### Slony-I example

In this example, a master server is setup with two direct slaves. This example was written and tested using Slony-I v1.2.11 and PostgreSQL 8.2.5, running on a single Windows XP machine. The PostgresSQL pgbench utility is used to generate the test schema and workload.

1. Create 3 databases, master, slave1 and slave2 and ensure pl/pgsql is setup in each.
2. Create a pgbench schema in the master database:
   `> pgbench -i -U postgres master`
3. Add a primary key called history_pkey to the history table on the tid, bid and aid columns.
4. Create a schema-only dump of the master database, and load it into slave1 and slave2:
   `> pg_dump -s -U postgres master > schema.sql
   > psql -U postgres slave1 < schema.sql
   > psql -U postgres slave2 < schema.sql`
5. Create Slony config files for each slon engine (daemon on *nix). The files should contain just the following two lines:
   `cluster_name='pgbench'
   conn_info='host=127.0.0.1 port=5432 user=postgres dbname=master'`
   Create a file for each database, adjusting the dbname parameter as required and adding any other connection options that may be needed.
6. (Windows only) Install the Slony-I service:
   `> slon -regservice Slony-I`
7. Register each of the engines (this is only necessary on Windows - on *nix the slon daemons may be started individually and given the path to the config file on the command line using the -f option):
   `> slon -addengine Slony-I C:\slony\master.conf
   > slon -addengine Slony-I C:\slony\slave1.conf
   > slon -addengine Slony-I C:\slony\slave2.conf`
8. In pgAdmin under the Replication node in the master database, create a new Slony-I cluster using the following options:

       Join existing cluster: Unchecked
       Cluster name:          pgbench
       Local node:            1        Master node
       Admin node:            99       Admin node

9. Under the Replication node, create a Slony-I cluster in each of the slave databases using the following options:

       Join existing cluster: Checked
       Server:                <Select the server containing the master database>
       Database:              master
       Cluster name:          pgbench
       Local node:            10       Slave node 1
       Admin node:            99 - Admin node

       Join existing cluster: Checked
       Server:                <Select the server containing the master database>
       Database:              master
       Cluster name:          pgbench
       Local node:            20       Slave node 2
       Admin node:            99 - Admin node

10. Create Paths on the master to both slaves, and on each slave back to the master. Create the paths under each node on the master, using the connection strings specified in the slon config files. Note that future restructuring of the cluster may require additional paths to be defined.
11. Create a Replication Set on the master using the following settings:

        ID:                  1
        Comment:             pgbench set

12. Add the tables to the replication set using the following settings:

        Table:               public.accounts
        ID:                  1
        Index:               accounts_pkey

        Table:               public.branches
        ID:                  2
        Index:               branches_pkey

        Table:               public.history
        ID:                  3
        Index:               history_pkey

        Table:               public.tellers
        ID:                  4
        Index:               tellers_pkey

13. On the master node, create a new subscription for each slave using the following options:

        Origin:              1
        Provider:            1 - Master node
        Receiver:            10 - Slave node 1

        Origin:              1
        Provider:            1 - Master node
        Receiver:            20 - Slave node 2

14. Start the slon service (or daemons on *nix):
    `> net start Slony-I`

Initial replication should begin and can be monitored on the statistics tab in pgAdmin for each node. The pgbench utility may be run against the master database to generate a test workload.