Table of Contents Previous Next


6 Multi-Master Replication Operation : 6.11 Ensuring High Availability

The actively used publication server and the master xDB Control database are running on the same physical host. This host is referred to as the master host in the context of the Slony replication environment. It is assumed that the subscription server is not used and is not running.
The Slony replication processes (the slon daemons) are to be run on the standby host. All Slony administration using the slonik utility program is to be run from the standby host as well.
Step 1: Install Postgres and the xDB Replication Server products on the standby host.
Note: You will later replace this newly created xDB Control database on the standby host with a backup of the schema and database object definitions from the master xDB Control database.
Step 2: Ensure that the POSTGRES_INSTALL_HOME/data/pg_hba.conf file and the XDB_HOME/etc/xdb_pubserver.conf file (especially the java.rmi.server.hostname configuration option) on the standby host are configured to allow participation in the multi-master replication system. Likewise, ensure the database servers of the master nodes can accept connections from the backup publication server on the standby host. See Section 6.1.4 for details on host accessibility.
Step 3: Install Slony on the master host and on the standby host. Make sure the same version of Slony is used on each host.
Note: Slony is available through Stack Builder for a PostgreSQL installation and through StackBuilder Plus for an Advanced Server installation.
Step 4: Make any necessary modifications to the pg_hba.conf files on the master host and on the standby host to permit access to the xDB Control databases from the slonik utility program and the slon daemon processes.
In this example, the Slony replication processes (the slon daemons) are to be run on the standby host for both the master and backup xDB Control databases. The slonik utility program is to be run from the standby host as well. The enterprisedb database superuser is used for these purposes.
This section describes the usage of the slonik utility program to set up Slony replication for the xDB Control database.
In examples on both the master host and the standby host, the POSTGRES_INSTALL_HOME/bin subdirectory has been added to the path as shown by the following:
Step 1: Make a backup file of the master xDB Control database schemas and database object definitions using the pg_dump utility program:
Note: This backup file must be created after you have created your multi-master replication system because schema _edb_replicator_pub and its database object definitions do not exist in the xDB Control database until after the replication system is created. This schema and its database object definitions must be included in the backup file.
Step 2: Recreate an empty xDB Control database on the standby host.
If the publication server is running on the standby host, stop the publication server by using the stop option of the Linux scripts or Windows services described in Step 1 of Section 5.2.1.
Step 3: On the standby host, load the pg_dump backup file into the newly created xDB Control database.
Step 4: Use the slonik utility program to create the Slony cluster, nodes, and replication set for the xDB Control databases on the master host and the standby host.
Environment variables set in script slony_setenv.sh are used to pass connection information to the slonik scripts and to the slon daemons.
The content of slony_setenv.sh is the following:
Environment variables with a suffix of 1 are used for connecting to the xDB Control database on the master host. Environment variables with a suffix of 2 are used for connecting to the xDB Control database on the standby host.
Note: For the purpose of simplicity in these examples, all database connection values are passed as environment variables. For a production environment, it is suggested that other techniques for passing database connection information be used, especially for hiding database passwords. See the Slony-I documentation for more information.
Be sure you have run slony_setenv.sh in your current session before running any of the slonik scripts or when starting the slon daemons.
Script slony_setup.sh defines the Slony cluster, nodes, and replication set as shown by the following:
The preceding script basically adds all database objects in schemas _edb_scheduler and _edb_replicator_pub to the replication set.
Step 5: On the standby host, start the slon daemons – one for the master xDB Control database and one for the backup xDB Control database.
Start the slon daemon for the master xDB Control database:
Start the slon daemon for the backup xDB Control database:
The operation of the slon daemons can be monitored by viewing the log files /tmp/slon_master.log and /tmp/slon_slave.log as shown by the following example for the master xDB Control database:
Step 6: Run script slony_subscribe.sh to subscribe the standby host to the replication set. This starts the Slony replication operation.
The slony_subscribe.sh script contains the following:
Step 1: Be sure the publication server is not running on either the master host or the standby host. Stop the publication server using the stop option of the Linux scripts or Windows services described in Step 1 of Section 5.2.1.
Step 2: On the standby host, run the script to perform the controlled switchover.
Script slony_origin_to_node2.sh shown by the following changes the role of node 2 (the backup xDB Control database) to the origin (master):
Step 3: On the standby host, start the publication server. See Section 5.2.1 for directions on starting a publication server.
Note: When using the xDB Replication Console or the xDB Replication Server CLI, you must register the publication server that is running on the standby host by specifying the network IP address of the standby host. See Section 5.2.1 for directions on registering a publication server.
Step 4: When the master host is back online, you can perform the switchover operation to revert the role of the origin back to the original master xDB Control database. Repeat steps 1 and 2, but use the following script, slony_origin_to_node1.sh, to switch the origin back to the original master xDB Control database:
Step 5: On the master host, start the publication server. See Section 5.2.1 for directions on starting a publication server.
Step 1: Be sure the publication server is not running on either the master host or the standby host. Stop the publication server using the stop option of the Linux scripts or Windows services described in Step 1 of Section 5.2.1.
Step 2: On the standby host, run the script to perform the failover.
Script slony_failover.sh shown by the following performs failover to the backup xDB Control database and drops the master xDB Control database from the Slony cluster:
Step 3: On the standby host, start the publication server and register it with the xDB Replication Console. See Section 5.2.1 for directions on starting and registering a publication server.
Step 4: You can stop the slon daemons since there are no longer any nodes participating in Slony replication.
The slon daemon is stopped using the kill command. You can find the process IDs by using the following command:
Use the kill command on the lower process ID of the pair running on each host:
Note: The database objects created by Slony in the xDB Control database on the master host are dropped by slonik when the slonik drop node command is processed. However, these Slony database objects still remain in the xDB Control database on the standby host. These include schema _xdbcluster and triggers created on the xDB Control database tables. These database objects must be dropped manually using a utility program such as PSQL or pgAdmin (Postgres Enterprise Manager Client in Advanced Server).

6 Multi-Master Replication Operation : 6.11 Ensuring High Availability

Table of Contents Previous Next