作為一個開發者，我們知道一個網站如果數據丟失和停機，即使是很少、很短暫，也可能是災難性的，并且降低生產力、可訪問性和產品信心。

為保護站點的完整性，建立防范停機或數據丟失的措施至關重要。

數據復制是一種自動備份過程，數據會從其主數據庫復制到另一個遠程位置以進行妥善保管。對于運行數據庫服務器的任何站點或應用程序來說，它都是一項不可或缺的技術。我們還可以利用復制的數據庫來處理只讀 SQL，從而允許在系統內運行更多進程。

在兩個數據庫之間設置復制是很有必要了，它提供了針對意外事故的容錯能力，這也是在災難期間實現高可用性的最佳策略。

在本文中，我們將深入探討 PostgreSQL 復制的不同策略。

什么是 PostgreSQL 復制？

PostgreSQL 復制是將數據從PostgreSQL 數據庫服務器復制到另一臺服務器的過程。源數據庫服務器也稱為“主”服務器，而接收復制數據的數據庫服務器稱為“副本”服務器。

PostgreSQL 數據庫遵循簡單的復制模型，其中所有寫入都轉到主節點。然后主節點可以應用這些更改并將它們廣播到輔助節點。

什么是自動故障轉移？

故障轉移是一種在主服務器因一些原因失效時恢復數據的方法。不過只要你配置了 PostreSQL 來進行物理流復制，就不會因主服務器故障而停機。

請注意，故障轉移過程可能需要一些時間來設置和啟動。PostgreSQL 中沒有用于監視和確定服務器故障范圍的內置工具，因此需要我們自行發揮。

不過幸運的是，我們需要依賴 PostgreSQL 進行故障轉移。有專用工具來進行自動故障轉移和自動切換到備用數據庫，從而減少數據庫停機時間。

通過設置故障轉移復制，即使主服務器崩潰時，也可以通過備用服務器切換來保證高可用性。

使用 PostgreSQL 復制的好處

以下是利用 PostgreSQL 復制的一些主要優勢：

• 數據遷移：可以通過更改數據庫服務器硬件或通過系統部署來使用 PostgreSQL 復制進行數據遷移。
• 容錯性：如果主服務器發生故障，備用服務器可以充當服務器，因為主服務器和備用服務器包含的數據是相同的。
• 聯機事務處理 (OLTP) 性能：可以通過移除報告查詢負載來改進 OLTP 系統的事務處理時間和查詢時間。事務處理時間是在事務完成之前執行給定查詢所花費的持續時間。
• 并行系統測試：在升級新系統時，需要確保系統能夠很好地處理現有數據，因此需要在部署前使用生產數據庫副本進行測試。

PostgreSQL 復制的工作原理

通常，一般的機構中只有一種方法可以設置備份和復制。然而，PostgreSQL 可以有三種，分別如下：

1. 流復制：將數據從主節點復制到從節點，然后將數據復制到 S3 等文件服務器進行備份存儲。
2. 卷級復制：在存儲層復制數據，從主節點開始復制到從節點，然后將數據復制到 S3 等進行備份存儲。
3. 增量備份：從主節點復制數據，同時從 S3 等文件服務器存儲構建新的輔助節點，允許直接從主節點流式傳輸。

方法一：流復制

PostgreSQL 流復制也稱為 WAL 復制，可以在服務器上安裝 PostgreSQL 后無縫設置。這種復制方法基于將 WAL 文件從主數據庫復制到目標數據庫來完成的。

通過使用主從配置來實現 PostgreSQL 流式復制。主服務器是處理主數據庫及其所有操作的主要實例。輔助服務器充當補充實例并執行復制對主數據庫所做的所有更改，并在此過程中生成相同的副本。主服務器是讀/寫服務器，而輔助服務器只是只讀的。

這種方法需要同時配置主節點和備節點。以下部分將闡明配置所涉及的步驟。

配置主節點

通過執行以下步驟來配置主節點：

第一步：初始化數據庫

我們可以利用 initdb 程序命令來初始化數據庫。接下來，使用命令創建具有復制權限的新用戶：

CREATE USER 'example_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'example_password';

