SLONIK_FAILOVER(7)

πŸ“¦
version 2.2.11 Β· 4 versions
, in debian trixie, ubuntu questing

✨ NAME ✨

FAILOVER β€” fail a broken replication set over to a backup node πŸ’–

(we're in the SLONIK FAILOVER(7) page, from the Slony-I 2.2.11 Documentation era, and bestie it is so much drama in here)


🌸 SYNOPSIS 🌸

FAILOVER (options);

πŸ’… DESCRIPTION πŸ’…

okay so listen. Your origin node is gone. Not responding. It's giving ghosted. The FAILOVER command is how you make the backup node step up and take over all the sets that currently originate on the failed node. main character energy, honestly.

Here's the part that's lowkey iconic: slonik doesn't just blindly hand everything to your backup node. It goes and contacts all the other direct subscribers of the failed node to figure out which node has the highest sync status for each set. And if some other node turns out to be more up to date than your backup node? Then the replication gets redirected first β€” your backup node starts replicating against that more-up-to-date node β€” and only then does it assume the origin role and start allowing update activity. she studies first, then she slays. πŸ“šβž‘οΈπŸ‘‘

After a successful failover, all the former direct subscribers of the failed node become direct subscribers of the backup node. The failed node is abandoned, and it can and should be removed from the configuration with SLONIK DROP NODE(7).

If multiple set origin nodes have failed, you should tell FAILOVER about all of them in one request. Do that by passing a list like NODE=(ID=val,BACKUP NODE=val), NODE=(ID=val2, BACKUP NODE=val2) to FAILOVER. one shot, all the chaos. 🎯

Also: nodes that are forwarding providers can be passed to the failover command as a failed node too. The failover process will redirect the subscriptions from those nodes over to the backup node. no node left behind fr fr 🫢

  • ID = ival β€” the ID of the failed node. yes, the one that ditched us.
  • BACKUP NODE = ival β€” the node ID of the node that will take over all sets originating on the failed node. your new it-girl node. πŸ‘‘

Under the hood this uses schemadocfailednode(p_failed_nodes integer, p_backup_node integer, p_failed_node integer[]) β€” and nope, that one's not available as a man page. tragic, I know. 😭


πŸŽ€ EXAMPLE πŸŽ€

Just one node going down? Adorable. Simple. Here you go:

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

Multiple nodes down at once? Now we're in our multitasking era:

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

πŸ”’ LOCKING BEHAVIOUR πŸ”’

Exclusive locks get taken out on each replicated table, on both the new origin node and the old one, as replication triggers are being changed. So heads up: if the new origin wasn't completely up to date, and replication data has to be pulled from some other node that is more up to date, then the new origin will not become usable until those updates are complete. She's locked in. literally. πŸ”


πŸ’€ 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. That's not a vibe, that's a funeral.

If at all possible, you would likely prefer to use SLONIK MOVE SET(7) instead, because that one does not abandon the failed node. πŸ’–

And one more for the anxiety files: if a second failure occours (yes, that's how the page spells it πŸ’€) in the middle of a FAILOVER operation, then recovery might be complicated. ngl that's the whole warning. complicated. πŸ™ˆ


🌈 SLONIK EVENT CONFIRMATION BEHAVIOUR 🌈

Slonik will submit the FAILOVER_EVENT without waiting, but then it waits until the most ahead node has received confirmations of the FAILOVER_EVENT from all nodes before completing. so: no patience on the way out, full patience on the way home. balance. ✨


⭐ 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

and that's the whole page bestie 🫢 this was the SLONIK FAILOVER(7) page, straight out of the Slony-I 2.2.11 Documentation, dated 19 September 2024. go forth, fail over responsibly, and don't abandon any nodes you're not ready to lose πŸ’œπŸ¦‹πŸŒΈ

πŸ“¦ where this page comes from