腳本之家服務器常用軟件

快捷導航

PostgreSQL 流復制異步轉同步的操作

更新時間：2020年12月31日 08:40:55 作者：董董-醬

這篇文章主要介紹了PostgreSQL 流復制異步轉同步的操作，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧

非常重要的synchronous_commit參數(shù)

流復制的同步方式，有主庫配置文件postgresql.conf，中的synchronous_commit控制著。所以理解該參數(shù)的配置十分重要。

單實例環(huán)境

參數(shù)值	說明	優(yōu)點	缺點
on 或 local	當事務提交時，WAL先寫入WAL buffer 再寫到 WAL文件（落盤）中。設置為on表示提交事務時需要等待本地WAL最終落盤后，才向客戶端返回成功。	非常安全	數(shù)據(jù)庫性能有損耗
off	當事務提交時，不需要等待WAL先寫入WAL buffer 再寫到 WAL文件（落盤）中。	提升數(shù)據(jù)庫性能	數(shù)據(jù)庫宕機是最新提交的少量事務可能丟失

流復制環(huán)境

參數(shù)值	說明	優(yōu)點	缺點
remote_write	當主庫提交事務后，需等待備庫接收主庫發(fā)送的WAL日志流并寫入WAL buffer，就向客戶端返回成功	只有主庫的WAL是落盤的	事務響應時間快
on	當主庫提交事務后，需等待備庫接收主庫發(fā)送的WAL日志流并寫入WAL buffer 以及寫入WAL文件，就向客戶端返回成功	主、備庫WAL均落盤，有兩份持有化文件保護	事務響應時間相對較慢
remote_apply	當主庫提交事務后，需等待備庫接收主庫發(fā)送的WAL日志流并寫入WAL buffer 以及寫入WAL文件，同時備庫apply之后，就向客戶端返回成功	數(shù)據(jù)保護最好	影響事務性能

查看同步情況

在主庫執(zhí)行以下SQL ， sync_state字段為async表示異步同步方式

postgres=# select usename , application_name , client_addr,sync_state from pg_stat_replication;
 usename | application_name | client_addr | sync_state 
---------+------------------+----------------+------------
 repuser | walreceiver | 192.168.56.102 | async
(1 row)

配置同步復制

主庫配置postgresql.conf文件

[postgres@pg01 data]$ vi postgresql.conf 
synchronous_commit = on
synchronous_standby_names = 'walreceiver'

synchronous_commit : 開篇提到的那個重要參數(shù)！

synchronous_standby_names：這里的name填寫，剛剛查詢到的application_name。

重啟主庫服務

[root@pg01 PG_12_201909212]# service postgresql-12 restart
Stopping postgresql-12 service:    [ OK ]
Starting postgresql-12 service:    [ OK ]

再次查看主庫字典

postgres=# select usename , application_name , client_addr,sync_state from pg_stat_replication;
 usename | application_name | client_addr | sync_state 
---------+------------------+----------------+------------
 repuser | walreceiver | 192.168.56.102 | sync

數(shù)據(jù)保護測試

關閉備庫。模擬備庫宕機無法正常接收WAL

[root@pg02 ~]# service postgresql-12 stop
Stopping postgresql-12 service:    [ OK ]

主庫嘗試進行DML操作

dong=# insert into t1 select * from t1;
Cancel 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.
INSERT 0 8

由于備庫已關閉，無法接受從主庫傳來的WAL，根據(jù)同步規(guī)則，主庫需要一直等待主庫接收到WAL的消息。

手動進行了cancel，數(shù)據(jù)庫報錯。說明在等待備庫reguest相應。

所以，sync同步模式雖然可以很好的保護數(shù)據(jù)，但同時也帶來了性能的影響，需慎重

補充：PostgreSQL 流復制數(shù)據(jù)同步檢查

如何分辨主、備

看進程

主庫 – walwriter

[root@pg01 PG_12_201909212]# ps -ef| grep wal
postgres 21157 21151 0 15:57 ?  00:00:00 postgres: walwriter         
postgres 21168 21151 0 15:57 ?  00:00:00 postgres: walsender repuser 192.168.56.102(38473) streaming 0/2A0001C0

備庫 – walreceiver

[root@pg02 ~]# ps -ef | grep wal
postgres 13383 13369 0 14:08 ?  00:00:01 postgres: walreceiver streaming 0/2A0001C0

函數(shù)方法

一句話判斷哪個是主庫、哪個是備庫，返回的值：

f 為主庫

t 為備庫

postgres=# select pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 f
(1 row)

那我這個就是主庫嘍~

檢查流復制同步情況

先確定主庫傳到哪兒了

在確定備庫接收到哪兒了

最后確定備庫應用到哪兒了

檢查主庫傳輸

確定主庫傳到什么位置了

postgres=# select pg_current_wal_lsn();
 pg_current_wal_lsn 
--------------------
 0/2A0001C0
(1 row)

檢查備庫恢復

確定備庫接收到哪兒了

postgres=# select pg_last_wal_receive_lsn();
 pg_last_wal_receive_lsn 
-------------------------
 0/2A0001C0
(1 row)

確定備庫應用到哪兒了

postgres=# select pg_last_wal_replay_lsn();
 pg_last_wal_replay_lsn 
------------------------
 0/2A0001C0
(1 row)

最近事務應用的時間

postgres=# select pg_last_xact_replay_timestamp();
 pg_last_xact_replay_timestamp 
-------------------------------
 2020-03-05 15:20:22.125688+08
(1 row)

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方，望不吝賜教。

您可能感興趣的文章: