7. Reshaping a Cluster

If you rearrange the nodes so that they serve different purposes, this will likely lead to the subscribers changing a bit.

This will require doing several things:

• If you want a node that is a subscriber to become the origin for a particular replication set, you will have to issue a suitable slonik MOVE SET operation.

• You may subsequently, or instead, wish to modify the subscriptions of other nodes. You might want to modify a node to get its data from a different provider, or to change it to turn forwarding on or off. This can be accomplished by issuing the slonik SLONIK SUBSCRIBE SET operation with the new subscription information for the node; Slony-I will change the configuration. No need to ask for SLONIK UNSUBSCRIBE SET; no need for it to start copying data from scratch; the SLONIK SUBSCRIBE SET request will reshape the subscription "on the fly" and allow data to remain consistent between nodes.

• If the directions of data flows have changed, it is doubtless appropriate to issue a set of SLONIK DROP LISTEN operations to drop out obsolete paths between nodes and SLONIK STORE LISTEN to add the new ones. Up until version 1.1, this was not changed automatically; as of 1.1, SLONIK MOVE SET and SLONIK SUBSCRIBE SET change the paths as a side-effect. See Section 9 for more information about this. In version 1.1 and later, generation of sl_listen entries is entirely automated, so that they are regenerated when changes are made to sl_path or sl_subscribe, thereby making it unnecessary to even think about SLONIK STORE LISTEN.

• After performing the configuration change, you should, as Section 1, run the Section 5.1 scripts in order to validate that the cluster state remains in good order after this change.

The altperl toolset includes a regenerate-listens script that is up to the task of creating the new SLONIK STORE LISTEN commands; it isn't, however, smart enough to know what listener paths should be dropped.