> Hi,
>
> I've read several articles about installing and using Slony, but I
> haven't found any that cover the basics of how Slony is implemented
> (or I'm too dumb to realize it). Most of the material is geared
> towards explaining Slony's purpose or usage, not its implementation.
>
> Without going into too many details, how is slony implemented? I know
> that might be a big and scary answer, so I'd really like to know...
>
> - What is slon? Is it a network service that other nodes communicate
> with? Is slonik its client?
Behaviour is more of a "store and forward"/"publish and subscribe" thing...
- There is a slon process for each and every node in the replication cluster.
- The slon listens for what is going on on remote nodes, and applies
changes (if need be) to the one node that it manages.
There are two roles of interest:
- A node may be the origin ('master') for a replication set; in that case,
the slon for that node is simply responsible for making the SYNC 'clock'
tick. It marks SYNC events every so often (configurable, but let's say,
every second, when things are busy). That timing information is used to
determine what data needs to be replicated.
- A slon may be a subscriber ('slave') for a replication set. In that
case, it refers to a provider node, using SYNC information to figure out
what transactions were committed as part of a given SYNC, and then pulls
and applies a list of updates from the provider.
There are two other components of interest:
- On an origin node ('master'), there are triggers on replicated tables
that cause updates to be stored in log tables (sl_log_1/sl_log_2).
- The program "slonik" manages replication configuration. Given a
configuration script, it tells one or more of the nodes in the cluster
that some aspect of configuration has changed. Generally, that then
propagates to ALL the nodes in the cluster; they're all listening for
configuration changes.
> - How does replication happen? When a change happens to the master, is
> the change pushed or pulled from the master?
As mentioned, there are two things that happen on the master:
1. There are triggers on the replicated tables that store updates in the
tables sl_log_1 and sl_log_2.
2. The master node has a clock "ticking" so that subscribers know how to
pull that data. It marks off events: "SYNC", "SYNC", "SYNC", ...
Each SYNC indicates what transactions are in progress, and based on that,
the slon for a subscriber can figure out which ones committed as part of a
given SYNC, and then pull the data for that.
So in answer to "pushed/pulled", the answer is "pulled."
> - What do the triggers do?
They record the change (insert/update/delete) along with primary key value
and, if need be, the data of the change. They also record a sequence ID
used to determine the order of application of changes.
> - In the usage articles I've found, databases are replicated on a
> single machine and a slon is started for each node. If I am
> replicating across two computers, does the computer on which the
> slonik commands are executed matter?
No, not at all.
If you can point at any places where you specifically found the
documentation deficient for your needs, that would be quite useful as it
might lead to its improvement...
_______________________________________________
Slony1-general mailing list
[email protected]
http://gborg.postgresql.org/mailman/listinfo/slony1-general
