這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)怎么在PostgreSQL中將流復(fù)制異步轉(zhuǎn)為同步,文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。
創(chuàng)新互聯(lián)建站是專業(yè)的大姚網(wǎng)站建設(shè)公司,大姚接單;提供成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作,網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行大姚網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!非常重要的synchronous_commit參數(shù)
流復(fù)制的同步方式,有主庫配置文件postgresql.conf,中的synchronous_commit控制著。所以理解該參數(shù)的配置十分重要。
參數(shù)值 | 說明 | 優(yōu)點(diǎn) | 缺點(diǎn) |
---|---|---|---|
on 或 local | 當(dāng)事務(wù)提交時,WAL先寫入WAL buffer 再寫到 WAL文件(落盤)中。設(shè)置為on表示提交事務(wù)時需要等待本地WAL最終落盤后,才向客戶端返回成功。 | 非常安全 | 數(shù)據(jù)庫性能有損耗 |
off | 當(dāng)事務(wù)提交時,不需要等待WAL先寫入WAL buffer 再寫到 WAL文件(落盤)中。 | 提升數(shù)據(jù)庫性能 | 數(shù)據(jù)庫宕機(jī)是新提交的少量事務(wù)可能丟失 |
參數(shù)值 | 說明 | 優(yōu)點(diǎn) | 缺點(diǎn) |
---|---|---|---|
remote_write | 當(dāng)主庫提交事務(wù)后,需等待備庫接收主庫發(fā)送的WAL日志流并寫入WAL buffer, 就向客戶端返回成功 | 只有主庫的WAL是落盤的 | 事務(wù)響應(yīng)時間快 |
on | 當(dāng)主庫提交事務(wù)后,需等待備庫接收主庫發(fā)送的WAL日志流并寫入WAL buffer 以及寫入WAL文件, 就向客戶端返回成功 | 主、備庫WAL均落盤,有兩份持有化文件保護(hù) | 事務(wù)響應(yīng)時間相對較慢 |
remote_apply | 當(dāng)主庫提交事務(wù)后,需等待備庫接收主庫發(fā)送的WAL日志流并寫入WAL buffer 以及寫入WAL文件, 同時備庫apply之后, 就向客戶端返回成功 | 數(shù)據(jù)保護(hù)好 | 影響事務(wù)性能 |
在主庫執(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
關(guān)閉備庫。模擬備庫宕機(jī)無法正常接收WAL
[root@pg02 ~]# service postgresql-12 stop Stopping postgresql-12 service: [ OK ]
主庫嘗試進(jìn)行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
由于備庫已關(guān)閉,無法接受從主庫傳來的WAL,根據(jù)同步規(guī)則,主庫需要一直等待主庫接收到WAL的消息。
手動進(jìn)行了cancel, 數(shù)據(jù)庫報(bào)錯。說明在等待備庫reguest相應(yīng)。
所以,sync同步模式雖然可以很好的保護(hù)數(shù)據(jù),但同時也帶來了性能的影響,需慎重
補(bǔ)充:PostgreSQL 流復(fù)制數(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
一句話判斷哪個是主庫、哪個是備庫,返回的值:
f 為主庫
t 為備庫
postgres=# select pg_is_in_recovery(); pg_is_in_recovery ------------------- f (1 row)
那我這個就是主庫嘍~
先確定主庫傳到哪兒了
在確定備庫接收到哪兒了
最后確定備庫應(yīng)用到哪兒了
確定主庫傳到什么位置了
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)
確定備庫應(yīng)用到哪兒了
postgres=# select pg_last_wal_replay_lsn(); pg_last_wal_replay_lsn ------------------------ 0/2A0001C0 (1 row)
最近事務(wù)應(yīng)用的時間
postgres=# select pg_last_xact_replay_timestamp(); pg_last_xact_replay_timestamp ------------------------------- 2020-03-05 15:20:22.125688+08 (1 row)
上述就是小編為大家分享的怎么在PostgreSQL中將流復(fù)制異步轉(zhuǎn)為同步了,如果剛好有類似的疑惑,不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識,歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。