NAME

       MOVE SET - Change origin of a Slony-I replication set

SYNOPSIS

       MOVE SET (options);

DESCRIPTION

       Changes  the origin of a set from one node to another. The new origin must be a current subscriber of the
       set. The set must currently be locked on the old origin.

       After this command, the set cannot be unlocked on the old origin any more. The old origin  will  continue
       as  a  forwarding  subscriber of the set and the subscription chain from the old origin to the new origin
       will be reversed, hop by hop. As soon as the new origin has finished processing the event (that  includes
       any  outstanding sync events that happened before, i.e. fully catching up), the new origin will take over
       and open all tables in the set for client application update activity.

       This is not failover, as it requires a functioning old origin node (you needed to lock the set on the old
       origin). You would probably prefer to MOVE SET instead of FAILOVER, if at all possible, as FAILOVER winds
       up discarding the old origin node as being corrupted. Before MOVE SET will function a LOCK SET is needed.

       Note that this is a locking operation, which means that it can get stuck behind other database activity.

       ID = ival
              ID of the set to transfer

       OLD ORIGIN = ival
              Node ID of the current set origin

       NEW ORIGIN = ival
              Node ID of the new set origin

       This uses “schemadocmoveset(p_new_origin integer, p_set_id integer)” [not available as a man page].

EXAMPLE

       LOCK SET (
          ID = 1,
          ORIGIN = 1
       );
       MOVE SET (
          ID = 1,
          OLD ORIGIN = 1,
          NEW ORIGIN = 3
       );

LOCKING BEHAVIOUR

       Exclusive locks on each replicated table will be taken out on both the old origin node and the new origin
       node, as replication triggers are changed on both nodes: on the former origin, each table has  two  trig‐
       gers  (logtrigger  and lockset) dropped and a denyaccess trigger added; on the new origin, the denyaccess
       trigger is dropped and a logtrigger trigger added.

SLONIK EVENT CONFIRMATION BEHAVIOUR

       Slonik waits for the command submitted to the previous event node to be confirmed on the specified  event
       node before submitting this command.

VERSION INFORMATION

       This command was introduced in Slony-I 1.0

                                                 10 January 2016                              SLONIK MOVE SET(7)