BDR Comparisons

From PostgreSQL wiki

Revision as of 05:07, 26 June 2014 by Ringerc (Talk | contribs)

Jump to: navigation, search

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

Contents

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