Slony makes it very easy to change the topology of a replication cluster. Let's say that business at the Boomtown store is really booming (ouch) and you want to lighten the load on the boomtown server. boomtown pulls replication data from springfield and forwards the data to snoozeville. You can tell snoozeville to pull its replication data directly from springfield by re-subscribing snoozeville and specifying a different provider (see Listing 24.9).
Listing 24.9. changeProvider.sk
#!/usr/local/bin/slonik # File: changeProvider.sk include ; subscribe set ( id = 1, provider = @SPRINGFIELD, receiver = @SNOOZEVILLE, forward = no );
That's nearly identical to the previous subscribe set command; the only difference is that you've changed the provider from @BOOMTOWN to @SPRINGFIELD.
You can also change the origin of a replication seta process known as re-mastering. To move a replication set from its current origin to a different node, you execute two slonik commands:
lock set ( id = set-id, origin = current-origin ); move set ( id = set-id, old origin = current-origin, new origin = target-origin );
When the move set command completes, Slony reverses the roles between the old origin (which is now a subscriber) and the new origin (which was formerly a subscriber). The old origin remains a member of the replication set, but it's just another subscriber now.
You can only re-master via the move set command if the origin node is healthy. If the origin has experienced a catastrophic failure, you can force another node to assume ownership of the replication set with the failover command. The failover command moves the replication set to a new origin just like the move set command, but it also invalidates the failed node. (Remove the failed node from the cluster with a drop node command once the failover command completes.) The syntax for the failover command is
failover ( id = failed-node, backup node = replacement-node );
The failover command replaces an entire node, not a single set. If the failed node originated more than one set, they're all re-mastered to the replacement node. If the failed node acted as a forwarding provider, failover moves all subscribers to the replacement node. If the failed node was a simple (non-forwarding) subscriber, the failover command doesn't do much of anything.
Part I: General PostgreSQL Use
Introduction to PostgreSQL and SQL
Working with Data in PostgreSQL
PostgreSQL SQL Syntax and Use
Part II: Programming with PostgreSQL
Introduction to PostgreSQL Programming
The PostgreSQL C APIlibpq
A Simpler C APIlibpgeasy
The New PostgreSQL C++ APIlibpqxx
Embedding SQL Commands in C Programsecpg
Using PostgreSQL from an ODBC Client Application
Using PostgreSQL from a Java Client Application
Using PostgreSQL with Perl
Using PostgreSQL with PHP
Using PostgreSQL with Tcl and Tcl/Tk
Using PostgreSQL with Python
Npgsql: The .NET Data Provider
Other Useful Programming Tools
Part III: PostgreSQL Administration
Introduction to PostgreSQL Administration
Internationalization and Localization
Replicating PostgreSQL Data with Slony