Slony SUBSCRIBE SET explained

Posted: May 22, 2010 in postgresql, Uncategorized
Tags: ,

Subscribing a set is the most useful slony operation (after all, a replication cluster with no subscriptions is pretty useless) but the subscription process somewhat complicated behind the scenes. Let’s review the proper way to subscribe a set and what happens underneath.


subscribe set(id=1, provider=2, receiver=3,forward=no);
wait for event(wait on=2, confirmed=3, origin=2);
sync(id=2)
wait for event(wait on=2, confirmed=3, id=2);


The first line

''subscribe set(id=1, provider=2, receiver=3,forward=no);''

says that slony should subscribe node 3 to replication set 1 and that node 3 should get the data from node 2.

Question: Does the provider node have to be the origin of set 1?
Answer: No, the provider node can be any node that is currently subscribed to set one with forward=yes

The subscribe set command will cause slonik to connect to the provider (node 2) and send a SUBSCRIBE SET message to node 3 via the slony event queue. The configuration tables on node 2 (sl_subscribe) will then be updated to reflect the subscription information. A ENABLE SUBSCRIPTION event will then be sent to node 3. This ENABLE SUBSCRIPTION event will be processed by node 3 after the SUBSCRIBE SET has been processed on both nodes 2 and 3.

subscribe set diagram

When the SUBSCRIBE SET event is processed on node 3, the slon for node 3, will configure node 3 as a subscriber to set 1 but mark the subscription as inactive. The SUBSCRIBE SET event will then be marked as being confirmed by node 3.

Enable subscription diagram

Next the ENABLE SUBSCRIPTION event will be processed by the slon for node 3. The ENABLE SUBSCRIPTION event will be transfered as an event in the event queue for node 3.

During the processing of the ENABLE SUBSCRIPTION event, the slon for node 3 will TRUNCATE each of the tables in the replication set (on node 3) and COPY the data from node 2 into node 3.

After all of the tables in the replication set have been copied to node to the set will be marked as active.

Having reviewed what the 'subscribe set' command does we can now examine the rest of the lines of the slonik script.

''wait for event(wait on=2, confirmed=3, origin=2);''
Tells slonik to wait until the subscribe set event has been confirmed as having been received by node 3.

sync(id=2)

Tells generates an explicit sync event on node 2. This sync event happens after the initial subscribe set message is received by node 3. The sync event also will appear in the event log after the enable subscription (because the enable subscription is inserted by the sync event).

wait for event(wait on=2, confirmed=3, origin=2);

Waits for the sync event (generated on the previous line) to be confirmed on node 3. The sync event can't be processed by node 3 until after the subscription process has been completed this is because the slon for node 3 won't get to processing the sync event until it is done processing the ENABLE SUBSCRIPTION event. Once this wait for completes it means that node 3 is subscribed to the replication set.

updated: I have changed the arguments in the 'wait for' commands in this past to be 'origin' the previous version of this post was in error. I also want to point out that this post applies to Slony versions earlier than 2.0.5. Things changed in 2.0.5, I should l write another post on that.

Advertisements
Comments
  1. Chirag says:

    Looks like in this command, id is not valid parameter.

    wait for event(wait on=2, confirmed=3, id=2);

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s