Configuring a cascaded replication

As you have already seen in this chapter, setting up streaming replication is really easy. All it takes is setting a handful of parameters, taking a base backup, and enjoying your replication setup.

In many cases, however, the situation is a bit more delicate. Let's assume for this example that we want to use a master to spread data to dozens of servers. The overhead of replication is actually very small (common wisdom says that the overhead of a slave is around 3 percent of overall performance—however, this is just a rough estimate), but if you do something small often enough, it can still be an issue.

It is definitely not very beneficial for the master to have, say, 100 slaves.

An additional use case is as follows: having a master in one location and a couple of slaves in some other location. It does not make sense to send a lot of data over a long distance over and over again. It is a lot better to send it once and dispatch it to the other side.

To make sure that not all servers have to consume the transaction log from a single master, you can make use of cascaded replication. Cascading means that a master can stream its transaction log to a slave, which will then serve as the dispatcher and stream the transaction log to further slaves.

Tip

To use cascaded replication, you need at least PostgreSQL 9.2.

The following diagram illustrates the basic architecture of cascaded replication:

The slaves to the far right of the diagram could serve as dispatchers again. With this very simple method, you can basically create a system of infinite size.

The procedure to set things up is basically the same as that for setting up a single slave. You can easily take base backups from an operational slave (postgresql.conf and pg_hba.conf have to be configured just as in the case of a single master).

Tip

Be aware of timeline switches; these can easily cause issues in the event of a failover. Check out the Dealing with the timelines section to find out more.