> I'm reviewing the first slonik example in the README and trying to figure
> out which values correspond to which entities (origin, server, client,
> provider, receiver).  Below I've reduced the example and replaced the
> magic
> numbers with variable names for a simple master-slave replication setup in
> order to ask you if it appears I'm correctly understanding the type of
> each
> of the IDs in the example.  Assume I understand the conninfo parts
> correct.
>
> Questions:
>
>     What's the difference between a node ID and a cluster ID?

Node IDs are intended to identify the database hosts.  If you have five
hosts, then you need 5 node IDs.

The cluster ID should identify the nature of what is being replicated. 
This should identify something of the combination of the application and
data being replicated.

When Afilias is replicating databases for different TLDs, .org and .info,
it should come as no great shock that the respective cluster names might
be based on those names.  If you have several distinct accounting modules
that are being replicated, you might have a cluster named "general_ledger"
and another named "cash_journal" and still another called
"accounts_receivable."

If there are only a couple of database servers, and one or two
applications using replication, you don't need to be terribly
sophisticated about the cluster/node IDs.  As the number of nodes grows,
the need to manage names carefully grows.

This is much the same as the way that if you have a network with only half
a dozen hosts, managing host names in /etc/hosts is perfectly reasonable,
whilst if there are 200, you probably need the sophistication of something
like BIND.

>     Any problem using oids for the table IDs in "set add table"?

I haven't tried that; they _don't_ need to be consecutive, and OID numbers
have the merit of being likely to be unique.  It's possible that you may
need, in some cases, to carefully choose the order of the IDs, but I
haven't yet seen any example to describe how things break if you fail to
do so.

>     Any problem using 'public' for replication tables schemaname?

In the "altperl" scripts, the set configuration code adds "public." to
objects where no schema is specified, so there's certainly no problem
here.

>     Below, are origin, server, client, provider, and receiver all "node"
> numbers?
>
> MASTER_ID=1     # Master's node ID number, first one has to be 1
> SLAVE_ID=2      # Slave's node ID number, first one has to be 1
> SET_ID=37       # Arbitrary set ID number?  Or does it have to start with
> 1?

I believe (Jan can verify) that the "first one has to be 1" requirement is
no longer true.

A common scenario with SET IDs will be that you want to replicate all of
the tables from a "master" node to all of the "slave" nodes.  In that
case, you would only require one set ID number.  Note that it does NOT
need to start with 1.  A common case will be to discover that you need a
couple of extra tables/sequences.  You may set up "set 2" to contain them,
and then merge them into set 1 once they're replicating everywhere.

> CLUSTER=test1                     # schema name for replication tables?

The schema in which Slony-I does its work on each node in the cluster will
be "_test1" if the cluster name is "test1".