For a couple of years now a team at 2ndQuadrant led by Andres Freund have been working on adding bi-directional asynchronous multi-master replication support for PostgreSQL. This effort has become known as the BDR project.
We’re really excited to see these efforts leading to new PostgreSQL features and have a great deal more still to come.
Incremental Development
As a large development project it is neither practical nor desirable to deliver all the changes to PostgreSQL as a single huge patch. That way lies madness and unmaintainable code. It would also be resoundingly rejected by the PostgreSQL community, as it should be.
Instead, BDR has been developed as a series of discrete changes to core PostgreSQL, plus an extension that uses those core changes to implement multi-master asynchronous logical replication.
To make this separation clearer we’ve split BDR into two separate trees since the last official release. We now manage and develop the set of patches to PostgreSQL separately from the BDR extension its self.
BDR is destined for community PostgreSQL
2ndQuadrant’s goal is to get all of BDR – the changes to the core server as well as the extension or its functionality – included in a future open source community PostgreSQL release.
When that’s achieved you’ll be able to use all the features currently provided by the BDR patches and extension with no 3rd party (open source or otherwise) patches, extensions and tools.
All of BDR is open source, released under the PostgreSQL license, and is developed on PostgreSQL’s public infrastructure. The git repository containing the authoritative current version of BDR is on git.postgresql.org.
Getting BDR into users’ hands
With a project as big as BDR and with the PostgreSQL project’s safety-first, conservative and careful development style it’ll be a long time before all of BDR is included in community PostgreSQL. As a result we’ve had to make some compromises in order to get BDR functionality out to users prior to the expected end of the 9.5/9.6 release cycles in a couple of years time.
The main compromise is that we have merged all the not-yet-committed patches to PostgreSQL core that BDR requires into a patched variant of PostgreSQL 9.4 that can be used to run BDR. The need for this patched version to exist is temporary. If all the patches required to run BDR (see below) get into PostgreSQL 9.5 it will be possible to run the BDR extension on a stock community version of PostgreSQL 9.5. We would’ve strongly preferred not to need to make a non-trivially patched version of PostgreSQL available to the public, even temporarily, so hopefully we can do away with it for 9.5.
BDR features in PostgreSQL 9.3, 9.4, 9.5 and onward
Many of the core server changes developed for or required by BDR have already been committed to community PostgreSQL. That means they’re part of released or soon-to-be-released PostgreSQL versions. These features include:
- Background workers (9.3)
- Event Triggers (9.3)
- Replication slots (9.4)
- Logical decoding (9.4)
- REPLICA IDENTITY (9.4)
Other changes have been submitted for potential inclusion in PostgreSQL 9.5 or are due to be submitted shortly, including:
- Commit Timestamps
- DDL deparse for event triggers
- Enhanced DROP event triggers
- Replication Identifiers
- Sequence Access Methods
BDR-related feature development has also led to other useful work by others, like pg_dump support for using snapshots.
Each of these features is/was a significant development effort in its self – and they’re just the foundations required to make the BDR extension possible.
Adoption of features developed for BDR by other projects
The BDR team is really excited at how far BDR has come and how much of the work done for BDR has already entered community PostgreSQL.
Some of those BDR building blocks are already seeing adoption and use for other purposes. For example, the Slony-I team are working on adopting the logical decoding feature developed for BDR to reduce replication overheads.
Background workers are sure to be a crucial foundation for new PostgreSQL features and capabilities such as built-in task scheduling, and in time I think that we’ll wonder how we ever did without them.
UDR – one-way BDR for unmodified community PostgreSQL 9.4
We’re also pleased to report that a reduced-functionality version of the BDR extension currently known as “UDR” will soon be available for use with PostgreSQL 9.4.
An extension running on unmodified PostgreSQL 9.4 can’t use the not-yet-in-core-PostgreSQL features that BDR relies on to implement full multi-master support. Nonetheless it provides useful path toward live major-version upgrade and an efficient one-way replication tool.
Because PostgreSQL 9.4 does not include support for DDL deparse, full DROP tracking, commit timestamps, or replication identifiers we can’t support DDL replication or multi-master in UDR.
Functionally UDR is quite similar to Londiste, but it avoids the write-amplification of trigger based replication and runs entirely within PostgreSQL, without any need for an external daemon. UDR will offer a useful live-migration path for moving stock 9.4 into BDR vice versa, and in future for online upgrades of 9.4 to later major releases.
More details on UDR will be available soon, as will RPMs.
What’s next for BDR
PostgreSQL is 9.4 due to be released any minute now, and we’re working to have a new BDR release ready to follow shortly afterwards.
Otherwise, the BDR team is focusing on getting all the functionality required to run BDR on top of unmodified PostgreSQL into PostgreSQL 9.5.
Support for replication sets was recently added to the BDR extension. This permits replication of subsets of tables in a database to some nodes, asymmetric replication, and various other configurations that are useful for workloads like data aggregation.
We’re also working on dynamic configuration, where node addition and removal is done using SQL commands instead of by modifying postgresql.conf and restarting the server. That work will lead to a smoother process for node addition and removal.
There are lots of goodies coming, both for core PostgreSQL and for users of the BDR extension.