| Slony-I 1.2.23 Documentation | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Fast Forward | Next | |
5. Slony-I Concepts
In order to set up a set of Slony-I replicas, it is necessary to understand the following major abstractions that it uses:
Cluster
Node
Replication Set
Origin, Providers and Subscribers
slon daemons
slonik configuration processor
It is also worth knowing the meanings of certain Russian words:
slon is Russian for "elephant"
slony is the plural of slon, and therefore refers to a group of elephants
slonik is Russian for "little elephant"
The use of these terms in Slony-I is a "tip of the hat" to Vadim Mikheev, who was responsible for the rserv prototype which inspired some of the algorithms used in Slony-I.
5.1. Cluster
In Slony-I terms, a "cluster" is a named set of PostgreSQL database instances; replication takes place between those databases.
The cluster name is specified in each and every Slonik script via the directive:
cluster name = something;
If the Cluster name is something, then Slony-I will create, in each database instance in the cluster, the namespace/schema _something.
5.2. Node
A Slony-I Node is a named PostgreSQL database that will be participating in replication.
It is defined, near the beginning of each Slonik script, using the directive:
NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
The SLONIK ADMIN CONNINFO information indicates database
connection information that will ultimately be passed to the
PQconnectdb() libpq function.
Thus, a Slony-I cluster consists of:
A cluster name
A set of Slony-I nodes, each of which has a namespace based on that cluster name
5.3. Replication Set
A replication set is defined as a set of tables and sequences that are to be replicated between nodes in a Slony-I cluster.
You may have several sets, and the "flow" of replication does not need to be identical between those sets.
5.4. Origin, Providers and Subscribers
Each replication set has some origin node, which is the only place where user applications are permitted to modify data in the tables that are being replicated. This might also be termed the "master provider"; it is the main place from which data is provided.
Other nodes in the cluster subscribe to the replication set, indicating that they want to receive the data.
The origin node will never be considered a "subscriber." (Ignoring the case where the cluster is reshaped, and the origin is expressly shifted to another node.) But Slony-I supports the notion of cascaded subscriptions, that is, a node that is subscribed to some set may also behave as a "provider" to other nodes in the cluster for that replication set.
5.5. slon Daemon
For each node in the cluster, there will be a slon process to manage replication activity for that node.
slon is a program implemented in C that processes replication events. There are two main sorts of events:
Configuration events
These normally occur when a slonik script is run, and submit updates to the configuration of the cluster.
SYNC events
Updates to the tables that are replicated are grouped together into SYNCs; these groups of transactions are applied together to the subscriber nodes.
5.6. slonik Configuration Processor
The slonik command processor processes scripts in a "little language" that are used to submit events to update the configuration of a Slony-I cluster. This includes such things as adding and removing nodes, modifying communications paths, adding or removing subscriptions.