GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  SLONIK_MOVE_SET (7)

NAME

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

CONTENTS

Synopsis

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 moveset(integer,integer).

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 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 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

Search for    or go to Top of page |  Section 7 |  Main Index


SLONIK MOVE SET (7) 18 January 2015

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.