## 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 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 `SYNC`s; 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.