NAME

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

SYNOPSIS

       FAILOVER (options);

DESCRIPTION

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

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

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

EXAMPLE

       FAILOVER (
          ID = 1,
          BACKUP NODE = 2
       );

       #example of multiple nodes
       FAILOVER(
          NODE=(ID=1, BACKUP NODE=2),
          NODE=(ID=3, BACKUP NODE=4)
       );

LOCKING BEHAVIOUR

       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 up‐
       dates are complete.

DANGEROUS/UNINTUITIVE BEHAVIOUR

       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 like‐
       ly 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 complicated.

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.

VERSION INFORMATION

       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

       In version 2.2 support was added for passing multiple nodes to a single failover command

                                                19 September 2024                             SLONIK FAILOVER(7)