MOVE SET - Change origin of a Slony-I replication set
MOVE SET (options);
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
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.
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
instead of FAILOVER
, if at all possible, as
winds up discarding the old origin node as being corrupted.
Before MOVE SET
will function a LOCK SET
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].
LOCK SET (
ID = 1,
ORIGIN = 1
MOVE SET (
ID = 1,
OLD ORIGIN = 1,
NEW ORIGIN = 3
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 triggers (logtrigger and
lockset) dropped and a denyaccess trigger added; on the new origin, the
denyaccess trigger is dropped and a logtrigger trigger added.
Slonik waits for the command submitted to the previous event node to be
confirmed on the specified event node before submitting this command.
This command was introduced in Slony-I 1.0