用戶在查詢時，必須提供密碼和用戶名。REPLICATION 關鍵字用于為用戶提供所需的權限。示例如下：

CREATE USER 'rep_username' REPLICATION LOGIN ENCRYPTED PASSWORD 'rep_password';

第二步：配置流屬性

接下來，使用 PostgreSQL 配置文件 ( postgresql.conf )配置流媒體屬性，如下：

wal_level = logical
wal_log_hints = on
max_wal_senders = 8
max_wal_size = 1GB
hot_standby = on

配置解析：

• wal_level：此參數用于啟用 PostgreSQL 流復制，值包括minimal、replica或logical。
• wal_log_hints：控制在 WAL 日志文件中是否包含有關寫入哪個數據文件的提示信息。當該參數設置為 ON 時，WAL 日志中的每個記錄將包含有關數據文件的信息，以便在進行數據庫恢復時可以更快地定位需要恢復的數據。當備用服務器與主服務器不同步時，此參數是pg_rewind 功能所必需的。
• max_wal_senders：指定可以與備用服務器建立的最大并發連接數。
• max_wal_size：指定可保留在日志文件中的 WAL 文件的大小。
• hot_standby：當它設置為 ON 時，可以利用此參數與輔助設備建立讀取連接。

第三步：創建新條目

修改 postgresql.conf 文件中的參數后， pg_hba.conf 文件中的新 replication 條目可以允許服務器相互建立連接以進行復制。

可以在 PostgreSQL 的數據目錄中找到這個文件，配置條目如下：

host replication rep_user IPaddress md5

執行以下代碼片段后，主服務器就允許調用的用戶（rep_user）通過使用指定的 IP 進行連接并充當備用服務器進行復制。示例：

host replication rep_user 192.168.0.22/32 md5

配置備節點

步驟 1：備份主節點

要配置備用節點，需要用 pg_basebackup 程序生成主節點的備份，這將作為備用節點的起點。命令如下：

pg_basebackp -D  -h  -X stream -c fast -U rep_user -W

上述語法中使用的參數如下：

• -h：主要主機。
• -D：表示當前正在處理的目錄。
• -C：設置檢查點。
• -X：此參數可用于包含必要的事務日志文件。
• -W：設置用戶在連接到數據庫之前提示用戶輸入密碼。

步驟 2：設置復制節點配置文件

接下來，我們需要檢查復制配置文件是否存在。如果沒有，生成復制配置文件，名稱為：recovery.conf。

在 PostgreSQL 安裝的數據目錄中創建此文件，也可以用 pg_basebackup 程序-R 選項自動生成。

recovery.conf文件應包含以下命令：

standby_mode = 'on'

primary_conninfo = 'host=<master_host> port=<postgres_port> user=<replication_user> password=<password> application_name="host_name"'

recovery_target_timeline = 'latest'

上述命令中使用的參數如下：

• primary_conninfo：通過利用連接字符串在主服務器和輔助服務器之間建立連接。
• standby_mode：通過啟用"pg_standby_mode"模式，備用服務器可以在主服務器失效時，接管主服務器的職責，確保數據的可用性和持久性。
• recovery_target_timeline：設置恢復時間線。在數據庫恢復時，需要指定恢復的時間線，以便將備份數據正確地還原到指定的時間點。

要建立連接，需要提供用戶名、IP 地址和密碼作為 primary_conninfo 參數的值。示例：

primary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'

步驟 3：重新啟動備份服務器

最后，重新啟動備份服務器以完成配置過程。

然而，流復制會帶來一些挑戰，例如：

• 各種 PostgreSQL 客戶端（用不同的編程語言編寫）與單個端點進行交互。當主節點出現故障時，這些客戶端將繼續重試相同的 DNS 或 IP 名稱。這使得故障轉移對應用程序可見。
• PostgreSQL 復制沒有內置的故障轉移和監控功能。當主節點發生故障時，我們需要將一個備份節點提升為新的主節點。這種提升需要讓用戶無感知，且不會出現數據不一致問題。
• PostgreSQL 需要復制主節點的整個狀態。當你需要開發一個新的備份節點時，需要從主節點重放狀態變化的整個歷史，這會導致很大的資源消耗，并且使得刪除頭部節點和創建新節點的成本很高。

