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 ，這時候咱們去主庫插入數據，可看到被阻塞了。