The fourth chapter of PostgreSQL replication set up asynchronous Replication (2)

4.2 Configuring cascading replication

As you've seen in this chapter, it's really easy to set up stream replication. Just set up a few parameters, make a basic backup, and enjoy your replication settings.

In many cases, this situation is a little bit more subtle. In this example we assume that we are going to use a master to send data to dozens of servers. The cost of replication is actually very small (it is often said that a slave overhead is about 3%), but you do small things enough, and it can still be a problem. There is absolutely no benefit to the 100 slave.

Another use case is one where the master and multiple slave in another place. It doesn't make any sense to send large amounts of data over and over again over long distances. Sending it once, distributing it to other places is a better solution.

To ensure that not all servers need to consume a single master transaction log, you can use Cascade Replication (cascaded replication). Cascading means that master can stream the transaction log to a Slave, which slave acts as a dispatch node to send transaction logs to more slave.

[To use cascade replication, you need at least PostgreSQL9.2. ]

Shows the basic schema:

The slaves on the far side of the picture can act as a transfer node here. With this very simple approach, you can basically create a wireless-scale system. The process of setting up is basically the same as setting up a single slave. You can easily make basic backups from a running slave (postgresql.conf and pg_hba.conf must be configured just like a single master).

[To know the switch on the timeline; This can easily cause problems in a failover situation.] Check out the chapters of the timeline for more information. ]

The fourth chapter of PostgreSQL replication set up asynchronous Replication (2)