PostgreSQL 多個同步復制服務器

在PG9.6版本時，只能支持基于優先級的同步備庫方式。

在PG10及以后版本中，引入了 synchronous_standby_names 這種基于 Quorum的同步復制優選提交的機制。

?

同步復制支持一個或者更多個同步后備服務器，事務將會等待，直到所有同步后備服務器都確認收到了它們的數據為止。事務必須等待其回復的同步后備的數量由synchronous_standby_names指定。這個參數還指定一個后備服務器名稱及方法（FIRST和ANY）的列表來從列出的后備中選取同步后備。

?

方法FIRST指定一種基于優先的同步復制并且讓事務提交等待，直到它們的WAL記錄被復制到基于優先級選中的所要求數量的同步后備上為止。在列表中出現較早的后備被給予較高的優先級，并且將被考慮為同步后備。其他在這個列表中位置靠后的后備服務器表示可能的同步后備。如果任何當前的同步后備由于任何原因斷開連接，它將立刻被下一個最高優先級的后備所替代。

?

基于優先級的多同步后備的synchronous_standby_names示例1：

synchronous_standby_names = 's1, s2'

在這個例子中，s1是同步備庫，s2為潛在同步備庫，當s1不可用時，s2升級為同步備庫

?

基于優先級的多同步后備的synchronous_standby_names示例2：

synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'

在這個例子中，如果有四個后備服務器s1、s2、s3和s4在運行，列表前兩個后備服務器s1和s2將被選中為同步后備。

主庫提交事務時，必須要等s1和s2都接收并寫入WAL日志文件才能返回給客戶端成功。

s3是一個潛在的同步后備，當s1或s2中的任何一個失效， 它將升級為同步備庫。

s4則是一個異步后備因為它的名字不在列表中。

?

基于Quorum數量的同步復制 示例：

synchronous_standby_names的基于規定數量的多同步后備的例子：

synchronous_standby_names = 'ANY 2 (s1, s2, s3)'

在這個例子中，如果有四臺后備服務器s1、s2、s3以及s4正在運行，事務提交將會等待來自s1 s2 s3中至少任意兩臺后備服務器的回復。

s4是一臺異步后備，因為它的名字不在該列表中。

?

后備服務器的同步狀態可以使用pg_stat_replication視圖查看。

?

當一臺后備服務器第一次附加到主服務器時，它將處于一種還沒有正確同步的狀態。這被描述為追趕模式。一旦后備服務器和主服務器之間的遲滯第一次變成零，我們就來到了實時的流式狀態。在后備服務器被創建之后的很長一段時間內可能都是追趕模式。如果后備服務器被關閉，則追趕周期將被增加，增加量由后備服務器被關閉的時間長度決定。只有當后備服務器到達流式狀態后，它才能成為一臺同步后備。這種狀態可以使用pg_stat_replication視圖查看。

?

注意：

如果在提交正在等待確認時主服務器重啟，那些正在等待的事務將在主數據庫恢復時被標記為完全提交。沒有辦法確認所有后備服務器已經收到了在主服務器崩潰時所有還未處理的 WAL 數據。某些事務可能不會在后備服務器上顯示為已提交，即使它們在主服務器上顯示為已提交。我們提供的保證是：在 WAL 數據已經被所有后備服務器安全地收到之前，應用將不會收到一個事務成功提交的顯式確認。

?

?

實驗部分：

一主兩備的流復制實驗（集群使用patroni搭建,它會自動構建同步復制節點）：

postgres=# select pid,usename,application_name,client_addr,state,sync_state,sync_priority from pg_stat_replication ;

? pid? |? usename?? | application_name |? client_addr? |?? state?? | sync_state | sync_priority

-------+------------+------------------+---------------+-----------+------------+---------------

?58691 | replicator | pg_node3???????? | 192.168.2.189 | streaming | sync?????? |???????????? 1

?58712 | replicator | pg_node2???????? | 192.168.2.188 | streaming | potential? |???????????? 1

(2 rows)

?

說明：

sync?????? 表示同步庫

potential? 表示潛在同步庫

?

在 patroni 構建的PG流復制集群中，我的配置是已經開啟了基于優先級多備庫的方式。 因此我們可以任意關閉1個standby節點，但是如果我們關閉全部的standby節點后，會造成主節點的修改阻塞。

?

下面是我自建的基于Quorum的同步備庫演示貼圖（因為我在patroni里面沒找到哪里配的支持Quorum。。。暫時也懶得找了）：

修改 postgresql.conf 的如下內容：

synchronous_standby_names = 'ANY 2 (pg_node2,pg_node3)'

?

然后重載pg的配置文件：

pg_ctl reload??

?

然后在主庫查詢配置是否生效：

postgres=# show synchronous_standby_names ;

?synchronous_standby_names

---------------------------

?ANY 2 (pg_node2, pg_node3)

(1 row)

?

這時候，在主庫查看到的如下：

postgres=# select pid,usename,application_name,client_addr,state,sync_state,sync_priority from pg_stat_replication ;

? pid? |? usename?? | application_name |? client_addr? |?? state?? | sync_state | sync_priority

-------+------------+------------------+---------------+-----------+------------+---------------

?65373 | replicator | pg_node3???????? | 192.168.2.189 | streaming | quorum???? |???????????? 1

?65375 | replicator | pg_node2???????? | 192.168.2.188 | streaming | quorum???? |???????????? 1

(2 rows)

?

圖上可以看出，2個standby節點的sync_state都是 quorum的，并且 sync_priority 優先級都是1 (基于Quorum的同步備庫 sync_prioriy的值對備庫無影響，可忽略)

?

接著關閉一個同步備庫 pg_node2 ，這時候我們去主庫插入數據，可看到被阻塞了。