Summary of Chapter# 11: "Streaming Replication" from the book "The Internals of PostgreSQL"
Tags: postgres, apacheage, database, agenssql
Published: 2023-09-16 16:45:29

This blog aims to assist you in understanding the initial concepts of Chapter 11 [Streaming Replication] from the book The Internals of PostgreSQL.

> _**Note: Ensure that you have a thorough understanding of 
 [Chapter 10 Part-2](https://dev.to/vkt1271/summary-of-chapter-10-base-backup-point-in-time-recovery-from-the-book-the-internals-of-postgresql-part-2-5aec) and basics of PostgreSQL before we proceed to Chapter 11 Part-1, as it forms the foundation for our exploration.**_

So, Let's Start:

## Introduction to chapter

- Synchronous streaming replication was implemented in version 9.1. It is a single-master-multi-slaves type of replication, where the terms "**master**" and "**slaves**" are usually referred to as **primary** and **standbys** respectively.

- This native replication feature is based on log shipping, a general replication technique in which the primary server continuously sends **WAL** (Write-Ahead Log) data to the **standby servers**, which then replay the received data immediately.

----------------------------------------------------------------

## Starting the Streaming Replication

- In streaming replication, **three** types of processes work cooperatively

- (1) A **walsender** process on the primary server sends WAL (Write-Ahead Log) data to the standby server.

- (2) A **walreceiver** process on the standby server receives and replays the WAL data.

- (3) A **startup** process on the standby server starts the walreceiver process.

- The **walsender** and **walreceiver** communicate using a single TCP connection.

> **SR startup sequence** in PostgreSQL is depicted in the figure below:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/kwe3u0rlklgwpno7xwc9.png)

- (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 and a TCP connection is established between the walsender and walreceiver.

- (6) The walreceiver sends the latest LSN (Log Sequence Number) of standby's database cluster. This is known as **handshaking** in the field of information technology.

- (7) If the standby's latest LSN is less than the primary's latest LSN (Standby's LSN < Primary's LSN), the walsender sends WAL data from the former LSN to the latter LSN. These WAL data are provided by WAL segments stored in the primary's pg_wal subdirectory (in versions 9.6 or earlier, pg_xlog). The standby server then replays the received WAL data. In this phase, the standby catches up with the primary, so it is called **catch-up**.

- (8) Streaming Replication begins to work.

----------------------------------------------------------------

## How to Conduct Streaming Replication

- Streaming replication has **two** aspects: **log shipping** and **database synchronization**. 

- **Log shipping** is the main aspect of streaming replication, as the primary server sends WAL (Write-Ahead Log) data to the connected standby servers whenever they are written. 

- **Database synchronization** is required for synchronous replication, where the primary server communicates with each standby server to synchronize their database clusters.

**Communication Between a Primary and a Synchronous Standby**

- The standby server is in the synchronous replication mode, but the configuration parameter **hot_standby** is disabled and **wal_level** is 'replica'.

- The backend starts a transaction, issues an INSERT statement, and then commits the transaction immediately.

> **Streaming Replication's communication sequence diagram** in PostgreSQL is depicted in the figure below:

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/arw83w5igarel7sni24n.png)

- (1) The backend process writes and flushes WAL data to a WAL segment file by executing the functions **XLogInsert()** and **XLogFlush()**.

- (2) The walsender process sends the WAL data written into the WAL segment to the walreceiver process.

- (3) After sending the WAL data, the backend process continues to wait for an ACK response from the standby server. More precisely, the backend process gets a latch by executing the internal function **SyncRepWaitForLSN()**, and waits for it to be released.

- (4) The walreceiver on the standby server writes the received WAL data into the standby's WAL segment using the **write()** system call, and returns an ACK response to the walsender.

- (5) The walreceiver flushes the WAL data to the WAL segment using the system call such as **fsync()**, returns another ACK response to the walsender, and informs the startup process about WAL data updated.

- (6) The startup process **replays the WAL data**, which has been written to the WAL segment.

(7) The walsender releases the latch of the backend process on receiving the ACK response from the walreceiver, and then, the backend process's commit or abort action will be completed. The timing for latch-release depends on the parameter **synchronous_commit**.

- It is 'on' (default), the latch is released when the ACK of step 
(5) received, whereas it is '**remote_write**', the latch is released when the ACK of step (4) is received.

- Each ACK response informs the primary server of the internal information of standby server. 

- It contains four items below:

- (1) The LSN location where the latest WAL data has been written.

- (2) The LSN location where the latest WAL data has been flushed.

- (3) The LSN location where the latest WAL data has been replayed in the startup process.

- (4) The timestamp when this response has been sent.

----------------------------------------------------------------

I hope this blog has helped you understand the initial concepts of Streaming Replication in PostgreSQL.

Check out a summary of [Chapter: 11 Part-2](https://dev.to/vkt1271/summary-of-chapter-11-streaming-replication-from-the-book-the-internals-of-postgresql-part-2-231n)

If you want to understand [PostgreSQL In-Depth](https://www.youtube.com/playlist?list=PLhr1KZpdzukeAZuX0pNZ1lLDkaZWBOhQT).