BDR Administration

From PostgreSQL wiki

(Difference between revisions)
Jump to: navigation, search
(Using a physical clone)
m (Removing a node)
Line 104: Line 104:
 
== Removing a node ==
 
== Removing a node ==
  
Until automation for this is added, you will need to manually:
+
The process to remove a node is
  
* Delete the node from all configuration files
+
* Remove mention of the node from all configuration files
 
* Stop all nodes  
 
* Stop all nodes  
* Start all nodes.
+
* Start all nodes (note this is not the same thing as restarting all nodes)
* Delete the node from <tt>bdr_nodes</tt>  
+
* Delete the node record from <tt>bdr_nodes</tt>  
 
* Drop all slots that point to the removed node
 
* Drop all slots that point to the removed node
 
=== Gracefully removing a running node ===
 
 
See above.
 
 
=== Recovering from unplanned node loss ===
 
 
See above.
 
  
 
== Syncing all nodes ==
 
== Syncing all nodes ==

Revision as of 12:51, 2 July 2014

Contents

BDR administration tasks

Tasks a BDR admin might need to do.

Installing BDR

Discuss.

From packages

From source

To install BDR from sources you need to check out the sources, then and install PostgreSQL like normal. The only difference from a normal PostgreSQL install is that you'll need to install the contrib/btree_gist and contrib/bdr extensions.

Assuming that you want to install it in your home directory for testing purposes, you would install the development tools for your operating system/distro, then run:

To install the BDR extension and all the other "contrib" modules, you'd then run:

  • (cd contrib/btree_gist && make && make install)
  • (cd contrib/bdr && make && make install)

or to instead install all contribs (useful for widely used extensions things like hstore) instead just:

  • (cd contrib && make all)
  • (cd contrib && make install)

Adjusting your environment

Once you have BDR installed you will want to make sure that the BDR versions of PostgreSQL's binaries like pg_ctl, postgres and initdb are on your PATH.

You can do this per-command by writing (eg):

   PATH=/path/to/bdr/bin:$PATH pg_ctl ...

but it's generally more convenient to add the path to your .bash_profile. BDR's psql is unchanged from that in regular 9.4, as is the network protocol, so there won't be compatibility issues.

Just edit $HOME/.bash_profile and append:

   PATH=/path/to/bdr/bin:$PATH

Replace /path/to/bdr with the path you specified as --prefix to configure when you compiled BDR.

To test, close and re-open your terminal or run bash -l then run:

   psql --version

and it'll print:

   psql (PostgreSQL) 9.4_bdr0601

or similar if you're using a version with the BDR patches.

Creating the first node

You can make your first BDR node by creating a new data directory (a new PostgreSQL "cluster") or upgrading an existing 9.4 install for use with BDR.

New data directory

On RPM distros like RHEL/CentOS/Fedora you will need to run service postgresql-9.4bdr initdb to actually create the data directory. Your data directory will be /var/lib/pgsql/9.4bdr/data. You can skip to the next step after running that command.

On Ubuntu/Debian your data directory will be in /var/lib/postgresql/9.4bdr/main/data (Ubuntu, Debian). It has already been created for you so you can skip to the next step.

If you installed from source you need to initialize a new PostgreSQL data directory yourself. Run:

initdb --version

to check that it prints a version with "bdr" in it. If it doesn't, re-check the steps in adjusting your environment, above.

Then:

initdb -D $HOME/bdr-data -U postgres --auth-host=md5 --auth-local=peer

which will make the data directory.

Upgrading a 9.4 data directory

BDR will come with scripts to upgrade a 9.4 data directory to 9.4bdr or convert a 9.4bdr data directory back to plain unpatched 9.4.

Pending.

Adding a node

Pending.

Using a physical clone

The pg_basebackup utility can be used to create initial copy of the cluster from one of the existing nodes.

After the initial copy has been created, the postgresql.conf needs to be updated for current node (see Parameter Reference and Bi-Directional Replication Use Cases for more info. The important part is to set bdr.<connection_name>_init_replica for the connection(s) pointing to the cluster which was used as origin for pg_basebackup.

The bdr_init_copy utility which is provided as part of BDR has to be used to start the node for the first time - it will bring the node to consistent state with rest of the nodes.

Using a logical copy

Discuss init_replica, initdb vs CREATE DATABASE on an existing server.

Removing a node

The process to remove a node is

  • Remove mention of the node from all configuration files
  • Stop all nodes
  • Start all nodes (note this is not the same thing as restarting all nodes)
  • Delete the node record from bdr_nodes
  • Drop all slots that point to the removed node

Syncing all nodes

Pending.

Finding a lagging node

If a node doesn't keep up it can cause slots to fall behind and pg_xlog on other nodes to fill. Monitoring by admin should prevent this.

Dealing with full pg_xlog

If a slot doesn't progress, pg_xlog can fill up. Admin must deal with this problem.

Backups

BDR backups are no different to regular PostgreSQL - you can use pg_dump, pg_basebackup, pg_start_backup/rsync/pg_stop_backup with archiving, a file system level atomic snapshot, PgBarman, or whatever suits you.

Personal tools