SLONIK_MOVE_SET(7)

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

πŸ’… MOVE SET β€” slonik's "we're switching the main character" era

okay bestie, this is the SLONIK MOVE SET(7) page from the Slony-I 2.2.11 docs, and we're about to move a whole replication set's origin from one node to another. no cap, it's iconic. let's get into it πŸ¦‹


✨ NAME ✨

MOVE SET β€” change the origin of a Slony-I replication set πŸ’«


πŸŽ€ SYNOPSIS πŸŽ€

MOVE SET (options);

🌸 DESCRIPTION 🌸

so basically: this changes the origin of a set from one node to another. the new origin has to be a current subscriber of the set, and the set must currently be locked on the old origin. like, that's the vibe check it has to pass. πŸ”’

after this command runs, the set cannot be unlocked on the old origin anymore. the old origin keeps living its life as a forwarding subscriber of the set, and the subscription chain from the old origin to the new origin gets reversed, hop by hop. as soon as the new origin finishes processing the event β€” and yes, that includes any outstanding sync events that happened before, i.e. it fully catching up β€” the new origin takes over and opens all the tables in the set for client application update activity. main character moment fr. πŸ‘‘

okay important: this is NOT failover. it needs a functioning old origin node (that's the whole reason you had to lock the set on the old origin in the first place). you'd probably rather MOVE SET than FAILOVER if at all possible, because FAILOVER winds up discarding the old origin node as being corrupted. πŸ’€ and before MOVE SET will even function, you need a LOCK SET. periodt.

also heads up: this is a locking operation, which means it can get stuck behind other database activity. it's giving "waiting in line at the boba shop". πŸ™ˆ


🧚 the arguments (yes, all of them) 🧚

  • 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 schemadocmoveset(p_new_origin integer, p_set_id integer) [not available as a man page]. iykyk.


⭐ EXAMPLE ⭐

here's the whole serve, in order:

LOCK SET (
   ID = 1,
   ORIGIN = 1
);
MOVE SET (
   ID = 1,
   OLD ORIGIN = 1,
   NEW ORIGIN = 3
);

lock it first, bestie. don't skip the LOCK SET. 😭


πŸ”’ LOCKING BEHAVIOUR πŸ”’

exclusive locks on each replicated table will be taken out on both the old origin node and the new origin node, because replication triggers get 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

it's giving glow-up but for triggers. ✨


🫢 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. it's polite like that. πŸ’–


🌈 VERSION INFORMATION 🌈

this command was introduced in Slony-I 1.0. vintage. an OG. πŸ‘‘


and that's the whole page, bestie!! this was Slony-I 2.2.11 Documentation, dated 19 September 2024, and honestly? iconic. go move that set. mwah πŸ’…πŸ’–βœ¨

πŸ“¦ where this page comes from