Thu May 12 22:47:05 PDT 2005
- Previous message: [Slony1-commit] By cbbrowne: Parameterize warning/critical times so that they can vary
- Next message: [Slony1-commit] By cbbrowne: Fix typo - database name had "2" omitted
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Log Message:
-----------
Added FAQ item on the recently-discovered HASHES issue
Added docs for a newly-added Nagios check script
Changed a whole bunch of Slony-I references to &slony1;
Modified Files:
--------------
slony1-engine/doc/adminguide:
faq.sgml (r1.35 -> r1.36)
monitoring.sgml (r1.17 -> r1.18)
slonik_ref.sgml (r1.24 -> r1.25)
intro.sgml (r1.16 -> r1.17)
slon.sgml (r1.15 -> r1.16)
-------------- next part --------------
Index: slon.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slon.sgml,v
retrieving revision 1.15
retrieving revision 1.16
diff -Ldoc/adminguide/slon.sgml -Ldoc/adminguide/slon.sgml -u -w -r1.15 -r1.16
--- doc/adminguide/slon.sgml
+++ doc/adminguide/slon.sgml
@@ -29,10 +29,9 @@
<title>Description</title>
<para>
<application>slon</application> is the daemon application that
- <quote>runs</quote> <productname>Slony-I</productname>
- replication. A <application>slon</application> instance must be
- run for each node in a <productname>Slony-I</productname>
- cluster.
+ <quote>runs</quote> &slony1; replication. A
+ <application>slon</application> instance must be run for each node
+ in a &slony1; cluster.
</para>
</refsect1>
Index: monitoring.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/monitoring.sgml,v
retrieving revision 1.17
retrieving revision 1.18
diff -Ldoc/adminguide/monitoring.sgml -Ldoc/adminguide/monitoring.sgml -u -w -r1.17 -r1.18
--- doc/adminguide/monitoring.sgml
+++ doc/adminguide/monitoring.sgml
@@ -62,11 +62,63 @@
</para>
</sect2>
+<sect2> <title> Nagios Replication Checks </title>
+
+<para> The script in the <filename>tools</filename> directory called
+<command> pgsql_replication_check.pl </command> represents about best
+answers yet arrived at in several attempts to build replication tests
+to plug into the <ulink url="http://www.nagios.org/"> Nagios </ulink>
+system monitoring tool.</para>
+
+<para> A former script, <filename>
+test_slony_replication.pl</filename>, took a <quote>clever</quote>
+approach where a <quote>test script</quote> is periodically run, which
+rummages through the &slony1; configuration to find origin and
+subscribers, injects a change, and watches for its propagation through
+the system. It had two problems:</para>
+<itemizedlist>
+
+<listitem><para> Connectivity problems to the
+<emphasis>single</emphasis> host where the test ran would make it look
+as though replication was destroyed. Overall, this monitoring
+approach has been fragile to numerous error conditions.</para>
+</listitem>
+
+<listitem><para> Nagios has no ability to benefit from the
+<quote>cleverness</quote> of automatically exploring the set of nodes.
+</para> </listitem>
+</itemizedlist>
+
+<para> The new script, <command>pgsql_replication_check.pl</command>,
+takes the minimalist approach of assuming that the system is an online
+system that sees regular <quote>traffic,</quote> so that you can
+define a view specifically for the replication test called
+<envar>replication_status</envar> which is expected to see regular
+updates. The view simply looks for the youngest
+<quote>transaction</quote> on the node, and lists its timestamp, age,
+and some bit of application information that might seem useful to see.
+</para>
+
+<itemizedlist>
+
+<listitem><para> In an inventory system, that might be the order
+number for the most recently processed order. </para> </listitem>
+
+<listitem><para> In a domain registry, that might be the name of the
+most recently created domain.</para> </listitem>
+
+</itemizedlist>
+
+<para> An instance of the script will need to be run for each node
+that is to be monitored; that is the way
+<application>Nagios</application> works. </para>
+
+</sect2>
+
<sect2 id="testslonystate"> <title> test_slony_state</title>
<para> This script is in preliminary stages, and may be used to do
-some analysis of the state of a <productname>Slony-I</productname>
-cluster.</para>
+some analysis of the state of a &slony1; cluster.</para>
<para> You specify arguments including <option>database</option>,
<option>host</option>, <option>user</option>,
Index: intro.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/intro.sgml,v
retrieving revision 1.16
retrieving revision 1.17
diff -Ldoc/adminguide/intro.sgml -Ldoc/adminguide/intro.sgml -u -w -r1.16 -r1.17
--- doc/adminguide/intro.sgml
+++ doc/adminguide/intro.sgml
@@ -226,8 +226,8 @@
</sect2>
</sect1>
-<sect1 id="slonylistenercosts"><title>
-<productname>Slony-I</productname> Communications Costs</title>
+<sect1 id="slonylistenercosts"><title> &slony1; Communications
+Costs</title>
<para>The cost of communications grows in a quadratic fashion in
several directions as the number of replication nodes in a cluster
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.24
retrieving revision 1.25
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.24 -r1.25
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -5,7 +5,7 @@
<para>
<application>Slonik</application> is a command line utility designed
specifically to setup and modify configurations of the
- <productname>Slony-I</productname> replication system.
+ &slony1; replication system.
</para>
<sect2 id="outline">
@@ -17,9 +17,9 @@
commands from files or stdin (via here documents for
example). Nearly all of the <emphasis>real</emphasis>
configuration work is done by calling stored procedures after
- loading the <productname>Slony-I</productname> support base into
+ loading the &slony1; support base into
a database. You may find documentation for those procedures in
- the <ulink url="schemadoc"><productname>Slony-I</productname>
+ the <ulink url="schemadoc">&slony1;
Schema Documentation</ulink>, as well as in comments associated
with them in the database.
</para>
@@ -205,7 +205,7 @@
<refnamediv><refname>CLUSTER NAME</refname>
- <refpurpose> preamble - identifying <productname>Slony-I</productname> cluster </refpurpose>
+ <refpurpose> preamble - identifying &slony1; cluster </refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
@@ -218,7 +218,7 @@
<para>
Must be the very first statement in every
<application>slonik</application> script. It defines the
- namespace in which all <productname>Slony-I</productname>
+ namespace in which all &slony1;
specific functions, procedures, tables and sequences are
defined. The namespace name is built by prefixing the given
string literal with an underscore. This namespace will be
@@ -280,7 +280,7 @@
<note> <para>
As mentioned in the original documents,
- <productname>Slony-I</productname> is designed as an enterprise
+ &slony1; is designed as an enterprise
replication system for data centers. It has been assumed
throughout the entire development that the database servers and
administrative workstations involved in replication and/or setup
@@ -380,7 +380,7 @@
</refmeta>
<refnamediv>
<refname>INIT CLUSTER</refname>
- <refpurpose>Initialize <productname>Slony-I</productname> cluster</refpurpose></refnamediv>
+ <refpurpose>Initialize &slony1; cluster</refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>INIT CLUSTER</command>
@@ -392,7 +392,7 @@
<title>Description</title>
<para> Initialize the first node in a new
- <productname>Slony-I</productname> replication cluster. The
+ &slony1; replication cluster. The
initialization process consists of creating the cluster namespace,
loading all the base tables, functions, procedures and
initializing the node, using <xref
@@ -414,11 +414,11 @@
</para>
<para> For this process to work, the SQL scripts of the
- <productname>Slony-I</productname> system must be installed on the
+ &slony1; system must be installed on the
DBA workstation (the computer currently executing the
<application>slonik</application> utility), while on the system
where the node database is running the shared objects of the
- <productname>Slony-I</productname> system must be installed in the
+ &slony1; system must be installed in the
PostgreSQL library directory. Also the procedural language
PL/pgSQL is assumed to already be installed in the target
database.</para>
@@ -446,7 +446,7 @@
<refentry id ="stmtstorenode"><refmeta><refentrytitle>STORE NODE</refentrytitle> </refmeta>
<refnamediv><refname>STORE NODE</refname>
- <refpurpose> Initialize <productname>Slony-I</productname> node </refpurpose>
+ <refpurpose> Initialize &slony1; node </refpurpose>
</refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
@@ -509,7 +509,7 @@
<refnamediv><refname>DROP NODE</refname>
- <refpurpose> Decommission <productname>Slony-I</productname> node </refpurpose></refnamediv>
+ <refpurpose> Decommission &slony1; node </refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>DROP NODE (options);</command>
@@ -561,7 +561,7 @@
<refnamediv><refname>UNINSTALL NODE</refname>
- <refpurpose> Decommission <productname>Slony-I</productname> node </refpurpose></refnamediv>
+ <refpurpose> Decommission &slony1; node </refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>UNINSTALL NODE (options);</command>
@@ -572,8 +572,8 @@
<para> Restores all tables to the unlocked state, with all
original user triggers, constraints and rules, eventually added
- <productname>Slony-I</productname> specific serial key columns
- dropped and the <productname>Slony-I</productname> schema
+ &slony1; specific serial key columns
+ dropped and the &slony1; schema
dropped. The node becomes a standalone database. The data is left
untouched.
@@ -610,7 +610,7 @@
<refnamediv><refname>RESTART NODE</refname>
- <refpurpose> Restart <productname>Slony-I</productname> node </refpurpose></refnamediv>
+ <refpurpose> Restart &slony1; node </refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
@@ -650,7 +650,7 @@
<refnamediv><refname>STORE PATH</refname>
- <refpurpose> Configure <productname>Slony-I</productname> node connection </refpurpose></refnamediv>
+ <refpurpose> Configure &slony1; node connection </refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
@@ -717,7 +717,7 @@
<refnamediv><refname>DROP PATH</refname>
- <refpurpose> Delete <productname>Slony-I</productname> connection information </refpurpose></refnamediv>
+ <refpurpose> Delete &slony1; connection information </refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
@@ -760,7 +760,7 @@
<refnamediv><refname>STORE LISTEN</refname>
- <refpurpose> Configure <productname>Slony-I</productname> node to
+ <refpurpose> Configure &slony1; node to
indicate where to listen for events </refpurpose></refnamediv>
<refsynopsisdiv>
@@ -819,7 +819,7 @@
<refnamediv><refname>DROP LISTEN</refname>
<refpurpose> Eliminate configuration indicating how
- <productname>Slony-I</productname> node listens for events
+ &slony1; node listens for events
</refpurpose></refnamediv>
<refsynopsisdiv>
@@ -864,7 +864,7 @@
<refnamediv><refname>TABLE ADD KEY</refname>
<refpurpose> Add primary key for use by
- <productname>Slony-I</productname> for a table with no suitable
+ &slony1; for a table with no suitable
key </refpurpose></refnamediv>
<refsynopsisdiv>
@@ -876,7 +876,7 @@
<title>Description</title>
<para>
- In the <productname>Slony-I</productname> replication system,
+ In the &slony1; replication system,
every replicated table is required to have at least one
<command>UNIQUE</command> constraint whose columns are
declared <command>NOT NULL.</command> Any primary key
@@ -920,7 +920,7 @@
<refnamediv><refname>CREATE SET</refname>
- <refpurpose> Create <productname>Slony-I</productname> replication
+ <refpurpose> Create &slony1; replication
set </refpurpose></refnamediv>
<refsynopsisdiv>
@@ -932,7 +932,7 @@
<title>Description</title>
<para>
- In the <productname>Slony-I</productname> replication system,
+ In the &slony1; replication system,
replicated tables are organized in sets. As a general rule of
thumb, a set should contain all the tables of one application,
that have relationships. In a well designed application, this is
@@ -942,7 +942,7 @@
The smallest unit one node can subscribe for replication from
another node is a set. A set always has an origin. In
classical replication terms, that would be the <quote>master.</quote>
- Since in <productname>Slony-I</productname> a node can be the <quote>master</quote> over one set,
+ Since in &slony1; a node can be the <quote>master</quote> over one set,
while receiving replication data in the <quote>slave</quote> role for
another at the same time, this terminology may easily become
misleading and should therefore be replaced with <quote>set
@@ -980,7 +980,7 @@
<refnamediv><refname>DROP SET</refname>
- <refpurpose> Discard <productname>Slony-I</productname>
+ <refpurpose> Discard &slony1;
replication set </refpurpose></refnamediv>
<refsynopsisdiv>
@@ -992,7 +992,7 @@
<title>Description</title>
<para>
- Drop a set of tables from the <productname>Slony-I</productname>
+ Drop a set of tables from the &slony1;
configuration. This automatically unsubscribes all nodes from the
set and restores the original triggers and rules on all
subscribers.
@@ -1024,7 +1024,7 @@
<refnamediv><refname>MERGE SET</refname>
- <refpurpose> Merge <productname>Slony-I</productname> replication
+ <refpurpose> Merge &slony1; replication
sets together </refpurpose></refnamediv>
<refsynopsisdiv>
@@ -1075,7 +1075,7 @@
<refnamediv><refname>SET ADD TABLE</refname>
- <refpurpose> Add a table to a <productname>Slony-I</productname>
+ <refpurpose> Add a table to a &slony1;
replication set </refpurpose></refnamediv>
<refsynopsisdiv>
@@ -1154,7 +1154,7 @@
<refnamediv><refname>SET ADD SEQUENCE</refname>
<refpurpose> Add a sequence to a
- <productname>Slony-I</productname> replication set
+ &slony1; replication set
</refpurpose></refnamediv>
<refsynopsisdiv>
@@ -1221,7 +1221,7 @@
<refnamediv><refname>SET DROP TABLE</refname>
<refpurpose> Remove a table from a
- <productname>Slony-I</productname> replication set
+ &slony1; replication set
</refpurpose></refnamediv>
<refsynopsisdiv>
@@ -1269,7 +1269,7 @@
<refnamediv><refname>SET DROP SEQUENCE</refname>
<refpurpose> Remove a sequence from a
- <productname>Slony-I</productname> replication set
+ &slony1; replication set
</refpurpose></refnamediv>
<refsynopsisdiv>
@@ -1314,7 +1314,7 @@
<refnamediv><refname>SET MOVE TABLE</refname>
<refpurpose> Move a table from one
- <productname>Slony-I</productname> replication set to another
+ &slony1; replication set to another
</refpurpose></refnamediv>
<refsynopsisdiv>
@@ -1370,7 +1370,7 @@
<refnamediv><refname>SET MOVE SEQUENCE</refname>
<refpurpose> Move a sequence from one
- <productname>Slony-I</productname> replication set to another
+ &slony1; replication set to another
</refpurpose></refnamediv>
<refsynopsisdiv>
@@ -1431,7 +1431,7 @@
<refnamediv><refname>STORE TRIGGER</refname>
<refpurpose> Indicate that a trigger should not be disabled by
- <productname>Slony-I</productname> on a subscriber node
+ &slony1; on a subscriber node
</refpurpose></refnamediv>
<refsynopsisdiv>
@@ -1536,7 +1536,7 @@
<refnamediv><refname>SUBSCRIBE SET</refname>
- <refpurpose> Start replication of <productname>Slony-I</productname> set </refpurpose></refnamediv>
+ <refpurpose> Start replication of &slony1; set </refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
@@ -1552,7 +1552,7 @@
<para> The application tables contained in the set must already
exist and should ideally be empty. The current version of
- <productname>Slony-I</productname> will <emphasis>not</emphasis>
+ &slony1; will <emphasis>not</emphasis>
attempt to copy the schema of the set. The replication daemon will
start copying the current content of the set from the given
provider and then try to catch up with any update activity that
@@ -1635,7 +1635,7 @@
<refnamediv><refname>UNSUBSCRIBE SET</refname>
- <refpurpose> End replication of <productname>Slony-I</productname> set </refpurpose></refnamediv>
+ <refpurpose> End replication of &slony1; set </refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
@@ -1687,7 +1687,7 @@
<refnamediv><refname>LOCK SET</refname>
- <refpurpose> Guard <productname>Slony-I</productname> replication
+ <refpurpose> Guard &slony1; replication
set to prepare for <command>MOVE SET</command>
</refpurpose></refnamediv>
<refsynopsisdiv>
@@ -1744,7 +1744,7 @@
<refnamediv><refname>UNLOCK SET</refname>
- <refpurpose> Unlock a <productname>Slony-I</productname> set that was locked </refpurpose></refnamediv>
+ <refpurpose> Unlock a &slony1; set that was locked </refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
<command>UNLOCK SET (options);</command>
@@ -1787,7 +1787,7 @@
<refnamediv><refname>MOVE SET</refname>
- <refpurpose> Change origin of a <productname>Slony-I</productname>
+ <refpurpose> Change origin of a &slony1;
replication set </refpurpose></refnamediv>
<refsynopsisdiv>
<cmdsynopsis>
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.35
retrieving revision 1.36
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.35 -r1.36
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -647,7 +647,7 @@
</answer>
</qandaentry>
-<qandaentry>
+<qandaentry id="dupkey">
<question><para>Replication Fails - Unique Constraint Violation</para>
<para>Replication has been running for a while, successfully, when a
@@ -1454,6 +1454,81 @@
</answer>
</qandaentry>
+<qandaentry><question><para> I tried the following query which did not work:</para>
+
+<programlisting>
+sdb=# explain select query_start, current_query from pg_locks join
+pg_stat_activity on pid = procpid where granted = true and transaction
+in (select transaction from pg_locks where granted = false);
+
+ERROR: could not find hash function for hash operator 716373
+</programlisting>
+
+<para> It appears the &slony1; <function>xxid</function> functions are
+claiming to be capable of hashing, but cannot actually do so.</para>
+
+
+<para> What's up? </para>
+
+</question>
+
+<answer><para> &slony1; defined an XXID data type and operators on
+that type in order to allow manipulation of transaction IDs that are
+used to group together updates that are associated with the same
+transaction.</para>
+
+<para> Operators were not available for &postgres; 7.3 and earlier
+versions; in order to support version 7.3, custom functions had to be
+added. The <function>=</function> operator was marked as supporting
+hashing, but for that to work properly, the join operator must appear
+in a hash index operator class. That was not defined, and as a
+result, queries (like the one above) that decide to use hash joins
+will fail. </para> </answer>
+
+<answer> <para> This has <emphasis> not </emphasis> been considered a
+<quote>release-critical</quote> bug, as &slony1; does not internally
+generate queries likely to use hash joins. This problem shouldn't
+injure &slony1;'s ability to continue replicating. </para> </answer>
+
+<answer> <para> Future releases of &slony1; (<emphasis>e.g.</emphasis>
+1.0.6, 1.1) will omit the <command>HASHES</command> indicator, so that
+</para> </answer>
+
+<answer> <para> Supposing you wish to repair an existing instance, so
+that your own queries will not run afoul of this problem, you may do
+so as follows: </para>
+
+<programlisting>
+/* cbbrowne@[local]/dba2 slony_test1=*/ \x
+Expanded display is on.
+/* cbbrowne@[local]/dba2 slony_test1=*/ select * from pg_operator where oprname = '='
+and oprnamespace = (select oid from pg_namespace where nspname = 'public');
+-[ RECORD 1 ]+-------------
+oprname | =
+oprnamespace | 2200
+oprowner | 1
+oprkind | b
+oprcanhash | t
+oprleft | 82122344
+oprright | 82122344
+oprresult | 16
+oprcom | 82122365
+oprnegate | 82122363
+oprlsortop | 82122362
+oprrsortop | 82122362
+oprltcmpop | 82122362
+oprgtcmpop | 82122360
+oprcode | "_T1".xxideq
+oprrest | eqsel
+oprjoin | eqjoinsel
+
+/* cbbrowne@[local]/dba2 slony_test1=*/ update pg_operator set oprcanhash = 'f' where
+oprname = '=' and oprnamespace = 2200 ;
+UPDATE 1
+</programlisting>
+</answer>
+
+</qandaentry>
</qandaset>
<!-- Keep this comment at the end of the file Local variables:
- Previous message: [Slony1-commit] By cbbrowne: Parameterize warning/critical times so that they can vary
- Next message: [Slony1-commit] By cbbrowne: Fix typo - database name had "2" omitted
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list