Skip to content
This repository has been archived by the owner on Sep 15, 2022. It is now read-only.

Commit

Permalink
Slony-I documentation
Browse files Browse the repository at this point in the history 
git-svn-id: svn://svn.pgadmin.org/trunk@4508 a7884b65-44f6-0310-8a51-81a127f17b15
  • Loading branch information
Andreas Pflug committed Oct 5, 2005
1 parent e18923a commit 69139db
Show file tree
Hide file tree
Showing 201 changed files with 20,858 additions and 0 deletions.
1 change: 1 addition & 0 deletions docs/en_US/index.html
View file
Expand Up @@ -26,6 +26,7 @@ <H3>pgAdmin III</H3>
<UL>
<LI><A HREF="using.html">Using pgAdmin III</A><BR>&nbsp;</LI>
<LI><A HREF="pgagent.html">pgAgent</A> - a job scheduler for PostgreSQL.<BR>&nbsp;</LI>
<LI><A HREF="slony.html">Slony-I support</A> - The master-slave replication solution for PostgreSQL.<BR>&nbsp;</LI>
<LI><A HREF="extend.html">Extended features</A> - a contrib module for PostgreSQL to extend pgAdmin's functionality.<BR>&nbsp;</LI>
<LI><A HREF="appendices.html">Appendices</A> - bug reporting, licence info etc.<BR>&nbsp;</LI>
</UL>
Expand Down
Binary file modified docs/en_US/pgadmin3.hhp.cached
View file
Binary file not shown.
62 changes: 62 additions & 0 deletions docs/en_US/slony-install.html
View file
@@ -0,0 +1,62 @@
<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<link rel="STYLESHEET" type="text/css" href="pgadmin3.css">
<title>Slony-I administration with pgAdmin III: overview</title>
</head>

<body>
<h3>Slony-I administration with pgAdmin III: overview</h3>
<BR>
<H4>Prerequisites</H4>
<p>
As a prerequisite to running Slony-I on PostgreSQL, the slony modules
xxid and slony1_funcs must be present on all servers that have are to run a
Slony-I replication node. This is usually done by the Slony-I installation routine. In case you're installing
a PostgreSQL 8.1 server on Win32, the windows installer routine can do this
for you if you select the "Slony-I" installation option.
</p>
<BR><BR>
<center><img src="images/slony-create.png"></center>

<p>
To install a Slony-I cluster on the first database, the "New Slony-I Cluster" dialog is
used. It executes the official Slony-I cluster creation scripts, which are located in the
directory configured in the <A HREF="options-tab1.html">options</A> dialog.
</p>
<p>
pgAdmin III needs to store information how to contact each individual node in the cluster.
To achieve this, pgAdmin III uses the concept of "Administrative nodes".

</p>
<center><img src="images/slony-join.png"></center>
<p>
After the first node in the Slony-I replication cluster has been successfully created,
all subsequent nodes take their configuration and procedures from the first nodes.
This process is called "Joining a cluster" in pgAdmin III. Usually, you should also select
an existing node as admin node, to insure later accessibility from pgAdmin III.
<p>
</p>
After you added a new node to the Slony-I cluster, you need to set up
<A href='"slony-path.html'>replication paths</A> between the nodes, to enable communication
between the nodes.
</p>
<center><img src="images/slony-upgrade.png"></center>
<p>
When a cluster is to be upgraded to a new version of the Slony-I clustering software,
the upgrade process has to be run on all nodes of the cluster. For each node, the slon
daemon needs to be stopped, then the upgrade dialog is started and a node with
the new software is selected (pgAdmin III will extract all software from that node),
and finally the slon daemon is started again.
</p>
<p>
Currently, pgAdmin III does <B>not</B> support upgrading from slony creation scripts.
Instead, create an intermediate cluster from the creation scripts, use it as a source
for the upgrade dialog, and drop the cluster after usage. You may also use the slonik
tool to upgrade the first node, and then use it as source for subsequent node upgrades.
</p>
<p>
</p>
</body>
</html>
30 changes: 30 additions & 0 deletions docs/en_US/slony-overview.html
View file
@@ -0,0 +1,30 @@
<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<link rel="STYLESHEET" type="text/css" href="pgadmin3.css">
<title>Slony-I with pgAdmin III overview</title>
</head>

