BDR stands for BiDirectional Replication.
This page is a historical discussion of the BDR development project. Check the official BDR documentation for further information about BDR.
Design work began in late 2011 to look at ways of adding new features to PostgreSQL core to support a flexible new infrastructure for replication that built upon and enhanced the existing streaming replication features added in 9.1-9.2. Initial design and project planning was by Simon Riggs; implementation lead is now Andres Freund, both from 2ndQuadrant. Various additional development contributions from the wider 2ndQuadrant team as well as reviews and input from other community devs.
At the PgCon2012CanadaInCoreReplicationMeeting an inital version of the design was presented. A presentation containing reasons leading to the current design and a prototype of it, including preliminary performance results, is available here.
Project Overview and Plans
- To be included as part of the main PostgreSQL open source distribution
- Re-usable individual parts (see below), usable by other projects (slony, ...)
- Basis for easier sharding/write scalability
- Wide geographic distribution of replicated nodes
High Level Planning
Fundamental changes have been made as part of 9.3 to support BDR; total of 16 separate commits on these and other smaller aspects
- background workers
- xlogreader implementation
Fully working implementation will be available for production use in 2013. At this stage, probably more than 50% of code exists out of core.
Exact mechanism for dissemination is not yet announced; key objective is to develop code with the objective of being core/contrib modules. There is no long term plan for existence of code outside of core.
Objective to implement main BDR features into core Postgres.
Additional features based upon feedback
Aspects of BDR
Bi-Directional Replication consists of a number of related features
- Logical Log Streaming Replication - getting data from one master to another.
- Global Sequences - ability to support sequences that work globally across a set of nodes
- Conflict Detection & Resolution (options)
- DDL Replication via Event Triggers
Taken together these features will allow replication in both directions for any pair of servers. We could call this "multi-master replication", but the possibilities for constructing complex networks of servers allow much more than that, so we use the more general term bi-directional replication.
Note that these features aren't "clustering" in the sense that Oracle RAC uses the term. There is no distributed lock manager, global transaction coordinator etc.. The vision here is interconnected yet still separate servers, allowing each server to have radically different workloads and yet still work together, even across global scale and large geographic separation.
(Physical) Streaming replication talks about Master and Standby, so we could also talk about Master and Physical Standby, and then use Master and Logical Standby to describe LLSR. That terminology doesn't work when we consider that replication might be bi-directional, or at could be reconfigured that way in the future.
Similarly, the terms Origin, Provider and Subcriber only work with one Origin.
As a result of the architecture there are few physical tuning parameters. That may grow as the implementation matures, but not significantly.
There are no parameters for tuning transfer latency.
The only likely tunable is the amount of memory used to accumulate changes before we send them downstream. Similar in many ways to setting of shared_buffers and should be increased on larger machines.
A variant of hot_standby_feedback could be implemented also, though would likely need renaming.
The CRC check while reading WAL is not useful in this context and there will likely be an option to skip that for logical decoding since it can be a CPU bottleneck.
BDR usage is described in BDR User Guide.
Selective Replication (Table/Row-level filtering)
LLSR doesn't yet support selection of data at table or row level, only at database level. It is a design goal to be able to support this in the future.
DDL replication is supported using event triggers and DDL deparse, which is to be submitted to 9.5.
BDR restricts some DDL. See BDR Command Restrictions.
Logical changeset extraction
Merged in 9.4.