SLONIK_STORE_NODE(7)

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

✨ NAME ✨

STORE NODE β€” the glow-up ritual that initializes a Slony-I node πŸŽ€

okay so real quick, this is slonik page seven, SLONIK STORE NODE(7), straight out of the Slony-I 2.2.11 docs. bestie, buckle up πŸ’…


🌸 SYNOPSIS 🌸

STORE NODE (options);

πŸ¦‹ DESCRIPTION πŸ¦‹

So basically: you got a cluster already living its life, and you wanna bring a brand new node into the group chat. STORE NODE is the way you do that. It initializes the new node and adds it to the configuration of an existing cluster. ✨

Here's the whole ritual, step by step: it creates the cluster namespace in the new node (heads up β€” the database itself must already exist, it does NOT make one for you), it loads all the base tables, functions, procedures, and it initializes the node. Then the existing configuration of the rest of the cluster gets copied over from the β€˜event node’. that's the vibe. 🫢

Now the parameters, one by one, no skips:

  • ID = ival β€” the unique, immutable numeric ID number of the new node. and yeah, immutable matters here, because that ID is literally the basis for inter-node event communications. so don't be out here thinking you can change it later. you cannot. it's giving permanent. πŸ’€
  • COMMENT = 'description' β€” a descriptive text added to the node entry in the table sl_node [not available as a man page]. cute lil name tag for your node, love that for you.
  • SPOOLNODE = boolean β€” says that the new node is a virtual spool node for file archiving of replication log. if it's true, slonik will not attempt to initialize a database with the replication schema.
⚠️ Warning, and I mean it: Never use the SPOOLNODE value. No released version of Slony-I has ever behaved in the fashion described in the preceding fashion. Log shipping, as it finally emerged in 1.2.11, does not require initializing β€˜spool nodes’. like, just don't. it's a trap. 🚩
  • EVENT NODE = ival β€” the ID of the node used to create the configuration event that tells all existing nodes about the new node. it must be the ID of a pre-existing node in the cluster, NOT the ID of the new node. do not put the new node's ID here, I'm begging πŸ™ˆ

and for the record, this whole thing uses schemadocinitializelocalnode(p_comment integer, p_local_node_id text) [not available as a man page] and schemadocenablenode(p_no_id integer) [not available as a man page]. those are the actual functions doing the work behind the scenes. main characters fr fr. πŸ‘‘


πŸ“ EXAMPLE πŸ“

STORE NODE ( ID = 2, COMMENT = 'Node 2', EVENT NODE = 1 );

see how EVENT NODE = 1 is the existing one and ID = 2 is the new baby? yeah. that's the pattern. 🧚


πŸ’œ LOCKING BEHAVIOUR πŸ’œ

This command creates a new namespace and configures tables therein. no public objects should be locked during the duration of this. so like, chill, nothing public is getting locked, no cap. ✨


⭐ 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. so it's patient. it waits its turn. iconic behavior honestly. πŸŽ€


πŸ‘‘ VERSION INFORMATION πŸ‘‘

  • This command was introduced in Slony-I 1.0.
  • The SPOOLNODE parameter was introduced in version 1.1, but was vestigial in that version.
  • The described functionality for SPOOLNODE arrived in version 1.2, but SPOOLNODE was not used for this purpose.
  • In later versions, hopefully SPOOLNODE will be unavailable. (fingers crossed bestie 🀞)
  • In version 2.0, the default value for EVENT NODE was removed, so a node must be specified. no more vibing without it. periodt.

πŸ’– that's the whole page!! every flag, every warning, every version note, all of it. now go initialize that node, you absolute legend. 🌈

slay, and remember: the docs are from Slony-I 2.2.11 Documentation, and this page is dated 19 September 2024, filed under SLONIK STORE NODE(7). mwah πŸ’…

πŸ“¦ where this page comes from