11.1. Starting the Streaming Replication

In streaming replication, three types of processes work cooperatively:

  • A walsender process on the primary server sends WAL data to the standby server.
  • A walreceiver process on the standby server receives and replays the WAL data.
  • A startup process on the standby server starts the walreceiver process.

The walsender and walreceiver communicate using a single TCP connection.

The startup sequence of streaming replication is shown in Figure 11.1:

Figure 11.1. SR startup sequence.

  1. Start the primary and standby servers.

  2. The standby server starts the startup process.

  3. The standby server starts a walreceiver process.

  4. The walreceiver sends a connection request to the primary server. If the primary server is not running, the walreceiver sends these requests periodically.

  5. When the primary server receives a connection request, it starts a walsender process. A TCP connection is then established between the walsender and walreceiver.

  6. The walreceiver sends the latest LSN (Log Sequence Number) of the standby’s database cluster. This exchange is known as handshaking.

  7. If the standby’s latest LSN is less than the primary’s latest LSN (Standby’s LSN $\lt$ Primary’s LSN), the walsender sends WAL data from the former LSN to the latter LSN.

    Primary’s pg_wal subdirectory (or pg_xlog in versions 9.6 or earlier) provides these WAL segments. The standby server then replays the received WAL data.

    In this phase, the standby catches up with the primary, which is called catch-up.

  8. Streaming Replication begins to work.

Each walsender process maintains a state corresponding to the working phase of the connected walreceiver or application. The possible states of a walsender process are:

  • start-up - From the start of the walsender to the end of handshaking. See Figures 11.1(5)-(6).
  • catch-up - During the catch-up phase. See Figure 11.1(7).
  • streaming - While Streaming Replication is working. See Figure 11.1(8).
  • backup - While sending the files of the whole database cluster for backup tools such as the pg_basebackup utility.

The pg_stat_replication view shows the state of all running walsenders. An example is shown below:

testdb=# SELECT application_name,state FROM pg_stat_replication;
 application_name |   state
------------------+-----------
 standby1         | streaming
 standby2         | streaming
 pg_basebackup    | backup
(3 rows)

As shown above, two walsenders are running to send WAL data for the connected standby servers, and another one is running to send all files of the database cluster for the pg_basebackup utility.

11.1.1 What Happens When a Standby Server Restarts After a Long Downtime?

In versions 9.3 or earlier, the standby cannot catch up with the primary server if the required WAL segments have already been recycled on the primary.

No reliable solution exists for this problem other than setting a large value for the configuration parameter wal_keep_size (or wal_keep_segments in versions 12 or earlier). This parameter reduces the possibility of occurrence but remains a stopgap solution.

In versions 9.4 or later, replication slots can prevent this problem. A replication slot is a feature that expands the flexibility of WAL data sending. Refer to Section 11.4 for details.