方法二：RBD（塊設備復制）

?RBD 方法依賴于磁盤鏡像（也稱為卷復制）。在這種方法中，更改被寫入一個持久卷，該卷被同步鏡像到另一個卷。

RBD 是一個基于Ceph分布式存儲系統的塊設備復制方案，用于在PostgreSQL?數據庫中實現高可用性和容錯性。它通過將主服務器上的數據塊實時復制到備用服務器上，以確保在主服務器出現故障或宕機時，備用服務器可以立即接管其職責。

RBD是一個基于網絡塊設備的復制方案，它可以在多個Ceph節點之間實現數據復制，并通過Ceph的故障轉移機制來保證數據的可用性和一致性。在RBD中，主服務器和備用服務器之間通過Ceph集群的網絡通信，實現數據塊的實時復制和同步。

與其他流復制方案相比，RBD具有以下優點：

1. 數據復制速度更快：RBD通過Ceph的對象存儲方式來管理數據，可以實現高效的數據復制和同步，比傳統的流復制方案速度更快。
2. 數據安全性更高：RBD可以使用Ceph的數據加密和數據壓縮功能，提高數據的安全性和傳輸效率。
3. 可擴展性更好：RBD可以根據需要對Ceph存儲集群進行擴展，以滿足不同的存儲需求。
4. 系統穩定性更高：由于RBD是基于Ceph的分布式存儲系統實現的，因此具有更好的容錯性和可靠性，可以確保數據的可用性和一致性。

方法三：WAL

WAL 由段文件組成（默認為 16 MB）。每個段都有一個或多個記錄。日志序列記錄 (LSN) 是指向 WAL 中記錄的指針，用于記錄在日志文件中保存的位置（position/location）。

備份服務器利用 WAL 段（在 PostgreSQL 術語中也稱為 XLOGS）從其主服務器不斷復制更改。你可以通過在DBMS中使用預寫日志（write-ahead logging）來為數據提供持久性和原子性，具體做法是在將字節數組數據塊（每個塊都帶有唯一的LSN）應用到數據庫之前，將它們序列化并寫入穩定的存儲介質

將變更應用到數據庫可能會引起各種文件系統操作。一個相關的問題是，在文件系統更新過程中，如果服務器由于停電而發生故障，數據庫如何確保原子性。具體做法是當數據庫啟動時，它會開始一個啟動或重放過程，該過程可以讀取可用的WAL段，并將它們與存儲在每個數據頁上的LSN進行比較（每個數據頁都標記有影響該頁的最新WAL記錄的LSN）。

基于日志發送的復制（塊級）

流復制改進了日志發送的過程。與等待WAL切換不同，記錄在創建時就被發送，從而減少了復制延遲。

流復制也勝過日志發送，因為備份服務器通過復制協議在網絡上與主服務器建立連接。主服務器可以直接通過這個連接發送WAL記錄，而不必依賴于用戶提供的腳本。

基于日志發送的復制（文件級）

日志發送是將日志文件復制到另一臺PostgreSQL服務器，通過重放WAL文件生成另一臺備用服務器。且此服務器被配置為在恢復模式下工作，目的是為了在監聽新的 WAL 文件，并進行應用。

備份服務器將成為主 PostgreSQL 服務器的熱備份。它還可以配置為只讀副本，可以提供只讀查詢。

WAL 歸檔

在創建 WAL 文件時將其復制到除pg_wal子目錄以外的任何位置以將其歸檔稱為 WAL 歸檔。每次創建 WAL 文件時，PostgreSQL 都會調用用戶提供的腳本進行歸檔。

該腳本可以利用該scp命令將文件復制到一個或多個位置，例如 NFS 。存檔后，可以利用 WAL 段文件恢復數據庫到任何給定時間點。

其他基于日志的配置如下：

• 同步復制：在提交每個同步復制事務之前，主服務器會等待備用服務器以確認它們已獲取數據。這種配置的好處是不會因為并行寫入進程而導致任何沖突。
• 同步多主復制：這種情況下，每個服務器都可以接受寫入請求，并且在每個事務提交之前，修改后的數據從原始服務器傳輸到每個其他服務器。它利用 2PC 協議并遵守全有或全無規則。