<body>

<h3>Slony-I with pgAdmin III overview</h3>

<center><img src="images/slony-overview.png"></center>

<p>
The Slony-I objects are integrated into pgAdmin's main object tree browser, allowing
a single interface to both database object and replication administration.
</p>
<p>
The statistics tab for the nodes collection as well as for individual nodes show
the status of the replication event queue, and allows monitoring of the functionality
of the slony cluster.
</p>
<p>
As an example, the situation shown above displays the status of a node that hasn't
been responsive for about an hour, with 381 events pending to be replicated to that
node.
</p>
</body>
</html>
29 changes: 29 additions & 0 deletions docs/en_US/slony-path.html
View file
@@ -0,0 +1,29 @@
<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<link rel="STYLESHEET" type="text/css" href="pgadmin3.css">
<title>Creating paths and listens</title>
</head>

<body>
<h3>Creating paths and listens</h3>

<center><img src="images/slony-path.png"></center>

<p>
Slony-I needs path information, that defines how a slon process can communicate to
other nodes. The conninfo string takes a connect string as described in the
<a href='pg/libpq.html#LIBPQ-CONNECT'>libpq connection</A> documentation.
Usually, you will need to specify host, dbname and username, while the password should
be stored in the <a href='pg/libpq-pgpass.html'>.pgpass file</A>.
</p>
<BR>
<center><img src="images/slony-listen.png"></center>
<p>
After the communication path has been defined, the slon processes need to be
advised to listen to events from other nodes. This step is not necessary for Slony-I V1.1
and later, because listen information is generated automatically when paths are defined.
</p>
</body>
</html>
57 changes: 57 additions & 0 deletions docs/en_US/slony-set.html
View file
@@ -0,0 +1,57 @@
<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<link rel="STYLESHEET" type="text/css" href="pgadmin3.css">
<title>Creating sets and subscriptions</title>
</head>

<body>
<h3>Creating sets and subscriptions</h3>

<center><img src="images/slony-set.png"></center>

<p>
Slony-I groups tables and sequences it has to replicate from a master to slaves into
replication sets. The set is created on the source node of the data.
</p>
<BR>
<center><img src="images/slony-table.png"></center>
<p>
If the source table has triggers defined on it, these have to be disabled on replication
target nodes. But in replication environments, the master and slave roles might exchange,
so it is necessary to enable and disable triggers in those situations. The 'Trigger' page
allows selection of triggers that Slony-I should enable and disable if necessary.
</p>
<p>
<B>Attention</B>: If a table you'd like to have replicated doesn't appear in the table combobox,
this usually means that the table lacks a unique index. Slony-I requires that each row
in tables that are to be replicated must be uniquely identifyable. Usually, this should be done
with a primary key, but for replication purposes a unique key is satisfactory.
</p>
<p>
While Slony-I has a helper function to define intermediate unique keys, this is not supported
with tables added to replication sets with pgAdmin III. We strongly recommend defining
a primary key on the tables to be replicated.
</p>
<BR>
<center><img src="images/slony-sequence.png"></center>
<p>
The sequence allows adding sequences to a replication set.
</p>
<BR>
<center><img src="images/slony-subscription.png"></center>
<p>
After a replication set has been defined, it can be subscribed. Subscriptions have to
be created on the source node (note: on Slony-1 before V1.1, this had to be performed on the
target node).
</p><p>
After a set has been subscribed, its table and sequence definition can't be changed
any more. To add more tables, you can create a set that includes the additional tables
and sequences you'd like to have added to the first replication set, then subscribe
exactly the same receiver nodes to it, and finally use
<A HREF="slony-functions.html#merge">Merge</A> to merge both sets
into one.
</p>
</body>
</html>
35 changes: 35 additions & 0 deletions docs/en_US/slony.html
View file
@@ -0,0 +1,35 @@
<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<link rel="STYLESHEET" type="text/css" href="pgadmin3.css">
<title>pgAgent</title>
</head>

