BDR Comparisons

From PostgreSQL wiki

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
 
If you're wondering what makes BDR different and why you should care about it, you're in the right place.
 
If you're wondering what makes BDR different and why you should care about it, you're in the right place.
 +
 +
= 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
 +
 +
* BDR works alongside physical replication for protecting local nodes.
 +
 +
* BDR provides [[BDR Global Sequences|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 compared to PostgreSQL's built-in streaming replication =

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
  • 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