WAL 流協議詳細信息

WAL接收器的進程運行在備用服務器上，利用recovery.conf中提供的primary_conninfo參數中的連接詳細信息，通過TCP/IP連接到主服務器。

開始流式復制時，前端可以在啟動消息中發送復制參數。值為true、yes、1或ON的布爾值讓后端知道它需要進入物理復制walsender模式。

WAL發送器是在主服務器上運行的另一個進程，負責在生成WAL記錄時將其發送到備用服務器。WAL接收器將WAL記錄保存在WAL中，就像本地的客戶端連接一樣。

一旦WAL記錄到達WAL段文件，備用服務器就不斷地重放WAL，以使主服務器和備用服務器保持最新同步狀態。

PostgreSQL 復制的要素

接下來我們將更深入地了解 PostgreSQL 復制的常用模型（單主復制和多主復制）、類型（物理復制和邏輯復制）以及模式（同步和異步）。

PostgreSQL 數據庫復制模型

可擴展性是指向現有節點添加更多資源/硬件，以增強數據庫存儲和處理更多數據的能力，可以進行水平和垂直擴展。PostgreSQL 復制是水平可伸縮性的一個例子，它比垂直可伸縮性更難實現。主要通過單主復制（SMR）和多主復制（MMR）來實現水平擴展。

單主復制僅允許在單個節點上修改數據，并將這些修改復制到一個或多個節點。副本數據庫中的復制表不允許接受任何更改，但來自主服務器的更改除外。

大多數時候，SMR 足以滿足應用程序的需求，因為它的配置和管理不那么復雜，而且不會發生沖突。單主復制也是單向的，因為復制數據主要在一個方向上流動，從主數據庫到副本數據庫。

在某些情況下，單靠 SMR 可能不夠，你可能需要實施 MMR。MMR 允許多個節點充當主節點。對多個指定主數據庫中表行的更改將復制到每個其他主數據庫中的對應表。在這個模型中，經常采用沖突解決方案來避免重復主鍵等問題。

使用 MMR 有幾個優點，即：

• 在主機故障的情況下，其他主機仍然可以提供更新和插入服務。
• 主節點分布在幾個不同的位置，因此所有主節點發生故障的可能性很小。
• 能夠使用主數據庫的廣域網 (WAN)，這些主數據庫在地理位置上可以靠近客戶端組，同時保持網絡中的數據一致性。

然而，實施 MMR 的缺點是復雜性和沖突難以解決。

一些機構和應用程序提供 MMR 解決方案，因為 PostgreSQL 本身并不支持。這些解決方案可能是開源的、免費的或付費的。如雙向復制 (BDR)，它是異步的并且基于 PostgreSQL 邏輯解碼功能。

由于 BDR 應用程序在其他節點上重放事務，如果正在應用的事務與在接收節點上提交的事務之間存在沖突，重放操作可能會失敗。

PostgreSQL 復制的類型

PostgreSQL 復制有兩種類型：邏輯復制和物理復制。

一個簡單的 initdb 邏輯操作，將會執行為集群創建基準目錄的物理操作。同樣，一個簡單的邏輯操作（CREATE DATABASE）將執行為在基準目錄中創建子目錄的物理操作。

物理復制通常處理文件和目錄。它不知道這些文件和目錄代表什么。物理復制方法用于在另一臺機器上維護單個集群的完整數據副本，并且在文件系統級別或磁盤級別進行，并使用精確的塊地址。

邏輯復制是一種根據復制標識（通常是主鍵）復制數據實體及其修改的方法。與物理復制不同，它處理數據庫、表和 DML 操作，并在數據庫集群級別完成。它使用發布和訂閱模型，一個訂閱者可以訂閱發布者節點上的一個或多個發布。

復制過程首先對發布者數據庫上的數據進行快照，然后將其復制到訂閱者。訂閱者從他們訂閱的發布中提取數據，并可能稍后重新發布數據，以允許級聯復制或更復雜的配置。訂閱者以與發布者相同的順序應用數據，以便保證單個訂閱內的發布的事務一致性，也稱為事務復制。

邏輯復制的典型場景如下：

