BDR Comparisons

From PostgreSQL wiki

(Difference between revisions)
Jump to: navigation, search
(Why BDR?)
Line 13: Line 13:
 
* Replicated data is generated efficiently by direct decoding of the transaction log, minimising the cost on the source systems
 
* Replicated data is generated efficiently by direct decoding of the transaction log, minimising the cost on the source systems
  
* Replication includes schema change commands (DDL) and so the DBA maintenance burden is minimised
+
* Replication includes schema change commands (DDL) and so the DBA maintenance burden is minimised. DDL may be executed on any node.
  
 
* BDR works alongside physical replication for protecting local nodes.
 
* BDR works alongside physical replication for protecting local nodes.

Revision as of 05:14, 26 June 2014

If you're wondering what makes BDR different and why you should care about it, you're in the right place.

Contents

Why BDR?

  • Applications may connect to any node and write data, simplifying HA configurations
  • When a node fails, there is no wait for failover, or complexity in identifying new master
  • Nodes may be geographically distributed as BDR is not sensitive to inter-node latency
  • Data transferred between nodes is much less than with physical replication, reducing bandwidth costs and permitting the use of slower inter-node links
  • Replicated data is generated efficiently by direct decoding of the transaction log, minimising the cost on the source systems
  • Replication includes schema change commands (DDL) and so the DBA maintenance burden is minimised. DDL may be executed on any node.
  • BDR works alongside physical replication for protecting local nodes.
  • BDR provides global sequences for cluster-wide unique key generation. There is no need to use UUID keys or offset sequences. Global sequences are transparent to applications.
  • BDR has built-in last-update-wins conflict handling and extensible support for user-defined conflict handlers that are aware of application logic.

BDR compared to PostgreSQL's built-in streaming replication

BDR is very different to Pg's existing streaming replication, though it builds on some of the same infrastructure.

Key differences:

  • BDR supports multiple masters. All members are writeable nodes that replicate changes.
  • BDR doesn't send VACUUM traffic, index updates, full page images from full page writes, etc over the wire. Only data rows, DDL, and internal co-ordination data are sent. This saves a huge amount of bandwidth on some workloads.
  • BDR replicates per-database, not per-cluster. So you don't have to split your databases up into different PostgreSQL instances just to control how they replicate.
  • Unlike built-in SR, you can't combine BDR with WAL archiving. It only transfers data when there's a direct TCP connection between the servers.
  • There's no warm-standby or PITR with BDR. It only has only multi-master mode (though the underlying Logical Log Streaming Replication facility is capable of single-master hot-standby configurations).

There are also some implementation limits that will be progressively removed:

  • BDR doesn't yet support the cascading replication feature of PostgreSQL's physical replication.
  • BDR doesn't currently have synchronous replication; a future release may add it.
  • You must explicitly configure each database you want to replicate.

Finally, there's no need for wal_keep_segments with BDR - it automatically manages WAL retention on the master. The "replication slots" feature added to 9.4 allows you to use this BDR feature with regular streaming replication too.

BDR compared to trigger-based replication

BDR has a lower impact on the master(s) than trigger based replication solutions. There is no write-amplification, as it does not require triggers to write to queue tables in order to replicate writes.

Additionally:

Londiste (Skytools)

  • Londiste does single master replication; BDR supports multiple masters
  • BDR replicates DDL; there's no need to script changes on all nodes.

Bucardo

  • Both Bucardo and BDR support multi-master
  • Bucardo 5 supports > 2 masters; prior versions are limited to 2 masters. BDR doesn't limit the number of masters
  • BDR replicates DDL; there's no need to script changes on all nodes.
  • BDR performs significantly better than Bucardo
  • Bucardo works on PostgreSQL prior to 9.4 and doesn't require patches.

Slony-I

  • Both BDR and Slony-I support DDL, but BDR permits you to issue DDL commands directly to PostgreSQL without an external helper program.
  • There's no need to configure and update triggers on your tables with BDR
  • BDR supports multi-master operation; Slony-I does not.
  • BDR is a lot simpler to operate than Slony-I
  • Slony-I works on PostgreSQL prior to 9.4 and doesn't require patches.

Rubyrep

...

Personal tools