Single-master-multi-slave replication utilizing log shipping is made possible by PostgreSQL's streaming replication, which was added in version 9.1. Three processes are involved: walsender on the main server, walreceiver on the backup server, and startup on the standby server. A TCP connection is used for the communication between the walsender and walreceiver.
The standby server starts the startup process during the startup sequence, followed by the walreceiver procedure. When the primary server receives a connection request from the walreceiver, it launches a walsender process and creates a TCP connection between them. During handshaking, the walreceiver transmits the most recent LSN (Log Sequence Number) of the standby's database cluster.
The walsender delivers the pertinent WAL data to the walreceiver for catch-up transmission if the standby's LSN lags behind the primary's LSN. When the standby server catches up, streaming replication starts, keeping it in sync with the primary.
By using sync_priority and sync_state, the primary server controls a number of standby servers. Each standby server's priority is shown by its sync_priority value, while the server's status (sync, potential, or async) is indicated by its sync_state value. To guarantee consistency and synchrony, the primary watches for ACK responses from synchronous standbys.
The primary server keeps waiting forever for ACK responses if a standby server dies. Several standby servers can be utilised to prevent this, or the synchronous mode can be manually changed to the asynchronous mode by using the synchronous_standby_names parameter.
Mechanisms for detecting failures in backup servers are in place. In this, dropped connections, network issues, and unresponsiveness depending on customizable timeouts are all included.
PostgreSQL users may successfully establish and maintain streaming replication for high availability and data synchronization by comprehending the launch procedure, communication, and management of many backup servers.
Top comments (0)