The BDR team has recently introduced support for dynamically
adding new nodes to a BDR group from SQL into the current
development builds. Now no configuration file changes are required
to add nodes and there’s no need to restart the existing or newly
This change does not appear in the current 0.8.0 stable release;
it’ll land in 0.9.0 when that’s released, and can be found in the
bdr-plugin/next branch in the mean time.
New nodes negotiate with the existing nodes for permission to
join. Soon they’ll be able to the group without disrupting any DDL
locking, global sequence voting, etc.
There’s also an easy node removal process so you don’t need to
modify internal catalog tables and manually remove slots to drop a
New node join process
With this change, the long-standing GUC-based configuration for
BDR has been removed. bdr.connections no longer exists and
you no longer configure connections with bdr.[conname]_dsn
Instead, node addition is accomplished with the
bdr.bdr_group_join(...) function. Because this is a
function in the bdr extension, you must first CREATE
EXTENSION bdr;. PostgreSQL doesn’t have extension dependencies
and the bdr extension requires the btree_gist
extension so you’ll have to CREATE EXTENSION btree_gist
Creating the first node
Creation of the first node must now be done explicitly using
bdr.bdr_group_create. This promotes a standalone
PostgreSQL database to a single-node BDR group, allowing other
nodes to then be joined to it.
You must pass a node name and a valid externally-reachable
connection string for the dsn parameter, e.g.:
CREATE EXTENSION btree_gist;
CREATE EXTENSION bdr;
local_node_name = 'node1',
node_external_dsn := 'host=node1 dbname=mydb'
Note that the dsn is not used by the root node its self. It’s
used by other nodes to connect to the root node, so you can’t use a
dsn like host=localhost dbname=mydb if you intend to have
nodes on multiple machines.
Adding other nodes
You can now join other nodes to f