• 將單個數據庫（或數據庫的子集）中的增量更改發送給訂閱者。
• 在多個數據庫之間共享數據庫的一個子集。
• 在單個更改到達訂閱者時觸發它們的觸發事件。
• 將多個數據庫合并為一個。
• 為不同的用戶組提供對復制數據的訪問。

訂閱者數據庫的行為方式與任何其他 PostgreSQL 實例相同，并且可以通過定義其發布來用作其他數據庫的發布者。

當訂閱者被應用程序配置成只讀時，單個訂閱不會發生沖突。不過，如果應用程序或其他訂閱者對同一組表進行了寫入，則可能會出現沖突。

PostgreSQL 同時支持這兩種機制。邏輯復制允許對數據復制和安全性進行細粒度控制。

復制模式

PostgreSQL 復制主要有兩種模式：同步和異步。同步復制允許同時將數據寫入主服務器和從服務器，而異步復制確保數據先寫入主服務器，然后再復制到從服務器。

在同步模式復制中，只有當這些更改已復制到所有副本時，主數據庫上的事務才被視為完成。副本服務器必須始終可用，以便在主服務器上完成事務。同步復制模式用于具有即時故障轉移要求的高端事務環境。

在異步模式下，當只在主服務器上完成更改時，可以聲明主服務器上的事務已完成。這些更改隨后會及時復制到副本中。副本服務器可以在一段時間內保持不同步，稱為復制滯后。在崩潰的情況下，可能會發生數據丟失，但異步復制提供的開銷很小，因此在大多數情況下是可以接受的（不會使主服務器負擔過重）。

如何設置 PostgreSQL 復制

接下來，我們將演示如何在 Linux 操作系統上設置 PostgreSQL 復制過程。對于本例，我們將使用 Ubuntu 18.04 LTS 和 PostgreSQL 10。

一、安裝

通過以下步驟在 Linux 上安裝 PostgreSQL：

1. 首先，通過在終端中鍵入以下命令來導入 PostgreSQL 簽名密鑰

wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O- | sudo apt-key add -

2. 然后，添加 PostgreSQL 存儲庫：

echo "deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main" | sudo tee /etc/apt/sources.list.d/postgresql.list

3. 更新存儲庫索引：

sudo apt-get update

4. 使用 apt 命令安裝 PostgreSQL 包：

sudo apt-get install -y postgresql-10

5. 最后，使用以下命令為 PostgreSQL 用戶設置密碼：

sudo passwd postgres

在進行 PostgreSQL 復制過程之前，主服務器和備份服務器都必須安裝 PostgreSQL。

在兩臺服務器上設置 PostgreSQL 后，可以繼續進行主服務器和備份服務器的復制設置。

二、主服務器配置

1. 首先，使用以下命令登錄到 PostgreSQL 數據庫：

su - postgres

2. 使用以下命令創建復制用戶：

psql -c "CREATEUSER replication REPLICATION LOGIN CONNECTION LIMIT 1 ENCRYPTED PASSWORD'YOUR_PASSWORD';"

3. 在 Ubuntu 中使用任何 nano 應用程序編輯pg_hba.cnf并添加以下配置：

nano /etc/postgresql/10/main/pg_hba.conf

4. 使用以下命令配置該文件：

host replication  replication  MasterIP/24  md5

5. 打開并編輯postgresql.conf，并進行以下配置：

nano /etc/postgresql/10/main/postgresql.conf

配置如下：

listen_addresses = 'localhost,MasterIP'
wal_level = replica
wal_keep_segments = 64
max_wal_senders = 10

6. 最后，在主服務器中重啟 PostgreSQL：

systemctl restart postgresql

至此，主服務器配置已經完成。

三、備份服務器配置

1. 使用以下命令登錄到 PostgreSQL RDMS：

su - postgres

2. 停止 PostgreSQL 服務，使用以下命令對其進行處理：

systemctl stop postgresql

3. 使用以下命令編輯pg_hba.conf文件并添加以下配置：

nano /etc/postgresql/10/main/pg_hba.conf

host replication  replication  MasterIP/24  md5

4. 在備份服務器打開并編輯postgresql.conf并放入以下配置，如果有注釋則取消注釋：

