Replication Server FAQs
Q. What's the difference between Single Master Replication (SMR) and Multi-Master Replication (MMR) ?
A. SMR allows your client applications to update or write to only 1 database server and allows them to read from all database servers in a replication cluster. Writing to the single master can be a limiting factor in write performance / scalability / availability. MMR allows your client applications to both write and read from any database server in a replication cluster while keeping all servers in synch in near real time.
Q. What are the main benefits of Replication Server with Multi-Master support?
A. Multi-master replication solutions are ideal for geo-dispersed organizations in need of better local write performance, improved write availability, scaling read workloads, and continuous data synchronization for applications tolerant of eventual consistency. xDB MMR provides customers with enhanced write availability for database clusters inside a single data center. This improves the cluster's ability to stay available for write operations without interruption should one of the master instances in the cluster fail. This provides better availability than a single master-multiple replica configuration which takes more time to promote a replica to master status.
MMR will also provide customers with enhanced write availability for geographically dispersed database clusters hosted in separate data centers. This improves the entire cluster's ability to stay available for write operations by allowing masters hosted in other geographies to absorb the load for a failed master instance in one geography.
MMR will improve write performance for database applications tolerant of eventual consistency. A multi-master cluster will be able to handle larger write volumes by routing write operations to multiple local master databases instead of all writes going to a single master which may be geographically distant and suffer from network latency.
MMR provides customers the ability to synchronize writes in one geography with other databases located in a separate geography. This enhances an organization's ability to provide a more up to date single view of the data regardless of the geography where the write occurred. MMR data consistency is not immediate and must be gauged against each organization's application needs. This is s much better solution than having a single master attempt to keep data from going stale by one or more daily batch updates.
xDB MMR provides the above benefits using low cost commodity hardware reducing costs for the organization instead of very expensive specialized hardware.
Q. Is SMR a separate product from MMR?
A. No and yes. No in the sense that both capabilities are built into the same software bundle that you download and install. Yes, in that the MMR features are priced differently than the SMR features and require a Product Key to continue using them beyond the initial full feature evaluation period of 60 days.
Q. What happens after the 60 day trial is over?
A. When you install xDB you have all the SMR and MMR features available to try out and evaluate. After 60 days, you can no longer register databases for multi-master replication and you won't be allowed to create new MMR publications, alter MMR publications or schedule/change MMR replication events.
Q. Do I need to purchase a database subscription to use EDB Postgres Replication Server?
A. Yes, xDB Replication Server may only be used after purchasing a database subscription. An Enterprise Edition subscription includes using xDB in either single-master or multi-master configurations for the sockets (or vCores) covered by the subscription. A Standard Edition subscription includes using xDB in single-master configurations only. To use xDB for multi-master configurations with Standard Edition requires an additional add-on option purchase. Click here for subscription details.
Q. Do I need a Product Key to install EDB Postgres Replication Server?
A. No. xDB installs as a fully functional evaluation version under a Limited Use license and will operate with full capabilities for 45 days.
Q. How do I get Product Key?
A. Contact the EnterpriseDB Sales team by email: firstname.lastname@example.org the website at: http://www.enterprisedb.com/general-inquiry-form or by phone at: US +1 781-357-3390 or 1-877-377-4352 ; EMEA +31 70 891 8451 ; Japan +81-3-5488-6007 ; UK +44 (0) 1235 227276 ; INDIA +91-20-30589500/01.
Q. Is EDB Postgres Replication Server based on triggers ?
A. Yes, it uses triggers.
Q. Will the triggers delay the transactions on my production database?
A. No. 'After' triggers are used so they will not affect the actual transaction that is being performed against the base table.
Q. If replication is asynchronous, how will it ensure that all Master transactions are available on the Replica database?
A. By definition asynchronous means there is no guarantee that all transactions will always be available on the replica database. The risk is if the network between the master database and the replica database is unreliable then it is possible that some transactions will be delayed from reaching the replica database. However, due to the publication /subscription architecture of xDB, the transaction is recorded in the replication log on the master and thus when the replica is reachable, the transactions will be sent. Thus, there might be a delay but the replica will get synchronized with the master eventually.
Q. What if I loose my EDB Postgres Replication Server control database?
A. If the xDB control database is lost, the worst case scenario is that the master and replica are out of sync. If you can't recover the control database and need to re-configure the replication setup, the snapshot and subsequent sync process will get the master and replica back in sync.
Q. Can I use my secondary database for Load Balancing?
A. Yes, but only for read load balancing. Though you can use Master-Master replication between two Postgres Database and achieve write load balancing at the application end as well by connecting to two different Databases.
Q. What operating system platforms are supported?
A. Linux 32/64, Windows 32/64, Solaris x86/SPARC and OS X.
Q.Will replication cause performance degradation on my Primary Database?
A. There is some overhead related to the triggers firing and performing an additional write to the shadow table. That overhead can be in the range of a 10-15 percent performance impact on the Master database server.
Multi-Master Technical FAQs
Q. How many master nodes are supported?
An MMR cluster in general is limited to 2-3 nodes, however one can use as many nodes as you wish - there is no technical limitation. Adding too many nodes for many applications will increase the replication latency since each master synchs to all the other masters in the cluster. Depending on your application and requirements the increased latency may be within your tolerances.
Latency will increase according to the following formula: sync cycles for one replication event when changes are available on all nodes = cluster node count * (cluster node count -1) e.g. for a 3 node cluster, 6 cycles occur for one rep event, so for a 4 node cluster it'll increase to 12. If WRITE changes occur on only a subset of cluster nodes then some synch cycles will not cause any overhead.
Practically an MMR framework (be it Oracle® Advanced Replication or an SQL Server MMR solution) is subject to result in an increase in "replication latency" as more nodes are added in the cluster. In addition the network layout (so a WAN is typically subject to cause more latency). The triggers behind replication are expected to drop the TPM rate by 20-30%, but all applications and setups are different which makes evaluation and testing for your configuration a best practice before production deployment.
Q. What database server platforms does MMR support?
A. xDB Replication Server runs on all platforms supported by EDB Postgres Advanced Server.
Q. What database server products does MMR work with?
A. PostgreSQL and Postgres Plus Advanced Server distributions from EnterpriseDB. Non-EnterpriseDB distributions of PostgreSQL are also supported with prior notice and approval from EnterpriseDB. The supported combinations for multi-master replication between database server products is in the v5.0 release are:
- All Master nodes are PPAS databases configured in Oracle compatibility mode
- All Master nodes are PPAS databases configured in PostgreSQL mode
- All Master nodes are PostgreSQL databases
- Some Master nodes are PPAS databases configured in PostgreSQL mode and some Master nodes are PostgreSQL databases
Q. What database server versions does MMR work with?
A. xDBM MMR can be used with versions 9.0 and higher for PostgreSQL and Postgres Plus Advanced Server.
Q. Is replication with Oracle® or Microsoft® SQL Server supported too?
A. Oracle and SQL Server are not supported for MMR.
Q. Can each master also participate in streaming replication?
A. Yes, each master can implement streaming replication to a local Hot Standby.
Q. Does table size matter?
Q. Do replication tables need to have a primary key constraint?
A. Yes, An explicit Primary Key constraint is required. An OID cannot be used.
Q. Are there any initial data load considerations?
A. In the case where each of the master nodes is hosted in a different geography and communicating over a WAN, the initial database dump size may impact your choice of initial loading. Where a large amount of data is involved, it's better to perform an offline snapshot (see details in the xDB documentation) rather than doing an online snapshot from Master Database Node database.
Q. Can MMR do everything that xDB SMR can do?
A. Almost. The following features are not supported in MMR in the v5.1 release: cascading replication and heterogenous replication.
Q. Who created EDB Postgres Replication Server and how is it licensed?
A. EnterpriseDB created xDB and distributes it under the EnterpriseDB Full Use License.