SLONIK FAILOVER(7) Slony-I 2.2.6 Documentation SLONIK FAILOVER(7)
FAILOVER - Fail a broken replication set over to a backup node
The FAILOVER command causes the backup node to take over all sets that currently originate
on the failed node. slonik will contact all other direct subscribers of the failed node to
determine which node has the highest sync status for each set. If another node has a high‐
er sync status than the backup node, the replication will first be redirected so that the
backup node replicates against that other node, before assuming the origin role and allow‐
ing update activity.
After successful failover, all former direct subscribers of the failed node become direct
subscribers of the backup node. The failed node is abandoned, and can and should be re‐
moved from the configuration with SLONIK DROP NODE(7).
If multiple set origin nodes have failed, then you should tell FAILOVER about all of them
in one request. This is done by passing a list like NODE=(ID=val,BACKUP NODE=val),
NODE=(ID=val2, BACKUP NODE=val2) to FAILOVER.
Nodes that are forwarding providers can also be passed to the failover command as a failed
node. The failover process will redirect the subscriptions from these nodes to the backup
ID = ival
ID of the failed node
BACKUP NODE = ival
Node ID of the node that will take over all sets originating on the failed node
This uses “schemadocfailednode(p_failed_nodes integer, p_backup_node integer,
p_failed_node integer)” [not available as a man page].
ID = 1,
BACKUP NODE = 2
#example of multiple nodes
NODE=(ID=1, BACKUP NODE=2),
NODE=(ID=3, BACKUP NODE=4)
Exclusive locks on each replicated table will be taken out on both the new origin node as
replication triggers are changed. If the new origin was not completely up to date, and
replication data must be drawn from some other node that is more up to date, the new ori‐
gin will not become usable until those updates are complete.
This command will abandon the status of the failed node. There is no possibility to let
the failed node join the cluster again without rebuilding it from scratch as a slave. If
at all possible, you would likely prefer to use SLONIK MOVE SET(7) instead, as that does
not abandon the failed node.
If a second failure occours in the middle of a FAILOVER operation then recovery might be
SLONIK EVENT CONFIRMATION BEHAVIOUR
Slonik will submit the FAILOVER_EVENT without waiting but wait until the most ahead node
has received confirmations of the FAILOVER_EVENT from all nodes before completing.
This command was introduced in Slony-I 1.0
In version 2.0, the default BACKUP NODE value of 1 was removed, so it is mandatory to pro‐
vide a value for this parameter
In version 2.2 support was added for passing multiple nodes to a single failover command
21 September 2017 SLONIK FAILOVER(7)