Using VIEW

Changing the Cluster Topology (Re mastering and Failover)

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.