18. Slony-I Administration Scripts

In the altperl directory in the CVS tree, there is a sizable set of Perl scripts that may be used to administer a set of Slony-I instances, which support having arbitrary numbers of nodes.

Most of them generate Slonik scripts that are then to be passed on to the slonik utility to be submitted to all of the Slony-I nodes in a particular cluster. At one time, this embedded running slonik on the slonik scripts. Unfortunately, this turned out to be a pretty large calibre "foot gun", as minor typos on the command line led, on a couple of occasions, to pretty calamitous actions, so the behavior has been changed so that the scripts simply submit output to standard output. The savvy administrator should review the script before submitting it to slonik.

18.1. Node/Cluster Configuration - cluster.nodes

The UNIX environment variable SLONYNODES is used to determine what Perl configuration file will be used to control the shape of the nodes in a Slony-I cluster.

What variables are set up.

You then define the set of nodes that are to be replicated using a set of calls to add_node().

add_node (host => '10.20.30.40', dbname => 'orglogs', port => 5437, user => 'postgres', node => 4, parent => 1);

The set of parameters for add_node() are thus:

my %PARAMS =   (host=> undef,		# Host name
	   	dbname => 'template1',	# database name
		port => 5432,		# Port number
		user => 'postgres',	# user to connect as
		node => undef,		# node number
		password => undef,	# password for user
		parent => 1,		# which node is parent to this node
		noforward => undef	# shall this node be set up to forward results?
                sslmode => undef        # SSL mode argument - determine 
                                        # priority of SSL usage
                                        # = disable,allow,prefer,require
);

18.2. Set configuration - cluster.set1, cluster.set2

The UNIX environment variable SLONYSET is used to determine what Perl configuration file will be used to determine what objects will be contained in a particular replication set.

Unlike SLONYNODES, which is essential for all of the slonik-generating scripts, this only needs to be set when running create_set, as that is the only script used to control what tables will be in a particular replication set.

What variables are set up.

18.3. slonik_build_env

Queries a database, generating output hopefully suitable for slon_tools.conf consisting of:

18.4. slonik_create_set

This requires SLONYSET to be set as well as SLONYNODES; it is used to generate the slonik script to set up a replication set consisting of a set of tables and sequences that are to be replicated.

18.5. slonik_drop_node

Generates Slonik script to drop a node from a Slony-I cluster.

18.6. slonik_drop_set

Generates Slonik script to drop a replication set (e.g. - set of tables and sequences) from a Slony-I cluster.

18.7. slonik_execute_script

Generates Slonik script to push DDL changes to a replication set.

18.8. slonik_failover

Generates Slonik script to request failover from a dead node to some new origin

18.9. slonik_init_cluster

Generates Slonik script to initialize a whole Slony-I cluster, including setting up the nodes, communications paths, and the listener routing.

18.10. slonik_merge_sets

Generates Slonik script to merge two replication sets together.

18.11. slonik_move_set

Generates Slonik script to move the origin of a particular set to a different node.

18.12. replication_test

Script to test whether Slony-I is successfully replicating data.

18.13. slonik_restart_node

Generates Slonik script to request the restart of a node. This was particularly useful pre-1.0.5 when nodes could get snarled up when slon daemons died.

18.14. slonik_restart_nodes

Generates Slonik script to restart all nodes in the cluster. Not particularly useful.

18.15. slony_show_configuration

Displays an overview of how the environment (e.g. - SLONYNODES) is set to configure things.

18.16. slon_kill

Kills slony watchdog and all slon daemons for the specified set. It only works if those processes are running on the local host, of course!

18.17. slon_start

This starts a slon daemon for the specified cluster and node, and uses slon_watchdog to keep it running.

18.18. slon_watchdog

Used by slon_start.

18.19. slon_watchdog2

This is a somewhat smarter watchdog; it monitors a particular Slony-I node, and restarts the slon process if it hasn't seen updates go in in 20 minutes or more.

This is helpful if there is an unreliable network connection such that the slon sometimes stops working without becoming aware of it.

18.20. slonik_store_node

Adds a node to an existing cluster.

18.21. slonik_subscribe_set

Generates Slonik script to subscribe a particular node to a particular replication set.

18.22. slonik_uninstall_nodes

This goes through and drops the Slony-I schema from each node; use this if you want to destroy replication throughout a cluster. This is a VERY unsafe script!

18.23. slonik_unsubscribe_set

Generates Slonik script to unsubscribe a node from a replication set.

18.24. slonik_update_nodes

Generates Slonik script to tell all the nodes to update the Slony-I functions. This will typically be needed when you upgrade from one version of Slony-I to another.

18.25. regenerate-listens

This script connects to a Slony-I node, and queries various tables (sl_set, sl_node, sl_subscribe, sl_path) to compute what STORE LISTEN requests should be submitted to the cluster.

See the documentation in Section 8.3 for more details on how this works.