Provided by: slony1-2-doc_2.0.7-3build1_all bug


       FAILOVER - Fail a broken replication set over to a backup node


       FAILOVER (options);


       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
       higher 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
       allowing 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
       removed from the configuration with SLONIK DROP NODE(7).

       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(integer, integer)” [not available as a man page].


       FAILOVER (
          ID = 1,
          BACKUP NODE = 2


       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
       origin 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 there are many nodes in a cluster, and failover includes dropping out additional  nodes
       (e.g.  when  it  is  necessary to treat all nodes at a site including an origin as well as
       subscribers as failed), it is necessary to carefully sequence the actions.


       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
       provide a value for this parameter.

                                         3 December 2011                       SLONIK FAILOVER(7)