Synchronous and asynchronous multi-slave replication
The complete set of environment is as follows:
PostgreSQL 9.6 SUSE environment construction (1)
PostgreSQL master-slave asynchronous streaming replication configuration (2)
PostgreSQL master-slave asynchronous and synchronous streaming replication configuration (3)
Connect to the pocdb database on the master , based on the node status of configuration 2
pocdb=# SELECT client_addr,application_name,sync_state FROM pg_stat_replication;
client_addr | application_name | sync_state
-------------+------------------+------------
10.10.56.17 | slave1 | async
10.10.56.19 | slave2 | async
(2 rows)The master has two slaves, both of which are async (asynchronous) streaming replication. Now modify the slave1 node to sync (synchronous) streaming replication, and modify the parameter synchronous_standby_names in postgresql.conf of the master node.
synchronous_standby_names = 'slave1'
postgres@clw-db1:~> /opt/pgsql-9.6/bin/pg_ctl -D /pgdata/9.6/poc/data/ reload
server signaledView the replication information of the master:
pocdb=# SELECT client_addr,application_name,sync_state FROM pg_stat_replication;
client_addr | application_name | sync_state
-------------+------------------+------------
10.10.56.17 | slave1 | sync
10.10.56.19 | slave2 | async
(2 rows)slave1 has been modified for synchronous replication.
Synchronous replication slave downtime test
a. Implicit transaction, the synchronization slave is down, the transaction is suspended, and the write transaction continues to execute after the slave recovers.
pocdb=# SELECT client_addr,application_name,sync_state FROM pg_stat_replication;
client_addr | application_name | sync_state
-------------+------------------+------------
10.10.56.17 | slave1 | sync
(1 row)Slave1 is a synchronous replication method. When slave1 is down (kill -9), the query can be executed on the master, but the written DML statement will be blocked;
pocdb=# SELECT * FROM tbl;
id | ival | cval
----+------+------
1 | 1 | A
2 | 20 | B
(2 rows)
pocdb=# INSERT INTO tbl (ival,cval) VALUES ( 4,NULL); After restoring slave1, the transaction on the master will continue to execute:
restore slave:
postgres@clw-db2:~> /opt/pgsql-9.6/bin/pg_ctl -D /pgdata/9.6/poc/data/ start
server startingTransaction on master:
pocdb=# INSERT INTO tbl (ival,cval) VALUES ( 4,NULL);
INSERT 0 1
pocdb=# SELECT * FROM tbl;
id | ival | cval
----+------+------
1 | 1 | A
2 | 20 | B
4 | 4 |
(3 rows)Query on the synchronously replicated slave node
pocdb=# SELECT * FROM tbl;
id | ival | cval
----+------+------
1 | 1 | A
2 | 20 | B
4 | 4 |
(3 rows)b. Explicit transaction. In the case of slave downtime, the submitted transaction will be submitted locally. After the slave recovers, the locally submitted transaction on the master will be synchronized to the slave, and the rollback transaction will not be affected when the slave is down.
Explicitly commit the transaction locally:
pocdb=# BEGIN;
BEGIN
pocdb=# INSERT INTO tbl (ival,cval) VALUES (5,NULL);
INSERT 0 1
pocdb=# COMMIT;
^CCancel request sent
WARNING: canceling wait for synchronous replication due to user request
DETAIL: The transaction has already committed locally, but might not have been replicated to the standby.
COMMIT
pocdb=# Explicit local ROLLBACK transactions:
pocdb=# BEGIN;
BEGIN
pocdb=# INSERT INTO tbl (ival,cval) VALUES (10,'f');
INSERT 0 1
pocdb=# ROLLBACK;
ROLLBACK
pocdb=# Query on slave:
postgres@clw-db2:~> /opt/pgsql-9.6/bin/psql pocdb
psql (9.6.8)
Type "help" for help.
pocdb=# SELECT * FROM tbl;
id | ival | cval
----+------+------
1 | 1 | A
2 | 20 | B
4 | 4 |
6 | 5 |
(4 rows)Asynchronous replication slave downtime
When the asynchronous replication slave is down, the master's read and write are not affected, and the latest data can be synchronized to the latest data immediately after recovery:
pocdb=# SELECT * FROM tbl;
id | ival | cval
----+------+------
1 | 1 | A
2 | 20 | B
4 | 4 |
6 | 5 |
(4 rows)