The attach patches: - attempt to improve the section introducing altperl - integrate an altperl example into the section on configuring your first DB for replication.
Mark
Tue Jan 30 12:13:05 EST 2007 [EMAIL PROTECTED] * provide examples of using the altperl scripts for initial replication set up. diff -rN -u old-slony1-1.2.5/doc/adminguide/firstdb.sgml new-slony1-1.2.5/doc/adminguide/firstdb.sgml --- old-slony1-1.2.5/doc/adminguide/firstdb.sgml 2007-01-30 12:15:03.000000000 -0500 +++ new-slony1-1.2.5/doc/adminguide/firstdb.sgml 2007-01-30 12:15:04.000000000 -0500 @@ -139,7 +139,46 @@ <para>Creating the configuration tables, stored procedures, triggers and configuration is all done through the <xref linkend="slonik"> tool. It is a specialized scripting aid that mostly calls stored -procedures in the master/slave (node) databases. The script to create +procedures in the master/slave (node) databases. </para> +</sect2> + +<sect3><title>Using the altperl scripts</title> + +<para> +Using the <xref linkend="altperl"> scripts is an easy way to get started. The +<command>slonik_build_env</command> script will generate output providing +details you need to omplete building a <filename>slon_tools.conf</filename>. +An example <filename>slon_tools.conf</filename> is provided in the distribution +to get you started. The altperl scripts will all reference +this central configuration file in the future to ease administration. Once +slon_tools.conf has been created, you can proceed as follows: +</para> + +<programlisting> +# Initialize cluster: +$ slonik_init_cluster | slonik + +# Start slon (here 1 and 2 are node numbers) +$ slon_start 1 +$ slon_start 2 + +# Create Sets (here 1 is a set number) +$ slonik_create_set 1 + +# subscribe set to second node (1= set ID, 2= node ID) +$ slonik_subscribe_set 2 | slonik +</programlisting> + +You have now replicated your first database. You can skip the following section +of documentation if you'd like, which documents a more bare-metal approach. +</sect3> + +<sect3><title>Using slonik command directly</title> +The traditional approach to administering slony is to craft slonik +commands directly. An example of this given here. + + +The script to create the initial configuration for the simple master-slave setup of our <application>pgbench</application> database looks like this: @@ -272,6 +311,8 @@ are tuned and maintained, this catchup process can be a matter of minutes, hours, or eons.</para> +</sect3> + <para>You have now successfully set up your first basic master/slave replication system, and the 2 databases should, once the slave has caught up, contain identical data. That's the theory, at least. In
Tue Jan 30 11:52:31 EST 2007 [EMAIL PROTECTED] * PATCH: attempt to improve the docs introducing altperl diff -rN -u old-slony1-1.2.5/doc/adminguide/adminscripts.sgml new-slony1-1.2.5/doc/adminguide/adminscripts.sgml --- old-slony1-1.2.5/doc/adminguide/adminscripts.sgml 2007-01-30 12:14:53.000000000 -0500 +++ new-slony1-1.2.5/doc/adminguide/adminscripts.sgml 2007-01-30 12:14:53.000000000 -0500 @@ -13,23 +13,26 @@ <indexterm><primary>altperl scripts for &slony1;</primary></indexterm> -<para>In the <filename>altperl</filename> directory in the -<application>CVS</application> tree, there is a sizable set of -<application>Perl</application> scripts that may be used to administer -a set of &slony1; instances, which support having arbitrary numbers of -nodes.</para> - -<para>Most of them generate Slonik scripts that are then to be passed -on to the <xref linkend="slonik"> utility to be submitted to all of -the &slony1; nodes in a particular cluster. At one time, this -embedded running <xref linkend="slonik"> on the slonik scripts. +<para>There is a set of scripts to simplify administeration +of set of &slony1; instances. The scripts support having arbitrary numbers of +nodes. They may be installed as part of the installation process:</para> + +<para><command> + ./configure --with-perltools +</command></para> + +<para>This will produce a number of scripts with the prefix <command>slonik_</command>. +They eliminate tedium by always referring to a central configuration file +for the details of your site configuration. Most also include some command +line help with the "-h" option, making them easier to learn and use. +</para> + +<para>Most generate Slonik scripts that are printed to STDOUT. +At one time, the commands were passed directly to <xref linkend="slonik"> for execution. Unfortunately, this turned out to be a pretty large calibre <quote>foot gun</quote>, 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 -<emphasis>before</emphasis> submitting it to <xref -linkend="slonik">.</para> +couple of occasions, to pretty calamitous actions. The savvy administrator should review the script +<emphasis>before</emphasis> piping it to <xref linkend="slonik">.</para> <sect3><title>Node/Cluster Configuration - cluster.nodes</title> <indexterm><primary>cluster.nodes - node/cluster configuration for Perl tools</primary></indexterm>
_______________________________________________ Slony1-general mailing list [email protected] http://gborg.postgresql.org/mailman/listinfo/slony1-general
