Node management functions table

Function	Return Type	Description
bdr.bdr_group_create(local_node_name, node_external_dsn, node_local_dsn DEFAULT NULL, apply_delay integer DEFAULT NULL, replication_sets text[] DEFAULT ARRAY['default'])	void	Create the first node in a future cluster of bdr nodes. May be run on an empty database or one with existing data. An existing database may be a previously standalone normal PostgreSQL databaseor an ex-BDR database cleaned with bdr.remove_bdr_from_local_node. The "dsn" (data source name) parameters are libpq connection strings. node_external_dsn is an arbitrary node name, which must be unique across the BDR group. node_external_dsn must be a connection string other nodes can use to connect to this node. It must embed any required passwords unless passwordless authentication is required or a suitable .pgpass file is created in the postgres home directory. If specified, node_local_dsn should be a local loopback or unix socket connection string that the node can use to connect to its self; this is only used during initial setup to make the database restore faster. apply_delay allows you to slow down transaction apply, and is mainly for debugging. replication_sets is the collection of replication sets this node should receive. See Joining a node for details on node joining and creation, and Replication Sets for more on how replication sets work.
bdr.bdr_group_join(local_node_name, node_external_dsn, join_using_dsn, node_local_dsn DEFAULT NULL, apply_delay integer DEFAULT NULL, replication_sets text[] DEFAULT ARRAY['default'])	void	Join this database to a cluster of existing bdr nodes. This will initiate connections to and from all nother nodes. The function returns immediately, without waiting for the join process to complete, and only starts work when the calling transaction commits.bdr.bdr_node_join_wait_for_ready may be used to wait until join completes. If there are problems with the join, check the PostgreSQL logs on both systems for more information. The parameters are the same as bdr.bdr_group_create() except for the additional required parameter join_using_dsn. This must be the libpq connection string of the node to initialize from, i.e. the other node's node_external_dsn. Any node may be chosen as the join target, but if possible a node with a fast and reliable network link to the new node should be preferred. Note that bdr.bdr_group_join() can not "re-join" a node you removed with bdr.bdr_part_by_node_names(). See Joining a node for details on node joining and creation, and Replication Sets for more on how replication sets work.
bdr.bdr_part_by_node_names(p_nodes text[])	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. There is no way to re-join a node once removed; a new node must be created and joined to replace the parted one if required.
bdr.remove_bdr_from_local_node(force boolean, convert_global_sequences boolean)	void	Remove BDR slots, replication identifiers, security labels including replication sets, etc from a BDR-enabled database, so the BDR extension can be dropped and the database used for normal PostgreSQL. Will refuse to run on a node that hasn't already been parted from the cluster unless force is true. Global sequences are converted into local sequences unless convert_global_sequences is false. See Turning a BDR node back into a normal database for details, including important caveats with conversion of sequences.
bdr.bdr_node_join_wait_for_ready()	void	Wait till all in-progress node joins have completed.
bdr.bdr_is_active_in_db()	boolean	Report whether the current database has BDR active. Will be true if BDR is configured, whether or not there are active connections or any peer nodes added yet. Also true on a parted node until/unless bdr.remove_bdr_from_local_node is called.
bdr.bdr_apply_pause()	void	Temporarily stop applying changes from remote nodes to the local node, until resume is requested with bdr.bdr_apply_resume(). Connections to the remote node(s) are retained but no data is read from them. The effects of pausing apply are not persistent, so replay will resume if PostgreSQL is restarted or the postmaster does crash recovery after a backend crash. Terminating individual backends using pg_terminate_backend will not cause replay to resume; nor will reloading the postmaster without a full restart. There is no option to pause replay from only one peer node.
bdr.bdr_apply_resume()	void	Resume replaying changes from peer nodes after replay has been paused by bdr.bdr_apply_pause().
bdr.bdr_apply_is_paused()	boolean	Report whether replay is paused (e.g. with bdr.bdr_apply_pause()). A false return does not mean replay is actually progressing, only that it's not intentionally paused.
bdr.bdr_replicate_ddl_command(cmd text)	void	Execute the SQL (usually DDL) cmd on the local node and queue it for extension on all peer nodes. 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; seeDDL 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. Additionally, this function does not acquire the global DDL lock so care must be taken to ensure that concurrent DDL is not run on multiple nodes. Do not use this to enqueue ALTER TABLE, DROP TABLE etc on a BDR system as committed but not yet applied changes from other nodes might fail to apply after the change, breaking replication.
pg_xlog_wait_remote_apply(lsn pg_lsn, pid integer)	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 pg_current_xlog_insert_location() as the target LSN. Note that currently disconnected peers will not be waited for; this function cannot be used to verify that all peers are caught up, only all currently connected peers. (This function was added to PostgreSQL 9.4 by the BDR patches and is not part of the BDR extension as such.)
pg_xlog_wait_remote_receive(lsn pg_lsn, pid integer)	void	Same as pg_xlog_wait_remote_apply(...), but returns as soon as the remote confirms it has received the changes, not necessarily applied them.
bdr.terminate_apply_workers(sysid text, timeline oid, dboid oid)	boolean	Terminate any downstream (apply) BDR workers that are connected to the upstream peer with the identified (sysid,timeline,dboid) tuple. Returns true if a terminate signal was successfully sent. The worker may not yet have exited; check pg_stat_activity.
bdr.terminate_walsender_workers(sysid text, timeline oid, dboid oid)	boolean	Terminate any upstream (walsender) BDR workers that are connected to the downstream peer with the identified (sysid,timeline,dboid) tuple. Returns true if a terminate signal was successfully sent. The worker may not yet have exited; check pg_stat_activity.
bdr.terminate_apply_workers(node_name text)	boolean	Same as bdr.terminate_apply_workers(text,oid,oid) but instead of a node identity tuple this function looks up the node in bdr.bdr_nodes by node name.
bdr.terminate_walsender_workers(node_name text)	boolean	Same as bdr.terminate_walsender_workers(text,oid,oid) but instead of a node identity tuple this function looks up the node in bdr.bdr_nodes by node name.
bdr.skip_changes_upto(sysid text, timeline oid, dboid oid, skip_to_lsn pg_lsn)	void	Discard (skip over) changes not yet replayed from the peer with identity (sysid,timeline,dboid), resuming replay at the first commit after skip_to_lsn. A commit exactly at the specified LSN is skipped, not replayed. Warning This function is very dangerous. Improper use can completely break your replication setup, and almost any use will cause your cluster nodes to become inconsistent with each other. It is intended only for recovery from situations where replication is broken by un-replayable DDL or similar. Use the bdr.trace_replay setting to enable replay tracing and find the problem change to skip, or look at the error context emitted in log messages if there's an error. You may need to set log_error_verbosity = verbose in postgresql.conf to see the full error context. Skip to the commit LSN reported in the error, like "in commit 0123/ABCD0123". Because the change is still committed on the node it originated from and possibly on other nodes, to restore consistency you'll have to perform some transactions manually with bdr.do_not_replicate, bdr.permit_unsafe_ddl_commands and/or bdr.skip_ddl_replicationoptions set to restore consistency by manually undoing the operations on some nodes or manually applying them on the other nodes. Note: BDR still cares about dropped columns in tables, so if you dropped a column in one node then skipped the drop in another, you must manually drop the column in the one you skipped it in; adding the column back on the other side does not have the same effect because BDR uses the underlying column attribute numbers frompg_catalog.pg_attribute, not column names, to replicate... and those numbers change when you drop and re-create a column.