CVS User Account cvsuser
Tue Nov 23 23:34:00 PST 2004
Log Message:
-----------
Added more docs on "altperl" tools

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        SlonyAdministrationScripts.txt (r1.1 -> r1.2)

-------------- next part --------------
Index: SlonyAdministrationScripts.txt
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/SlonyAdministrationScripts.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -Ldoc/adminguide/SlonyAdministrationScripts.txt -Ldoc/adminguide/SlonyAdministrationScripts.txt -u -w -r1.1 -r1.2
--- doc/adminguide/SlonyAdministrationScripts.txt
+++ doc/adminguide/SlonyAdministrationScripts.txt
@@ -1,4 +1,4 @@
-%META:TOPICINFO{author="guest" date="1098117183" format="1.0" version="1.2"}%
+%META:TOPICINFO{author="guest" date="1101222000" format="1.0" version="1.3"}%
 %META:TOPICPARENT{name="SlonyIAdministration"}%
 ---++ Slony Administration Scripts
 
@@ -12,11 +12,148 @@
 
 What variables are set up...
 
+	* $SETNAME=orglogs;	# What is the name of the replication set?
+	* $LOGDIR='/opt/OXRS/log/LOGDBS';  # What is the base directory for logs?
+	* $SLON_BIN_PATH='/opt/dbs/pgsql74/bin';  # Where to look for slony binaries
+	* $APACHE_ROTATOR="/opt/twcsds004/OXRS/apache/rotatelogs";  # If set, where to find Apache log rotator
+
+You then define the set of nodes that are to be replicated using a set of calls to add_node().
+<verbatim>
+  add_node (host => '10.20.30.40', dbname => 'orglogs', port => 5437,
+			  user => 'postgres', node => 4, parent => 1);
+</verbatim>
+
+The set of parameters for add_node() are thus:
+<verbatim>
+  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?
+			 );
+</verbatim>
 ---+++ 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.pl, to control what tables will be 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.pl, as that is the only script used to control what tables will be in a particular replication set.
 
 What variables are set up...
 
+	* $TABLE_ID = 44;	 Each table must be identified by a unique number; this variable controls where numbering starts
+	* @PKEYEDTABLES		An array of names of tables to be replicated that have a defined primary key so that Slony-I can automatically select its key
+	* %KEYEDTABLES		 A hash table of tables to be replicated, where the hash index is the table name, and the hash value is the name of a unique not null index suitable as a "candidate primary key."
+	* @SERIALTABLES		An array of names of tables to be replicated that have no candidate for primary key.  Slony-I will add a key field based on a sequence that Slony-I generates
+	* @SEQUENCES			An array of names of sequences that are to be replicated
+
+---+++ build_env.pl
+
+Queries a database, generating output hopefully suitable for
+"slon.env" consisting of:
+
+	* a set of add_node() calls to configure the cluster
+	* The arrays @KEYEDTABLES, @SERIALTABLES, and @SEQUENCES
+
+---+++ create_set.pl
+
+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.
+
+---+++ drop_node.pl
+
+Generates Slonik script to drop a node from a Slony-I cluster.
+
+---+++ drop_set.pl
+
+Generates Slonik script to drop a replication set (e.g. - set of tables and sequences) from a Slony-I cluster.
+
+---+++ failover.pl
+
+Generates Slonik script to request failover from a dead node to some new origin
+
+---+++ init_cluster.pl
+
+Generates Slonik script to initialize a whole Slony-I cluster,
+including setting up the nodes, communications paths, and the listener
+routing.
+
+---+++ merge_sets.pl
+
+Generates Slonik script to merge two replication sets together.
+
+---+++ move_set.pl
+
+Generates Slonik script to move the origin of a particular set to a different node.
+
+---+++ replication_test.pl
+
+Script to test whether Slony-I is successfully replicating data.
+
+---+++ restart_node.pl
+
+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.
+
+---+++ restart_nodes.pl
+
+Generates Slonik script to restart all nodes in the cluster.  Not
+particularly useful...
+
+---+++ show_configuration.pl
+
+Displays an overview of how the environment (e.g. - SLONYNODES) is set
+to configure things.
+
+---+++ slon_kill.pl
+
+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!
+
+---+++ slon_pushsql.pl
+
+Generates Slonik script to push DDL changes to a replication set.
+
+---+++ slon_start.pl
+
+This starts a slon daemon for the specified cluster and node, and uses
+slon_watchdog.pl to keep it running.
+
+---+++ slon_watchdog.pl
+
+Used by slon_start.pl...
+
+---+++ slon_watchdog2.pl
+
+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...
+
+---+++ subscribe_set.pl
+
+Generates Slonik script to subscribe a particular node to a particular replication set.
+
+---+++ uninstall_nodes.pl
+
+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!
+
+---+++ unsubscribe_set.pl
+
+Generates Slonik script to unsubscribe a node from a replication set.
+
+---+++ update_nodes.pl
+
+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.
+


More information about the Slony1-commit mailing list