Man Linux: Main Page and Category List


       SUBSCRIBE SET - Start replication of Slony-I set


       SUBSCRIBE SET (options);


       This performs one of two actions:

       · Initiates replication for a replication set

         Causes  a  node  (subscriber)  to  start  replicating a set of tables
         either from the origin or from  another  provider  node,  which  must
         itself already be be an active, forwarding subscriber.

         The  application  tables  contained in the set must already exist and
         should ideally be empty. The current  version  of  Slony-I  will  not
         attempt  to  copy  the schema of the set. The replication daemon will
         start copying the current content of the set from the given  provider
         and  then  try  to  catch  up  with any update activity that happened
         during that copy process. After successful subscription,  the  tables
         are  guarded  on  the  subscriber, using triggers, against accidental
         updates by the application.

         If the tables on the subscriber are not  empty,  then  the  COPY  SET
         event  (which  is part of the subscription process) may wind up doing
         more work than should be strictly necessary:

         · It attempts to TRUNCATE the table, which will be efficient.

         · If that fails (a foreign key relationship  might  prevent  TRUNCATE
           from  working),  it  uses DELETE to delete all ‘old’ entries in the

         · Those old entries clutter up the table until it  is  next  VACUUMed
           after the subscription process is complete

         · The indices for the table will contain entries for the old, deleted
           entries, which will slow the process of inserting new entries  into
           the index.

         This operation can take a (potentially distinctly) non-zero period of
         time. If you have a great deal of data in a particular set of tables,
         it  may  take  hours  or  even  (if ‘a great deal’ indicates ‘tens or
         hundreds gigabytes of data’) possibly multiple days for this event to

         The  SUBSCRIBE  SET  request  will,  nonetheless,  return fairly much
         immediately, even though the work, being  handled  by  the  COPY  SET
         event,  is still in progress. If you need to set up subscriptions for
         a set of cascading nodes, you will need to wait for  each  subscriber
         to  complete subscribing before submitting requests for subscriptions
         that use that node as a provider. If you don’t, it  won’t  be  a  big
         deal:  slonik  will  check  the  node, discover that it is not yet an
         active provider for the set, and report back:

          Slony-I: provider 2 is not an active forwarding node for replication set 1

         In effect, such subscription  requests  will  be  ignored  until  the
         provider is ready.

       · Revising subscription information for already-subscribed nodes.

         If  you  need to revise subscription information for a node, you also
         submit  the  new  information  using  this  command,  and   the   new
         configuration  will be propagated throughout the replication network.
         The normal reason to revise this information is that you want a  node
         to  subscribe to a different provider node, or for a node to become a
         ‘forwarding’ subscriber so it may later become  the  provider  for  a
         later subscriber.

       ID = ival
         ID of the set to subscribe

       PROVIDER = ival
         Node ID of the data provider from which this node draws data.

       RECEIVER = ival
         Node ID of the new subscriber

       FORWARD = boolean
         Flag  whether  or  not  the  new  subscriber  should  store  the  log
         information during replication to make it possible candidate for  the
         provider  role  for  future  nodes. Any node that is intended to be a
         candidate for FAILOVER must have FORWARD = yes.

       This uses “schemadocsubscribeset( integer, integer, integer, boolean )”
       [not available as a man page].


          ID = 1,
          PROVIDER = 1,
          RECEIVER = 3,
          FORWARD = YES


       The  FORWARD=boolean  flag  indicates whether the subscriber will store
       log information in tables “sl_log_1” [not available as a man page]  and
       “sl_log_2”  [not  available  as  a man page]. Several implications fall
       from this...

       By storing the data in these tables on the subscriber,  there  is  some
       additional  processing  burden. If you are certain that you would never
       want to SLONIK MOVE  SET(7)  or  SLONIK  FAILOVER(7)  to  a  particular
       subscriber,  it  is  worth  considering  turning off forwarding on that

       There is, however, a case where having forwarding turned off opens up a
       perhaps-unexpected  failure  condition;  a rule of thumb should be that
       all nodes that connect directly to the origin  should  have  forwarding
       turned on. Supposing one such ‘direct subscriber’ has forwarding turned
       off, it is possible for that node to be forcibly  lost  in  a  case  of
       failover. The problem comes if that node gets ahead of other nodes.

       Let’s  suppose  that the origin, node 1 is at SYNC number 88901, a non-
       forwarding node, node 2 has processed  up  to  SYNC  88897,  and  other
       forwarding  nodes,  3,  4,  and  5, have only processed data up to SYNC
       88895. At that moment, the disk system on the origin node catches fire.
       Node  2  has  the data up to SYNC 88897, but there is no remaining node
       that  contains,  in  “sl_log_1”  [not  available  as  a  man  page]  or
       “sl_log_2”  [not available as a man page], the data for SYNCs 88896 and
       88897, so there is no way to bring nodes 3-5 up to that point.

       At that point, there are only two choices:  To  drop  node  2,  because
       there  is  no  way to continue managing it, or to drop all nodes but 2,
       because there is no way to bring them up to SYNC 88897.

       That dilemma may be avoided by making  sure  that  all  nodes  directly
       subscribing to the origin have forwarding turned on.


       · The  fact  that  the  request  returns  immediately  even  though the
         subscription may take considerable time to  complete  may  be  a  bit

         Processing   of   the   subscription   involves   two   events;   the
         SUBSCRIBE_SET,   initiated   from   the   provider   node,   and   an
         ENABLE_SUBSCRIPTION,  which is initiated on the subscriber node. This
         means  that  SLONIK  WAIT  FOR  EVENT(7)  cannot  directly  wait  for
         completion of a subscription. If you need to wait for completion of a
         subscription, then what you need to do instead is to submit a  SLONIK
         SYNC(7) request, and wait for that event.

       · This command has two purposes; setting up subscriptions (which should
         be unsurprising) and revising subscriptions, which isn’t  so  obvious
         to intuition.

       · New subscriptions are set up by using DELETE or TRUNCATE to empty the
         table on a subscriber. If you created a new node by copying data from
         an  existing node, it might ‘seem intuitive’ that that data should be
         kept; that is not the case - the former contents  are  discarded  and
         the node is populated from scratch.


       This  operation  does  not  require acquiring any locks on the provider

       On the subscriber node, it will have the effect of locking every  table
       in the replication set. In version 1.2, exclusive locks are acquired at
       the beginning of the process; in earlier versions, locks were  acquired
       implicitly as activity mandated it, which left some risk of deadlock if
       other applications could access the subscriber database at this time.


       This command was introduced in Slony-I 1.0

                                  12 May 2010          SLONIK SUBSCRIBE SET(7)