作為一個開發(fā)者，我們知道一個網(wǎng)站如果數(shù)據(jù)丟失和停機，即使是很少、很短暫，也可能是災難性的，并且降低生產(chǎn)力、可訪問性和產(chǎn)品信心。
為保護站點的完整性，建立防范停機或數(shù)據(jù)丟失的措施至關重要。
數(shù)據(jù)復制是一種自動備份過程，數(shù)據(jù)會從其主數(shù)據(jù)庫復制到另一個遠程位置以進行妥善保管。對于運行數(shù)據(jù)庫服務器的任何站點或應用程序來說，它都是一項不可或缺的技術。我們還可以利用復制的數(shù)據(jù)庫來處理只讀 SQL，從而允許在系統(tǒng)內運行更多進程。
在兩個數(shù)據(jù)庫之間設置復制是很有必要了，它提供了針對意外事故的容錯能力，這也是在災難期間實現(xiàn)高可用性的最佳策略。
在本文中，我們將深入探討 PostgreSQL 復制的不同策略。
什么是 PostgreSQL 復制？
PostgreSQL 復制是將數(shù)據(jù)從PostgreSQL 數(shù)據(jù)庫服務器復制到另一臺服務器的過程。源數(shù)據(jù)庫服務器也稱為“主”服務器，而接收復制數(shù)據(jù)的數(shù)據(jù)庫服務器稱為“副本”服務器。
PostgreSQL 數(shù)據(jù)庫遵循簡單的復制模型，其中所有寫入都轉到主節(jié)點。然后主節(jié)點可以應用這些更改并將它們廣播到輔助節(jié)點。
什么是自動故障轉移？
故障轉移是一種在主服務器因一些原因失效時恢復數(shù)據(jù)的方法。不過只要你配置了 PostreSQL 來進行物理流復制，就不會因主服務器故障而停機。
請注意，故障轉移過程可能需要一些時間來設置和啟動。PostgreSQL 中沒有用于監(jiān)視和確定服務器故障范圍的內置工具，因此需要我們自行發(fā)揮。
不過幸運的是，我們需要依賴 PostgreSQL 進行故障轉移。有專用工具來進行自動故障轉移和自動切換到備用數(shù)據(jù)庫，從而減少數(shù)據(jù)庫停機時間。
通過設置故障轉移復制，即使主服務器崩潰時，也可以通過備用服務器切換來保證高可用性。
使用 PostgreSQL 復制的好處
以下是利用 PostgreSQL 復制的一些主要優(yōu)勢：
- 數(shù)據(jù)遷移：可以通過更改數(shù)據(jù)庫服務器硬件或通過系統(tǒng)部署來使用 PostgreSQL 復制進行數(shù)據(jù)遷移。
- 容錯性：如果主服務器發(fā)生故障，備用服務器可以充當服務器，因為主服務器和備用服務器包含的數(shù)據(jù)是相同的。
- 聯(lián)機事務處理 (OLTP) 性能：可以通過移除報告查詢負載來改進 OLTP 系統(tǒng)的事務處理時間和查詢時間。事務處理時間是在事務完成之前執(zhí)行給定查詢所花費的持續(xù)時間。
- 并行系統(tǒng)測試：在升級新系統(tǒng)時，需要確保系統(tǒng)能夠很好地處理現(xiàn)有數(shù)據(jù)，因此需要在部署前使用生產(chǎn)數(shù)據(jù)庫副本進行測試。
PostgreSQL 復制的工作原理
通常，一般的機構中只有一種方法可以設置備份和復制。然而，PostgreSQL 可以有三種，分別如下：
- 流復制：將數(shù)據(jù)從主節(jié)點復制到從節(jié)點，然后將數(shù)據(jù)復制到 S3 等文件服務器進行備份存儲。
- 卷級復制：在存儲層復制數(shù)據(jù)，從主節(jié)點開始復制到從節(jié)點，然后將數(shù)據(jù)復制到 S3 等進行備份存儲。
- 增量備份：從主節(jié)點復制數(shù)據(jù)，同時從 S3 等文件服務器存儲構建新的輔助節(jié)點，允許直接從主節(jié)點流式傳輸。
方法一：流復制
PostgreSQL 流復制也稱為 WAL 復制，可以在服務器上安裝 PostgreSQL 后無縫設置。這種復制方法基于將 WAL 文件從主數(shù)據(jù)庫復制到目標數(shù)據(jù)庫來完成的。
通過使用主從配置來實現(xiàn) PostgreSQL 流式復制。主服務器是處理主數(shù)據(jù)庫及其所有操作的主要實例。輔助服務器充當補充實例并執(zhí)行復制對主數(shù)據(jù)庫所做的所有更改，并在此過程中生成相同的副本。主服務器是讀/寫服務器，而輔助服務器只是只讀的。
這種方法需要同時配置主節(jié)點和備節(jié)點。以下部分將闡明配置所涉及的步驟。
配置主節(jié)點
通過執(zhí)行以下步驟來配置主節(jié)點：
第一步：初始化數(shù)據(jù)庫
我們可以利用 initdb 程序命令來初始化數(shù)據(jù)庫。接下來，使用命令創(chuàng)建具有復制權限的新用戶：
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：此參數(shù)用于啟用 PostgreSQL 流復制，值包括minimal、replica或logical。
- wal_log_hints：控制在 WAL 日志文件中是否包含有關寫入哪個數(shù)據(jù)文件的提示信息。當該參數(shù)設置為 ON 時，WAL 日志中的每個記錄將包含有關數(shù)據(jù)文件的信息，以便在進行數(shù)據(jù)庫恢復時可以更快地定位需要恢復的數(shù)據(jù)。當備用服務器與主服務器不同步時，此參數(shù)是pg_rewind 功能所必需的。
- max_wal_senders：指定可以與備用服務器建立的最大并發(fā)連接數(shù)。
- max_wal_size：指定可保留在日志文件中的 WAL 文件的大小。
- hot_standby：當它設置為 ON 時，可以利用此參數(shù)與輔助設備建立讀取連接。
第三步：創(chuàng)建新條目
修改 postgresql.conf 文件中的參數(shù)后， pg_hba.conf 文件中的新 replication 條目可以允許服務器相互建立連接以進行復制。
可以在 PostgreSQL 的數(shù)據(jù)目錄中找到這個文件，配置條目如下：
host replication rep_user IPaddress md5
執(zhí)行以下代碼片段后，主服務器就允許調用的用戶（rep_user）通過使用指定的 IP 進行連接并充當備用服務器進行復制。示例：
host replication rep_user 192.168.0.22/32 md5
配置備節(jié)點
步驟 1：備份主節(jié)點
要配置備用節(jié)點，需要用 pg_basebackup 程序生成主節(jié)點的備份，這將作為備用節(jié)點的起點。命令如下：
pg_basebackp -D -h -X stream -c fast -U rep_user -W
上述語法中使用的參數(shù)如下：
- -h：主要主機。
- -D：表示當前正在處理的目錄。
- -C：設置檢查點。
- -X：此參數(shù)可用于包含必要的事務日志文件。
- -W：設置用戶在連接到數(shù)據(jù)庫之前提示用戶輸入密碼。
步驟 2：設置復制節(jié)點配置文件
接下來，我們需要檢查復制配置文件是否存在。如果沒有，生成復制配置文件，名稱為：recovery.conf。
在 PostgreSQL 安裝的數(shù)據(jù)目錄中創(chuàng)建此文件，也可以用 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'
上述命令中使用的參數(shù)如下：
- primary_conninfo：通過利用連接字符串在主服務器和輔助服務器之間建立連接。
- standby_mode：通過啟用"pg_standby_mode"模式，備用服務器可以在主服務器失效時，接管主服務器的職責，確保數(shù)據(jù)的可用性和持久性。
- recovery_target_timeline：設置恢復時間線。在數(shù)據(jù)庫恢復時，需要指定恢復的時間線，以便將備份數(shù)據(jù)正確地還原到指定的時間點。
要建立連接，需要提供用戶名、IP 地址和密碼作為 primary_conninfo 參數(shù)的值。示例：
primary_conninfo = 'host=192.168.0.26 port=5432 user=rep_user password=rep_pass'
步驟 3：重新啟動備份服務器
最后，重新啟動備份服務器以完成配置過程。
然而，流復制會帶來一些挑戰(zhàn)，例如：
- 各種 PostgreSQL 客戶端（用不同的編程語言編寫）與單個端點進行交互。當主節(jié)點出現(xiàn)故障時，這些客戶端將繼續(xù)重試相同的 DNS 或 IP 名稱。這使得故障轉移對應用程序可見。
- PostgreSQL 復制沒有內置的故障轉移和監(jiān)控功能。當主節(jié)點發(fā)生故障時，我們需要將一個備份節(jié)點提升為新的主節(jié)點。這種提升需要讓用戶無感知，且不會出現(xiàn)數(shù)據(jù)不一致問題。
- PostgreSQL 需要復制主節(jié)點的整個狀態(tài)。當你需要開發(fā)一個新的備份節(jié)點時，需要從主節(jié)點重放狀態(tài)變化的整個歷史，這會導致很大的資源消耗，并且使得刪除頭部節(jié)點和創(chuàng)建新節(jié)點的成本很高。
方法二：RBD（塊設備復制）
?RBD 方法依賴于磁盤鏡像（也稱為卷復制）。在這種方法中，更改被寫入一個持久卷，該卷被同步鏡像到另一個卷。
RBD 是一個基于Ceph分布式存儲系統(tǒng)的塊設備復制方案，用于在PostgreSQL數(shù)據(jù)庫中實現(xiàn)高可用性和容錯性。它通過將主服務器上的數(shù)據(jù)塊實時復制?到備用服務器上，以確保在主服務器出現(xiàn)故障或宕機時，備用服務器可以立即接管其職責。
RBD是一個基于網(wǎng)絡塊設備的復制方案，它可以在多個Ceph節(jié)點之間實現(xiàn)數(shù)據(jù)復制，并通過Ceph的故障轉移機制來保證數(shù)據(jù)的可用性和一致性。在RBD中，主服務器和備用服務器之間通過Ceph集群的網(wǎng)絡通信，實現(xiàn)數(shù)據(jù)塊的實時復制和同步。
與其他流復制方案相比，RBD具有以下優(yōu)點：
- 數(shù)據(jù)復制速度更快：RBD通過Ceph的對象存儲方式來管理數(shù)據(jù)，可以實現(xiàn)高效的數(shù)據(jù)復制和同步，比傳統(tǒng)的流復制方案速度更快。
- 數(shù)據(jù)安全性更高：RBD可以使用Ceph的數(shù)據(jù)加密和數(shù)據(jù)壓縮功能，提高數(shù)據(jù)的安全性和傳輸效率。
- 可擴展性更好：RBD可以根據(jù)需要對Ceph存儲集群進行擴展，以滿足不同的存儲需求。
- 系統(tǒng)穩(wěn)定性更高：由于RBD是基于Ceph的分布式存儲系統(tǒng)實現(xiàn)的，因此具有更好的容錯性和可靠性，可以確保數(shù)據(jù)的可用性和一致性。
方法三：WAL
WAL 由段文件組成（默認為 16 MB）。每個段都有一個或多個記錄。日志序列記錄 (LSN) 是指向 WAL 中記錄的指針，用于記錄在日志文件中保存的位置（position/location）。
備份服務器利用 WAL 段（在 PostgreSQL 術語中也稱為 XLOGS）從其主服務器不斷復制更改。你可以通過在DBMS中使用預寫日志（write-ahead logging）來為數(shù)據(jù)提供持久性和原子性，具體做法是在將字節(jié)數(shù)組數(shù)據(jù)塊（每個塊都帶有唯一的LSN）應用到數(shù)據(jù)庫之前，將它們序列化并寫入穩(wěn)定的存儲介質
將變更應用到數(shù)據(jù)庫可能會引起各種文件系統(tǒng)操作。一個相關的問題是，在文件系統(tǒng)更新過程中，如果服務器由于停電而發(fā)生故障，數(shù)據(jù)庫如何確保原子性。具體做法是當數(shù)據(jù)庫啟動時，它會開始一個啟動或重放過程，該過程可以讀取可用的WAL段，并將它們與存儲在每個數(shù)據(jù)頁上的LSN進行比較（每個數(shù)據(jù)頁都標記有影響該頁的最新WAL記錄的LSN）。
基于日志發(fā)送的復制（塊級）
流復制改進了日志發(fā)送的過程。與等待WAL切換不同，記錄在創(chuàng)建時就被發(fā)送，從而減少了復制延遲。
流復制也勝過日志發(fā)送，因為備份服務器通過復制協(xié)議在網(wǎng)絡上與主服務器建立連接。主服務器可以直接通過這個連接發(fā)送WAL記錄，而不必依賴于用戶提供的腳本。
基于日志發(fā)送的復制（文件級）
日志發(fā)送是將日志文件復制到另一臺PostgreSQL服務器，通過重放WAL文件生成另一臺備用服務器。且此服務器被配置為在恢復模式下工作，目的是為了在監(jiān)聽新的 WAL 文件，并進行應用。
備份服務器將成為主 PostgreSQL 服務器的熱備份。它還可以配置為只讀副本，可以提供只讀查詢。
WAL 歸檔
在創(chuàng)建 WAL 文件時將其復制到除pg_wal子目錄以外的任何位置以將其歸檔稱為 WAL 歸檔。每次創(chuàng)建 WAL 文件時，PostgreSQL 都會調用用戶提供的腳本進行歸檔。
該腳本可以利用該scp命令將文件復制到一個或多個位置，例如 NFS 。存檔后，可以利用 WAL 段文件恢復數(shù)據(jù)庫到任何給定時間點。
其他基于日志的配置如下：
- 同步復制：在提交每個同步復制事務之前，主服務器會等待備用服務器以確認它們已獲取數(shù)據(jù)。這種配置的好處是不會因為并行寫入進程而導致任何沖突。
- 同步多主復制：這種情況下，每個服務器都可以接受寫入請求，并且在每個事務提交之前，修改后的數(shù)據(jù)從原始服務器傳輸?shù)矫總€其他服務器。它利用 2PC 協(xié)議并遵守全有或全無規(guī)則。
WAL 流協(xié)議詳細信息
WAL接收器的進程運行在備用服務器上，利用recovery.conf中提供的primary_conninfo參數(shù)中的連接詳細信息，通過TCP/IP連接到主服務器。
開始流式復制時，前端可以在啟動消息中發(fā)送復制參數(shù)。值為true、yes、1或ON的布爾值讓后端知道它需要進入物理復制walsender模式。
WAL發(fā)送器是在主服務器上運行的另一個進程，負責在生成WAL記錄時將其發(fā)送到備用服務器。WAL接收器將WAL記錄保存在WAL中，就像本地的客戶端連接一樣。
一旦WAL記錄到達WAL段文件，備用服務器就不斷地重放WAL，以使主服務器和備用服務器保持最新同步狀態(tài)。
PostgreSQL 復制的要素
接下來我們將更深入地了解 PostgreSQL 復制的常用模型（單主復制和多主復制）、類型（物理復制和邏輯復制）以及模式（同步和異步）。
PostgreSQL 數(shù)據(jù)庫復制模型
可擴展性是指向現(xiàn)有節(jié)點添加更多資源/硬件，以增強數(shù)據(jù)庫存儲和處理更多數(shù)據(jù)的能力，可以進行水平和垂直擴展。PostgreSQL 復制是水平可伸縮性的一個例子，它比垂直可伸縮性更難實現(xiàn)。主要通過單主復制（SMR）和多主復制（MMR）來實現(xiàn)水平擴展。
單主復制僅允許在單個節(jié)點上修改數(shù)據(jù)，并將這些修改復制到一個或多個節(jié)點。副本數(shù)據(jù)庫中的復制表不允許接受任何更改，但來自主服務器的更改除外。
大多數(shù)時候，SMR 足以滿足應用程序的需求，因為它的配置和管理不那么復雜，而且不會發(fā)生沖突。單主復制也是單向的，因為復制數(shù)據(jù)主要在一個方向上流動，從主數(shù)據(jù)庫到副本數(shù)據(jù)庫。
在某些情況下，單靠 SMR 可能不夠，你可能需要實施 MMR。MMR 允許多個節(jié)點充當主節(jié)點。對多個指定主數(shù)據(jù)庫中表行的更改將復制到每個其他主數(shù)據(jù)庫中的對應表。在這個模型中，經(jīng)常采用沖突解決方案來避免重復主鍵等問題。
使用 MMR 有幾個優(yōu)點，即：
- 在主機故障的情況下，其他主機仍然可以提供更新和插入服務。
- 主節(jié)點分布在幾個不同的位置，因此所有主節(jié)點發(fā)生故障的可能性很小。
- 能夠使用主數(shù)據(jù)庫的廣域網(wǎng) (WAN)，這些主數(shù)據(jù)庫在地理位置上可以靠近客戶端組，同時保持網(wǎng)絡中的數(shù)據(jù)一致性。
然而，實施 MMR 的缺點是復雜性和沖突難以解決。
一些機構和應用程序提供 MMR 解決方案，因為 PostgreSQL 本身并不支持。這些解決方案可能是開源的、免費的或付費的。如雙向復制 (BDR)，它是異步的并且基于 PostgreSQL 邏輯解碼功能。
由于 BDR 應用程序在其他節(jié)點上重放事務，如果正在應用的事務與在接收節(jié)點上提交的事務之間存在沖突，重放操作可能會失敗。
PostgreSQL 復制的類型
PostgreSQL 復制有兩種類型：邏輯復制和物理復制。
一個簡單的 initdb 邏輯操作，將會執(zhí)行為集群創(chuàng)建基準目錄的物理操作。同樣，一個簡單的邏輯操作（CREATE DATABASE）將執(zhí)行為在基準目錄中創(chuàng)建子目錄的物理操作。
物理復制通常處理文件和目錄。它不知道這些文件和目錄代表什么。物理復制方法用于在另一臺機器上維護單個集群的完整數(shù)據(jù)副本，并且在文件系統(tǒng)級別或磁盤級別進行，并使用精確的塊地址。
邏輯復制是一種根據(jù)復制標識（通常是主鍵）復制數(shù)據(jù)實體及其修改的方法。與物理復制不同，它處理數(shù)據(jù)庫、表和 DML 操作，并在數(shù)據(jù)庫集群級別完成。它使用發(fā)布和訂閱模型，一個訂閱者可以訂閱發(fā)布者節(jié)點上的一個或多個發(fā)布。
復制過程首先對發(fā)布者數(shù)據(jù)庫上的數(shù)據(jù)進行快照，然后將其復制到訂閱者。訂閱者從他們訂閱的發(fā)布中提取數(shù)據(jù)，并可能稍后重新發(fā)布數(shù)據(jù)，以允許級聯(lián)復制或更復雜的配置。訂閱者以與發(fā)布者相同的順序應用數(shù)據(jù)，以便保證單個訂閱內的發(fā)布的事務一致性，也稱為事務復制。
邏輯復制的典型場景如下：
- 將單個數(shù)據(jù)庫（或數(shù)據(jù)庫的子集）中的增量更改發(fā)送給訂閱者。
- 在多個數(shù)據(jù)庫之間共享數(shù)據(jù)庫的一個子集。
- 在單個更改到達訂閱者時觸發(fā)它們的觸發(fā)事件。
- 將多個數(shù)據(jù)庫合并為一個。
- 為不同的用戶組提供對復制數(shù)據(jù)的訪問。
訂閱者數(shù)據(jù)庫的行為方式與任何其他 PostgreSQL 實例相同，并且可以通過定義其發(fā)布來用作其他數(shù)據(jù)庫的發(fā)布者。
當訂閱者被應用程序配置成只讀時，單個訂閱不會發(fā)生沖突。不過，如果應用程序或其他訂閱者對同一組表進行了寫入，則可能會出現(xiàn)沖突。
PostgreSQL 同時支持這兩種機制。邏輯復制允許對數(shù)據(jù)復制和安全性進行細粒度控制。
復制模式
PostgreSQL 復制主要有兩種模式：同步和異步。同步復制允許同時將數(shù)據(jù)寫入主服務器和從服務器，而異步復制確保數(shù)據(jù)先寫入主服務器，然后再復制到從服務器。
在同步模式復制中，只有當這些更改已復制到所有副本時，主數(shù)據(jù)庫上的事務才被視為完成。副本服務器必須始終可用，以便在主服務器上完成事務。同步復制模式用于具有即時故障轉移要求的高端事務環(huán)境。
在異步模式下，當只在主服務器上完成更改時，可以聲明主服務器上的事務已完成。這些更改隨后會及時復制到副本中。副本服務器可以在一段時間內保持不同步，稱為復制滯后。在崩潰的情況下，可能會發(fā)生數(shù)據(jù)丟失，但異步復制提供的開銷很小，因此在大多數(shù)情況下是可以接受的（不會使主服務器負擔過重）。
如何設置 PostgreSQL 復制
接下來，我們將演示如何在 linux 操作系統(tǒng)上設置 PostgreSQL 復制過程。對于本例，我們將使用 Ubuntu 18.04 LTS 和 PostgreSQL 10。
一、安裝
通過以下步驟在 Linux 上安裝 PostgreSQL：
- 首先，通過在終端中鍵入以下命令來導入 PostgreSQL 簽名密鑰
wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O- | sudo apt-key add -
- 然后，添加 PostgreSQL 存儲庫：
echo "deb http://apt.postgresql.org/pub/repos/apt/ bionic-pgdg main" | sudo tee /etc/apt/sources.list.d/postgresql.list
- 更新存儲庫索引：
sudo apt-get update
- 使用 apt 命令安裝 PostgreSQL 包：
sudo apt-get install -y postgresql-10
- 最后，使用以下命令為 PostgreSQL 用戶設置密碼：
sudo passwd postgres
在進行 PostgreSQL 復制過程之前，主服務器和備份服務器都必須安裝 PostgreSQL。
在兩臺服務器上設置 PostgreSQL 后，可以繼續(xù)進行主服務器和備份服務器的復制設置。
二、主服務器配置
- 首先，使用以下命令登錄到 PostgreSQL 數(shù)據(jù)庫：
su - postgres
- 使用以下命令創(chuàng)建復制用戶：
psql -c "CREATEUSER replication REPLICATION LOGIN CONNECTION LIMIT 1 ENCRYPTED PASSWORD'YOUR_PASSWORD';"
- 在 Ubuntu 中使用任何 nano 應用程序編輯pg_hba.cnf并添加以下配置：
nano /etc/postgresql/10/main/pg_hba.conf
- 使用以下命令配置該文件：
host replication replication MasterIP/24 md5
- 打開并編輯postgresql.conf，并進行以下配置：
nano /etc/postgresql/10/main/postgresql.conf
配置如下：
listen_addresses = 'localhost,MasterIP'
wal_level = replica
wal_keep_segments = 64
max_wal_senders = 10
- 最后，在主服務器中重啟 PostgreSQL：
systemctl restart postgresql
至此，主服務器配置已經(jīng)完成。
三、備份服務器配置
- 使用以下命令登錄到 PostgreSQL RDMS：
su - postgres
- 停止 PostgreSQL 服務，使用以下命令對其進行處理：
systemctl stop postgresql
- 使用以下命令編輯pg_hba.conf文件并添加以下配置：
nano /etc/postgresql/10/main/pg_hba.conf
host replication replication MasterIP/24 md5
- 在備份服務器打開并編輯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是從服務器的地址。
- 訪問備份服務器中的 PostgreSQL 數(shù)據(jù)目錄并刪除所有內容：
cd /var/lib/postgresql/10/main
rm -rfv *
- 將 PostgreSQL 主服務器數(shù)據(jù)目錄文件復制到 PostgreSQL 從服務器數(shù)據(jù)目錄，并在從服務器中寫入以下命令：
pg_basebackup -h MasterIP -D /var/lib/postgresql/11/main/ -P -U
replication --wal-method=fetch
- 輸入主服務器 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 創(chuàng)建的復制用戶的密碼。
- 設置密碼后，必須重新啟動備份 PostgreSQL 數(shù)據(jù)庫：
systemctl start postgresql
四、測試配置是否成功
現(xiàn)在已經(jīng)執(zhí)行完了這些配置，讓我們測試復制過程并觀察從服務器數(shù)據(jù)庫是否正常。
首先，我們在主服務器中創(chuàng)建一個表，并觀察它是否反映在備份服務器上。
- 由于我們在主服務器中創(chuàng)建表，因此需要登錄到主服務器：
su - postgres
psql
- 現(xiàn)在我們創(chuàng)建一個名為“testtable”的簡單表，并通過在終端中運行以下 PostgreSQL 查詢將數(shù)據(jù)插入表中：
CREATE TABLE testtable (websites varchar(100));
INSERT INTO testtable VALUES ('section.com');
INSERT INTO testtable VALUES ('google.com');
INSERT INTO testtable VALUES ('github.com');
- 登錄從服務器觀察從服務器PostgreSQL數(shù)據(jù)庫：
su - postgres psql
- 現(xiàn)在，檢查表 'testtable' 是否存在，并且可以通過在終端中運行以下 PostgreSQL 查詢來返回數(shù)據(jù)。
select * from testtable;
查詢結果如下：
| websites |
-------------------
| section.com |
| google.com |
| github.com |
--------------------
那么測試成功，主服務器數(shù)據(jù)已經(jīng)同步到從服務器上了。
PostgreSQL 手動故障轉移步驟
讓我們回顧一下 PostgreSQL 手動故障轉移的步驟：
- 使用非常規(guī)手段將主服務器崩潰。
- 通過在從服務器上運行以下命令來提升從服務（切為主服務）：
./pg_ctl promote -D ../sb_data/
server promoting
- 連接到提升后的從服務并插入一行：
-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)。在每個主節(jié)點和備用節(jié)點上下載并安裝 EFM 后，你可以創(chuàng)建一個 EFM 集群，該集群由一個主節(jié)點、一個或多個備用節(jié)點以及一個可選的 Witness 節(jié)點組成，該節(jié)點在發(fā)生故障時確認斷言。
EFM 持續(xù)監(jiān)控系統(tǒng)運行狀況并根據(jù)系統(tǒng)事件發(fā)送電子郵件警報。當發(fā)生故障時，它會自動切換到最新的備用服務并重新配置所有其他備用服務以識別新的主節(jié)點。
它還會重新配置負載平衡器（例如 pgPool）并防止發(fā)生“裂腦”（當兩個節(jié)點都認為它們是主節(jié)點時）。
總結
由于存儲數(shù)據(jù)量大，可伸縮性和安全性已成為數(shù)據(jù)庫管理中最重要的兩個標準，尤其是在事務環(huán)境中。雖然我們可以通過向現(xiàn)有節(jié)點添加更多資源/硬件來垂直提高可擴展性，但這并不總是可行的，因為添加新硬件是需要成本的。
因此，就需要 PostgreSQL 復制發(fā)揮作用了，它實現(xiàn)了水平可擴展，即向現(xiàn)有網(wǎng)絡節(jié)點添加更多節(jié)點，而不是增加現(xiàn)有節(jié)點的硬件配置。
