| Slony-I 1.2.13 Documentation | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Fast Forward | Next | |
2. Replicating Your First Database
In this example, we will be replicating a brand new +
| Slony-I 1.2.13 Documentation | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Fast Forward | Next | |
2. Replicating Your First Database
In this example, we will be replicating a brand new pgbench database. The mechanics of replicating an existing database are covered here, however we recommend that you learn how Slony-I functions by using a fresh new @@ -55,7 +58,9 @@ configuration:
You have tcpip_socket=true in your -postgresql.conf and
You have enabled access in your cluster(s) via +postgresql.conf (not needed for Postgres version 8.0 and higher) and
+
+You have enabled access in your cluster(s) via pg_hba.conf
The REPLICATIONUSER needs to be a PostgreSQL superuser. This is typically postgres or pgsql, although in complex environments it is quite likely a good idea to define a @@ -76,7 +81,11 @@ in which case you can skip this step because it's already installed into the $MASTERDBNAME. -
createlang -h $MASTERHOST plpgsql $MASTERDBNAME
Slony-I does not automatically copy table definitions from a +
createlang -h $MASTERHOST plpgsql $MASTERDBNAME +
+ + +
Slony-I does not automatically copy table definitions from a master when a slave subscribes to it, so we need to import this data. We do this with pg_dump. @@ -89,14 +98,23 @@
pgbench -s 1 -c 5 -t 1000 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
This will run pgbench with 5 concurrent clients each processing 1000 transactions against the pgbench -database running on localhost as the pgbench user.
2.3. Configuring the Database for Replication.
Creating the configuration tables, stored procedures, triggers +database running on localhost as the pgbench user.
2.3. Configuring the Database for Replication.
Creating the configuration tables, stored procedures, triggers and configuration is all done through the slonik tool. It is a specialized scripting aid that mostly calls stored -procedures in the master/slave (node) databases.
2.3.1. Using the altperl scripts
Using the Section 19.1 scripts is an easy way to get started. The +procedures in the master/slave (node) databases.
2.3.1. Using the altperl scripts
+ ++WARNING: altperl scripts are broken. Skip to section 2.3.2 for a more enjoyable test configuration experience. +
+ +Using the Section 19.1 scripts is an easy way to get started. The slonik_build_env script will generate output providing details you need to omplete building a slon_tools.conf. An example slon_tools.conf is provided in the distribution -to get you started. The altperl scripts will all reference +to get you started. This file is stored by default in . The altperl scripts will all reference this central configuration file in the future to ease administration. Once slon_tools.conf has been created, you can proceed as follows:
# Initialize cluster: $ slonik_init_cluster | slonik @@ -106,11 +124,19 @@ $ slon_start 2 # Create Sets (here 1 is a set number) -$ slonik_create_set 1 +$ slonik_create_set 1 | slonik # subscribe set to second node (1= set ID, 2= node ID) -$ slonik_subscribe_set 2 | slonik
You have now replicated your first database. You can skip the following section -of documentation if you'd like, which documents more of a "bare-metal" approach.
2.3.2. Using slonik command directly
The traditional approach to administering slony is to craft +$ slonik_subscribe_set 1 2 | slonik + + + + +
You have now replicated your first database. You can skip the following section +of documentation if you'd like, which documents more of a "bare-metal" approach.
2.3.2. Using slonik command directly
The traditional approach to administering slony is to craft slonik commands directly. An example of this given here.
The script to create the initial configuration for the simple master-slave setup of our pgbench database looks like this:
#!/bin/sh