Thanks all, this helps a lot
On 2/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > 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
