slony-config is a tool for configuring and setting up a PostgreSQL database cluster with slony-I replication daemon. Previously, setting up and installing slony took a lot of research and understanding of the slonik and slon programs and their commands. This process was prone to many simple errors and was time consuming for those setting up a replication cluster for the first time.

slony-config aims to make configuration of a replication cluster very simple and straight forward by means of an xml based configuration format. slony-config is written in perl and makes use of the XML::Simple perl module which can be found on CPAN and easily installed via the cpan program that comes with most perl distributions as follows:

% cpan install XML::Simple

Configuration for slony-config is xml based and fairly simple. After creating your configuration file, simply execute the following command and follow the directions:

% ./slony-config --config-file=<path-to-config-file>

slony-config will first generate the slonik commands to setup your replication cluster, then offer you the opportunity to save those to a file. It will then ask if you want to execute those commands. After that, slony-config generates the slon command you will need to run on each replication server. Finally, it generates and asks if you want to save and or execute the commands to subscribe your replication servers to a set on the master.

slony-config is NOT a full featured command interface for slony. Although this sounds like something that slony-config COULD turn into at some point, currently this script will only get you setup and running on a simple replication architecture at best. It will not promote a slave to master, restart a node, or do any set management for you. For help on those issues, please consult the references portion of this document.

config This is the root element of the document. Currently it contains no attributes, however future revisions may include configuration version numbers for instance. cluster This element defines a replication cluster and must contain 1 master element, at least 1 slave element, and at least 1 set element. Currently the only attribute available for this node is id, which is used for naming your cluster. This behaviour may change in the near future. master This element defines the master database server in the cluster and currently has no possible child elements. Attribute Definition id A unique number identifying this node in the cluster. label A text label for human readability hostname Either a fully qualified domain name or IP address. database The database name. Currently required, but will be optional in the near future. user The superuser account for slony on this database node. slave This element defines a slave database server in the cluster and currently has no valid child elements. Attribute Definition id A unique number identifying this node in the cluster. label A text label for human readability hostname Either a fully qualified domain name or IP address. database The database name. Currently required, but will be optional in the near future. user The superuser account for slony on this database node. set This element defines a portion of the schema to be replicated and must contain at least 1 table element and may also contain sequence elements. Attribute Definition id A unique number identifying this set in the cluster. comment A text label for human readability table This element defines a table to be replicated and must be included inside a set element. Attribute Definition id A unique number identifying the table in the set. label A text label for human readability fqn The fully qualified name for the table. For example, table users in schema public is 'public.users'. key The column name to use as the key for this table. CURRENTLY NOT YET IMPLEMENTED. comment A text comment to be added to the slony configuration. sequence This element defines a sequence to be replicated and must be included inside a set element. Attribute Definition id A unique number identifying the sequence in the set. label A text label for human readability fqn The fully qualified name for the sequence. For example, sequence users_id_seq in schema public is 'public.users_id_seq'. comment A text comment to be added to the slony configuration.

Example 1 replicates the users table from the testing1 database on our master at IP address 192.168.0.1 with a superuser account of slony to the slave on the same machine but to a different database (testing2). Although not required, I use the same username for my superuser accounts in my PostgreSQL cluster to keep confusion at a minimum.

<?xml version='1.0'?>
<config>
  <cluster id='test1'>
    <master id='1' label='master' hostname='192.168.0.1' database='testing1' user='slony'/>
    <slave id='2' label='slave1' hostname='192.168.0.1' database='testing2' user='slony'/>
    <set id='1' comment="User Tables">
      <table id='1' label='users' fqn='public.users' comment='users Table'/>
    </set>
  </cluster>
</config>

Example 2 is a little more complex, 1 master replicating to 3 slaves and also replicates the sequences for those tables.

<?xml version='1.0'?>
<config>
  <cluster id='test1'>
    <master id='1' label='master' hostname='192.168.0.1' database='testing1' user='slony'/>
    <slave id='2' label='slave1' hostname='192.168.0.2' database='testing2' user='slony'/>
    <slave id='3' label='slave2' hostname='192.168.0.3' database='testing3' user='slony'/>
    <slave id='4' label='slave3' hostname='192.168.0.4' database='testing4' user='slony'/>
    <set id='1' comment="User Tables">
      <table id='1' label='users' fqn='public.users' comment='users Table'/>
      <table id='2' label='address' fqn='public.address' comment='address Table'/>
      <sequence id='1' label='users_id_seq' fqn='public.users_id_seq' comment='users.id Sequence'/>
      <sequence id='2' label='address_id_seq' fqn='public.address_id_seq' comment='address.id Sequence'/>
    </set>
  </cluster>
</config>

1. Tables MUST be defined with a primary key. Although this is not a requirement on slony's behalf, slony-config does not currently have other methods for defining the unique key to a table implemented and therefor will break your config without a primary key.

2. All slaves will be subscribed to all sets. This functionality will change in the near future, but for the most part, most replication systems define 1 set and copy it to all slaves. Future considerations will allow for slaves to define which sets they subscribe to via a <subscribe> child element.

3. slony-config is released under the FreeBSD license.

• Slony-I Website
• PostgreSQL Website
• Slonik Command Summary
  ... for those needing help promoting a slave, restarting a node, etc.

• Date: Tue, 19 Jul 2005 Author: DIEGO URRA Changes: line 72: add sequence to forcearray (bad interpretation of sequence) line 102,116,121,259,285,298: added password support
• Date: Fri, 1 Oct 2004 Author: PHILIP SNYDER Comments: Initial creation.