nano /etc/postgresql/10/main/postgresql.conf
listen_addresses = 'localhost,SecondaryIP'
wal_keep_segments = 64
wal_level = replica
hot_standby = on
max_wal_senders = 10

SecondaryIP是從服務器的地址。

5. 訪問備份服務器中的 PostgreSQL 數據目錄并刪除所有內容：

cd /var/lib/postgresql/10/main
rm -rfv *

6. 將 PostgreSQL 主服務器數據目錄文件復制到 PostgreSQL 從服務器數據目錄，并在從服務器中寫入以下命令：

pg_basebackup -h MasterIP -D /var/lib/postgresql/11/main/ -P -U
replication --wal-method=fetch

7. 輸入主服務器 PostgreSQL 密碼并按回車鍵。接下來，為恢復配置添加以下命令：

// "Edit" Command
nano /var/lib/postgresql/10/main/recovery.conf
// Configuration
standby_mode   = 'on'
primary_conninfo = 'host=MasterIP port=5432 user=replication password=YOUR_PASSWORD'
trigger_file = '/tmp/MasterNow'

這里YOUR_PASSWORD是主服務器 PostgreSQL 創建的復制用戶的密碼。

8. 設置密碼后，必須重新啟動備份 PostgreSQL 數據庫：

systemctl start postgresql

四、測試配置是否成功

現在已經執行完了這些配置，讓我們測試復制過程并觀察從服務器數據庫是否正常。

首先，我們在主服務器中創建一個表，并觀察它是否反映在備份服務器上。

1. 由于我們在主服務器中創建表，因此需要登錄到主服務器：

su - postgres
psql

2. 現在我們創建一個名為“testtable”的簡單表，并通過在終端中運行以下 PostgreSQL 查詢將數據插入表中：

CREATE TABLE testtable (websites varchar(100));
INSERT INTO testtable VALUES ('section.com');
INSERT INTO testtable VALUES ('google.com');
INSERT INTO testtable VALUES ('github.com');

3. 登錄從服務器觀察從服務器PostgreSQL數據庫：

su - postgres psql

4. 現在，檢查表 'testtable' 是否存在，并且可以通過在終端中運行以下 PostgreSQL 查詢來返回數據。

select * from testtable;

查詢結果如下：

|  websites  |

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

| section.com |

| google.com |

| github.com  |

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

那么測試成功，主服務器數據已經同步到從服務器上了。

PostgreSQL 手動故障轉移步驟

讓我們回顧一下 PostgreSQL 手動故障轉移的步驟：

1. 使用非常規手段將主服務器崩潰。
2. 通過在從服務器上運行以下命令來提升從服務（切為主服務）：

./pg_ctl promote -D ../sb_data/
server promoting

3. 連接到提升后的從服務并插入一行：

-bash-4.2$ ./edb-psql -p 5432 edb

Password:

psql.bin (10.7)

Type "help" for help.

edb=# insert into abc values(4,'Four');

如果插入正常，則從服務（以前是只讀服務）已提升為新的主服務。

如何在 PostgreSQL 中自動進行故障轉移

設置自動故障轉移很容易，需要使用到 EDB PostgreSQL 故障轉移管理器 (EFM)。在每個主節點和備用節點上下載并安裝 EFM 后，你可以創建一個 EFM 集群，該集群由一個主節點、一個或多個備用節點以及一個可選的 Witness 節點組成，該節點在發生故障時確認斷言。

EFM 持續監控系統運行狀況并根據系統事件發送電子郵件警報。當發生故障時，它會自動切換到最新的備用服務并重新配置所有其他備用服務以識別新的主節點。

它還會重新配置負載平衡器（例如 pgPool）并防止發生“裂腦”（當兩個節點都認為它們是主節點時）。

總結

由于存儲數據量大，可伸縮性和安全性已成為數據庫管理中最重要的兩個標準，尤其是在事務環境中。雖然我們可以通過向現有節點添加更多資源/硬件來垂直提高可擴展性，但這并不總是可行的，因為添加新硬件是需要成本的。

因此，就需要 PostgreSQL 復制發揮作用了，它實現了水平可擴展，即向現有網絡節點添加更多節點，而不是增加現有節點的硬件配置。