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 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:
(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:
(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
If you want to understand PostgreSQL In-Depth.
Top comments (0)