'\" -*- coding: us-ascii -*-
.if \n(.g .ds T< \\FC
.if \n(.g .ds T> \\F[\n[.fam]]
.de URL
\\$2 \(la\\$1\(ra\\$3
..
.if \n(.g .mso www.tmac
.TH "SLONIK MOVE SET" 7 "24 July 2014" "" "Slony-I 2.2.3 Documentation"
.SH NAME
MOVE SET \- Change origin of a Slony-I replication set 
.SH SYNOPSIS
'nh
.fi
.ad l
\fBMOVE SET (options);\fR \kx
.if (\nx>(\n(.l/2)) .nr x (\n(.l/5)
'in \n(.iu+\nxu
'in \n(.iu-\nxu
.ad b
'hy
.SH 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. 
.PP
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,
\fIi.e.\fR fully catching up), the new origin will
take over and open all tables in the set for client application
update activity.
.PP
This is \fInot\fR failover, as it requires a
functioning old origin node (you needed to lock the set on the old
origin). You would probably prefer to \fBMOVE SET\fR
instead of \fBFAILOVER\fR, if at all possible, as
\fBFAILOVER\fR winds up discarding the old origin
node as being corrupted. Before \fBMOVE SET\fR will
function a \fBLOCK SET\fR is needed.
.PP
Note that this is a locking operation, which means that
it can get stuck behind other database activity.
.TP 
\*(T<ID = ival \*(T>
ID of the set to transfer
.TP 
\*(T<OLD ORIGIN = ival \*(T>
Node ID of the current set origin
.TP 
\*(T<NEW ORIGIN = ival \*(T>
Node ID of the new set origin
.PP
This uses \(lqschemadocmoveset(p_new_origin integer, p_set_id integer)\(rq [not available as a man page]. 
.SH EXAMPLE
.nf
\*(T<LOCK SET (
   ID = 1,
   ORIGIN = 1
);
MOVE SET (
   ID = 1,
   OLD ORIGIN = 1,
   NEW ORIGIN = 3
);
    \*(T>
.fi
.SH "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 triggers (logtrigger and lockset)
dropped and a denyaccess trigger added; on the new origin, the
denyaccess trigger is dropped and a logtrigger trigger
added. 
.SH "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.
.SH "VERSION INFORMATION "
This command was introduced in Slony-I 1.0