BDR and UDR use functions to manage the addition and removal of nodes and related replication control functions. See Node management for more on how to manage BDR.
The following functions exist to manage nodes:
Table 12-1. Node management functions
||void||Subscribes to changes made on another node. See bdr.bdr_subscribe.|
||void||Removes a previously created UDR subscription.|
||void||Create the first node in a future cluster of bdr nodes.|
||void||Join this database to a cluster of existing bdr nodes. This will initiate connections to and from all nother nodes.|
||void||Removes all the nodes - identified by the node names in the array. All the remaining nodes in the cluster have to be reachable for this to succeed. This function must be run on a node that is not being removed.|
||void||Wait till all in-progress node joins have completed.|
||void|| Temporarily stop applying changes from remote nodes to the local node,
until resume is requested with
||void|| Resume replaying changes from peer nodes after replay has been paused
||boolean|| Report whether replay is paused (e.g. with
||void||Execute the SQL (usually DDL) cmd on the local node and queue it for extension on all peer nodes. This function is useful mainly for replicating DDL in an UDR setup where the transparent DDL replication is not available. The same limitations apply to this function as to DDL run directly by the user, except that DDL not normally replicated by BDR will be replicated if run with this function; see DDL replication. References to objects in DDL must be fully schema-qualified (e.g. public.mytable not just mytable), otherwise the error no schema has been selected to create in will be emitted.|
||void|| Wait until the replication connection with process id pid
(or all connections if pid is 0)
in pg_stat_replication has replayed WAL up to at least
lsn. Typically used with
||void|| Same as |
bdr.bdr_subscribe will create unidirectional
connection between the local node and subscribe_to_dsn node.
Since: version 0.9.0.
The parameters are:
A string specifying the name of the new node (for identification purposes).
Connection string of the remote node from which replication should be started.
Public connection string to the new local node. It is used during initialization.
Time (in milliseconds), the node will wait before applying changes incoming from from the remote node.
Text array of replication sets which should be replicated to the local node. Note that you need to assign individual tables to the replication sets on the remote node.
What to synchronize (copy) during the node initialization. Currently supported values are full (the default) which means do full schema and data copy and none which means don't copy anything. Note that this can cause apply failures if the schemas of nodes differ.
If objects (tables, functions, types, views, etc) already exist on the
local node, i.e. the node calling this function, and have the same names
as objects on the upstream node being subscribed to, the subscribe may
fail. This failure will be visible in the logs but will not result
in any error being sent to the client that invoked the subscribe
bdr.bdr_unsubscribe to remove a
These examples show libpq connection strings without a host or hostadd.
To subscribe to a UDR group:
SELECT bdr.bdr_subscribe( local_node_name := 'udrnode', subscribe_to_dsn := 'port=6000 dbname=udrdemo', node_local_dsn := 'port=6001 dbname=udrdemo');
To create a BDR group on 'node1':
SELECT bdr.bdr_group_create( local_node_name := 'node1', node_external_dsn := 'port=5598 dbname=bdrdemo');
To join 'node2' to BDR group created above:
SELECT bdr.bdr_group_join( local_node_name := 'node2', node_external_dsn := 'port=5559 dbname=bdrdemo', join_using_dsn := 'port=5558 dbname=bdrdemo');
To remove 'node2' from the BDR group created above:
To see if your node is ready for replication (if you see a NULL result set, your node is ready):