<body>

<H3>Slony-I support</H3>
<P>pgAdmin III includes a frontend to Slony-I, the most popular master-slave
replication solution for PostgreSQL. pgAdmin III makes maintaining the replication
setup easier, and features health information to monitor the state of the cluster.</P>

<UL>
<LI><P><A HREF="slony-overview.html">Overview</A> - pgAdmin implements
many functions of the slonik tool with a user friendly interface.</P>
<LI><P><A HREF="slony-install.html">Installation</A> - Installation and
upgrade of Slony-I replication is implemented.</P>
<LI><P><A HREF="slony-path.html">Creating paths and listens</A> -
Create communication paths between nodes.</P>
<LI><P><A HREF="slony-set.html">Creating sets and subscriptions</A> - Managing
Slony-I replication sets and subscriptions.</P>
<LI><P><A HREF="slony-functions.html">Maintenance</A> - Additional
functions to maintain the cluster.</P>
</P>
</UL>
<BR>
<p>
For further information, please refer to the official <A HREF="slony/index.html">Slony-I documentation</A>
which is embedded in this help.
</p>
</BODY>
</HTML>
57 changes: 57 additions & 0 deletions docs/en_US/slony/addthings.html
View file
@@ -0,0 +1,57 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>11. Adding Things to Replication</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.66.1">
<link rel="start" href="index.html" title="Slony-I HEAD_20050707 Documentation">
<link rel="up" href="slonyadmin.html" title=" Slony-I Administration ">
<link rel="prev" href="locking.html" title="10. Locking Issues">
<link rel="next" href="dropthings.html" title="12. Dropping things from Slony-I Replication">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="addthings"></a>11. Adding Things to Replication</h2></div></div></div>
<p>You may discover that you have missed replicating things that
you wish you were replicating.</p>
<p>This can be fairly easily remedied.</p>
<p>You cannot directly use <a href="slonik.html" title="slonik"><span class="refentrytitle"><a name="app-slonik-title"></a><span class="application">slonik</span></span></a>
<a href="stmtsetaddtable.html" title="SET ADD TABLE"><span class="refentrytitle">SET ADD TABLE</span></a> or <a href="stmtsetaddsequence.html" title="SET ADD SEQUENCE"><span class="refentrytitle">SET ADD SEQUENCE</span></a>
in order to add tables and sequences
to a replication set that is presently replicating; you must instead
create a new replication set. Once it is identically subscribed
(e.g. - the set of providers and subscribers is <span class="emphasis"><em>entirely
identical</em></span> to that for the set it is to merge with), the
sets may be merged together using <a href="stmtmergeset.html" title="MERGE
SET"><span class="refentrytitle">MERGE
SET</span></a>.</p>
<p>Up to and including 1.0.2, there was a potential problem where
if <a href="stmtmergeset.html" title="MERGE
SET"><span class="refentrytitle">MERGE
SET</span></a> is issued while other
subscription-related events are pending, it is possible for things to
get pretty confused on the nodes where other things were pending.
This problem was resolved in 1.0.5.</p>
<p> Note that if you add nodes, you will need to add both <a href="stmtstorepath.html" title="STORE
PATH"><span class="refentrytitle">STORE
PATH</span></a> statements to indicate how nodes communicate
with one another, and <a href="stmtstorelisten.html" title="STORE LISTEN"><span class="refentrytitle">STORE LISTEN</span></a> statements to
configuration the &#8220;<span class="quote">communications network</span>&#8221; that results
from that. See <a href="listenpaths.html" title="8. Slony-I listen paths">Section 8, &#8220;<span class="productname">Slony-I</span> listen paths&#8221;</a> for more details on the
latter.</p>
<p>It is suggested that you be very deliberate when adding such
things. For instance, submitting multiple subscription requests for a
particular set in one <a href="slonik.html" title="slonik"><span class="refentrytitle"><a name="app-slonik-title"></a><span class="application">slonik</span></span></a> script often turns out
quite badly. If it is <span class="emphasis"><em>truly</em></span> necessary to
automate this, you'll probably want to submit <a href="stmtwaitevent.html" title="WAIT FOR EVENT"><span class="refentrytitle">WAIT FOR EVENT</span></a> requests in between subscription requests in
order that the <a href="slonik.html" title="slonik"><span class="refentrytitle"><a name="app-slonik-title"></a><span class="application">slonik</span></span></a> script wait for one
subscription to complete processing before requesting the next
one.</p>
<p>But in general, it is likely to be easier to cope with complex
node reconfigurations by making sure that one change has been
successfully processed before going on to the next. It's way easier
to fix one thing that has broken than to piece things together after
the interaction of five things that have all broken.</p>
</div></body>
</html>
72 changes: 72 additions & 0 deletions docs/en_US/slony/admconninfo.html
View file
@@ -0,0 +1,72 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>ADMIN CONNINFO</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.66.1">
<link rel="start" href="index.html" title="Slony-I HEAD_20050707 Documentation">
<link rel="up" href="hdrcmds.html" title="Slonik Preamble Commands">
<link rel="prev" href="clustername.html" title="CLUSTER NAME">
<link rel="next" href="cmds.html" title="Configuration and Action commmands">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="refentry" lang="en">
<a name="admconninfo"></a><div class="titlepage"></div>
<div class="refnamediv">
<h2>Name</h2>
<p>ADMIN CONNINFO &#8212; preamble - identifying <span class="productname">PostgreSQL</span> database </p>
</div>
<div class="refsynopsisdiv">
<h2>Synopsis</h2>
<div class="cmdsynopsis"><p><tt class="command">NODE ival ADMIN CONNINFO = 'DSN';</tt> [<i class="replaceable"><tt> ival;</tt></i>] [<i class="replaceable"><tt> 'conninfo'</tt></i>]</p></div>
</div>
<div class="refsect1" lang="en">
<a name="id2553114"></a><h2>Description</h2>
<p> Describes how the <span class="application">slonik</span> utility can
reach a nodes database in the cluster from where it is run
(likely the DBA's workstation). The conninfo string is the string
agrument given to the <tt class="function">PQconnectdb()</tt> libpq
function. The user used to connect must be the special
replication superuser, as some of the actions performed later may
include operations that are strictly reserved for database
superusers by PostgreSQL.
</p>
<p> The <span class="application">slonik</span> utility will not try to
connect to a given database unless some subsequent command
requires the connection.
</p>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p> As mentioned in the original documents,
<span class="productname">Slony-I</span> 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
and configuration activities can use simple authentication
schemes like &#8220;<span class="quote">trust</span>&#8221;. Alternatively, libpq can read
passwords from <tt class="filename"> .pgpass </tt>.
</p>
</div>
<div class="note" style="margin-left: 0.5in; margin-right: 0.5in;">
<h3 class="title">Note</h3>
<p> If you need to change the DSN information for a node, as would
happen if the IP address for a host were to change, you must
submit the new information using the <a href="stmtstorepath.html" title="STORE
PATH"><span class="refentrytitle">STORE
PATH</span></a> command, and that configuration will be
propagated. Existing <span class="application"> slon </span> processes
may need to be restarted in order to become aware of the
configuration change.
</p>
</div>
<p> For more details on the distinction between this and <a href="stmtstorepath.html" title="STORE
PATH"><span class="refentrytitle">STORE
PATH</span></a>, see <a href="plainpaths.html" title="9.  Slony-I Path Communications">Section 9, &#8220; <span class="productname">Slony-I</span> Path Communications&#8221;</a>.</p>
</div>
<div class="refsect1" lang="en">
<a name="id2553210"></a><h2>Example</h2>
<pre class="programlisting"> NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
</pre>
</div>
</div></body>
</html>

0 comments on commit 69139db

Please sign in to comment.