Contents
What is Slony replication?
Slony is a primary-standby replication environment that is well-suited for large databases with a limited number of standby systems. Slony replication: • Shares data in one direction only, from a primary node to a standby node.
How Slony works?
It operates as a trigger-based replication method that is a ‘master to multiple slaves’ solution. Slony operates by installing triggers on each table to be replicated, on both master and slaves, and every time the table gets an INSERT, UPDATE, or DELETE, it logs which record gets changed, and what the change is.
What is slonik?
slonik. is the word for a “little elephant,” and is the name of the program used to configure the cluster. In effect, the “little elephant” tells the cluster, “here’s what you need to do!”
How does Slony replication work in PostgreSQL cluster?
Since Slony can replicate data between PostgreSQL clusters of different versions, it can be used to set up replication between an older version as the master and a newer version as the slave. When the upgrade is to happen, simply perform a ‘switchover’, making the slave the new master, and the old master becomes the slave.
How does slonik work on a replicated table?
When executed, slonik will connect to all nodes defined and create the Slony schema on each. When the Slony daemons are kicked off, they will then clear out all data in the replicated tables on the slave (if there is any), and copy over all data from the master to the slave (s).
Where can I get Slony for PostgreSQL?
Slony is installed either by source or through the PGDG (PostgreSQL Global Development Group) repositories which are available for Red Hat and Debian based linux distributions. These binaries should be installed on all hosts that will contain either a master or slave node in the replication system.
How does Slon daemon work in PostgreSQL replication?
Outside processes, called the ‘slon daemons’, connect to the databases as any other client and fetch the changes from the master, then replay them on all slave nodes subscribed to the master. In a well performing replication setup, this asynchronous replication can be expected to be anywhere 1 to 20 seconds lagged behind the master.