# 25.2\. 日志傳送備份服務器 連續歸檔可以配合隨時準備取代失效主服務器的一個或多個_備份服務器_， 用于創建一個_高可用性_(HA)集群。 這個能力通常被稱為_熱備份_或_日志傳送_。 雖然主服務器和備份服務器只是松散的耦合在一起， 但它們必須同時運行。主服務器以連續歸檔模式運行， 備份服務器以連續恢復模式運行并從主服務器不停的讀取WAL文件。 因為數據庫的表無需為此進行任何改變，所以與其它復制方法相比， 額外的管理開銷很小。并且這種方法對主服務器的性能影響也很小。 直接從一個數據庫服務器移動WAL到另一個服務器通常被稱為日志傳送(LogShipping)。 PostgreSQL實現了基于文件的日志傳送， 意思是WAL記錄每次移動一個完整的文件(WAL段)。 WAL文件（16MB）可以被輕易的在任意兩個地點之間傳送， 不管是與鄰近的系統還是地球另一面的系統。 所需帶寬取決于主服務器的事務發生速度。 基于記錄的日志傳送更加細粒度，并且WAL流在網絡連接中增量改變。 日志傳送是異步的，也就是WAL記錄在事務提交之后才被傳送。 也就是說主服務器遭遇致命故障后尚未傳送的事務數據將會丟失。 數據丟失的長度可以使用`archive_timeout`加以限制，比如限制為幾秒鐘。 當然這么小的設置也導致了傳送帶寬的大幅增長。 流復制（參閱[Section 25.2.5](#calibre_link-1048)）允許數據丟失的更小窗口。 恢復性能足夠好，備份服務器一旦被激活通常只有很短的時間不能使用。 因此，我們認為這個方案可以作為熱備份來提供高可用性。 將服務器從一個已歸檔的基礎備份中恢復將可能耗費大量時間， 所以這個方案只能用于災難恢復而不能用于提供高可用性。 備用服務器還可以用于只讀查詢，在這種情況下它被稱為熱備份服務器。 參見[Section 25.5](#calibre_link-1047)獲取更多信息。 ## 25.2.1\. 規劃 至少從數據庫服務器的角度看， 創建主服務器和備份服務器并令兩者盡可能完全相同是非常明智的。 特別是表空間的路徑名必須保持完全一致， 這樣主服務器和備份服務器就必須擁有同樣的表空間掛載路徑(如果使用了表空間的話)。 需要記住的是如果在主服務器上執行了[CREATE TABLESPACE](#calibre_link-99)命令， 那么該命令需要的任何新掛載點必須在執行該命令之前同時在主服務器和備份服務器 上創建。 硬件不必完全相同，但是經驗顯示維護兩個完全相同的系統比維護兩 個不同的系統要少許多麻煩。 無論如何，應盡量保持體系結構相同— 比如一個是32-bit系統另一個是64-bit系統將不能正常工作。 通常，在主PostgreSQL版本不同的服務器之間傳送日志是不可能的， 它是PostgreSQL全球開發組在次要版本升級中不能改變磁盤格式的一種策略。 在主服務器和備份服務器上運行不同的次要版本可能成功。 但是，沒有正式支持，建議你盡可能的保持主服務器和備用服務器在同一個級別上。 在進行版本升級的時候，正確的做法是首先升級備份服務器— 因為新版本的服務器通常可以讀取老版本的WAL文件，但反之則不然。 ## 25.2.2\. 備用服務器操作 在備用模式，該服務器連續應用從主服務器收取的WAL。 備服務器可以從一個WAL歸檔（參閱[restore_command](#calibre_link-1656)） 或直接通過一個TCP連接（流復制）從主服務器上讀取WAL。 備服務器也可以在備用集群`pg_xlog`嘗試查找恢復任何WAL。 這通常發生在服務器重啟后，當備服務器重播，在備服務器重啟前， 從主服務器流復制的WAL，但是你也可以手工復制文件到`pg_xlog`， 在任何時候可以重播它們。 在啟動，備服務器恢復可用在所有的WAL開始存檔位置,調用`restore_command`。 一旦它到達可用WAL的結束，`restore_command`失敗， 將嘗試恢復`pg_xlog`目錄下任何可用的WAL。 如果那也失敗了，并且已經配置了流復制，則嘗試連接到主服務器， 從在歸檔或`pg_xlog`找到最后一條有效的記錄開始WAL流。如果那也失敗了， 或沒有配置流復制，或連接斷開，備服務器再次回到步驟1，循環嘗試從歸檔里恢復文件。 從歸檔，`pg_xlog`，通過連續流復制直到服務器停止或有觸發器文件觸發的失效切換時。 當運行`pg_ctl promote`時，或者找到一個觸發文件（`trigger_file`）時， 退出備用模式并且服務器切換到正常運行。 在失效切換前，將立即恢復歸檔或`pg_xlog`任何可用的WAL， 但不做嘗試連接主服務器。 ## 25.2.3\. 為備用服務器準備主服務器 在主服務器上設置連續歸檔到一個備服務器可訪問的存檔目錄， 正如[Section 24.3](#calibre_link-466)所描述的。即使主服務器關掉， 從備服務器應該可以訪問這個歸檔位置。 即它應該駐留在被服務器自身或其它可信賴的服務器， 而不是主服務器。 如果你想使用流復制，在主服務器上設置認證，允許從備用服務器復制連接； 在`pg_hba.conf`提供一個或多個合適項使用數據庫字段設置`replication`。 還要在主服務器的配置文件確保設置`max_wal_senders`足夠大。 啟動備用服務器做一個基準備份，參見[Section 24.3.2](#calibre_link-1632)。 ## 25.2.4\. 建立備用服務器 要建立備用服務器，從主服務器恢復基準備份（參閱[Section 24.3.4](#calibre_link-1634)）。 在備用服務器的集群數據目錄，創建一個恢復命令文件`recovery.conf`, 開啟`standby_mode`。設置`restore_command` 為一條從WAL歸檔復制文件的簡單命令。如果為了高可用性目的計劃有多個備用服務器， 設置`recovery_target_timeline`為`latest`， 使得備用服務器按照發生故障轉移到另一個備用服務器的時間變化。 > **Note:** 不要使用內置在這里描述的備用模式pg_standby或類似的工具。 如果該文件不存在，`restore_command`應該立即返回。 如果必要服務器將再次嘗試這個命令。 關于使用工具像pg_standby的詳情參閱[Section 25.4](#calibre_link-1282)。 如果你想使用流復制，在`primary_conninfo`填寫一個libpq連接串， 其包括主機名（或IP地址）和連接到主服務器需要的其它詳細信息。 如果主服務器需要個密碼驗證，也要在`primary_conninfo`指定所需要的密碼。 如果你要建立高可用目的備服務器，設置WAL歸檔， 像主服務器的連接和身份驗證，因為在失效切換后， 備服務器要作為主服務器運行。 如果你使用WAL歸檔，其大小可以使用[archive_cleanup_command](#calibre_link-1657)這個參數設置最小 ，用來刪除那些備服務器不再需要的文件。 專門設計的pg_archivecleanup這個實用程序就是在通常的單備配置里， 使用`archive_cleanup_command`的。參閱[pg_archivecleanup](#calibre_link-1096)。 請注意，如果你使用備份目的歸檔， 你仍要保留需要恢復的至少最新的基準備份文件， 即使備服務器不再需要。 `recovery.conf`的一個簡單例子： ``` standby_mode = 'on' primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' restore_command = 'cp /path/to/archive/%f %p' archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r' ``` 你可能有任何數目的備服務器，但是如果你用流復制， 確保你在主服務器上設置的`max_wal_senders`足夠大允許它們同時連接。 ## 25.2.5\. 流復制 與基于文件日志傳送相比，流復制允許保持備服務器更新。 備服務器連接主服務器，其產生的流WAL記錄到備服務器， 而不需要等待填寫WAL文件。 流復制是異步的，參閱[Section 25.2.7](#calibre_link-1439)， 在主服務器上提交事務和備用服務器上變化可見之間有一個小的延遲。 這個延遲遠小于基于文件日志傳送，通常1秒內足夠與負載保持。 使用流復制，為減少數據丟失窗口`archive_timeout`不是必要的。 如果使用流復制而不是基于文件連續歸檔， 你要在主服務器設置`wal_keep_segments`為一個足夠大的值以使不太早的回收舊WAL段， 當備服務器可能仍需要它們趕上。如果備服務器落后太多， 需要用一個新基準備份重新初始化。如果你設置一個備服務器可訪問的WAL歸檔， `wal_keep_segments`是不必要的， 作為備服務器總是使用歸檔來趕上。 要使用流復制，建立一個基于文件的日志傳送備服務器描述在[Section 25.2](#calibre_link-1133)。 該步將一個基于文件的日志傳送備服務器轉為流復制備服務器， 在`recovery.conf`文件中設置`primary_conninfo`指向主服務器。 在主服務器上設置[listen_addresses](#calibre_link-1559)和身份驗證選項 （參閱`pg_hba.conf`）， 因此備用服務器可以連接到在主服務器的`replication`偽數據庫 （參閱[Section 25.2.5.1](#calibre_link-1658)）。 系統上支持保持活動的套接字選項， 設置[tcp_keepalives_idle](#calibre_link-1659), [tcp_keepalives_interval](#calibre_link-1660)和 [tcp_keepalives_count](#calibre_link-1661) 幫助主機及時發現斷開的連接。 設置備用服務器的最大并發連接數。 （參閱[max_wal_senders](#calibre_link-470)獲取更多詳細信息）。 當啟動了備服務器并且正確設置了`primary_conninfo`, 該備服務器在回放所有可用的WAL文件后，將連接到主服務器。如果成功建立了該連接， 你將在備服務器中看到WAL接收進程，并且在主服務器相應的一個WAL發送進程。 ### 25.2.5.1\. 身份驗證 復制的訪問權限設置是很重要的，所以只有受信任的用戶可以讀取WAL流， 因為很容易從中提取權限信息。備服務器必須驗證作為主服務器的超級用戶或者有 `REPLICATION`權限的用戶。 建議為復制創建一個帶有`REPLICATION`和`LOGIN`權限的專有用戶賬號。 當`REPLICATION`權限有很高權限時，不允許用戶修改主服務器上的任何數據， 其中`SUPERUSER`就是這樣的。 由一條`pg_hba.conf`記錄指定`replication`在`_database_`字段， 控制客戶端的復制驗證。例如，如果備服務器是運行在主機IP `192.168.1.100`和復制時超級用戶名為`foo`， 管理員可以在主服務器`pg_hba.conf`文件里添加下面行： ``` # Allow the user "foo" from host 192.168.1.100 to connect to the primary # as a replication standby if the user's password is correctly supplied. # # TYPE DATABASE USER ADDRESS METHOD host replication foo 192.168.1.100/32 md5 ``` 主服務器的主機名和端口號，連接用戶名，和在`recovery.conf`文件指定的密碼。 該密碼也可以在備服務器的`~/.pgpass`文件里設置。 （在`_database_`字段指定`replication`）。例如， 如果主服務器是運行的主機IP `192.168.1.50`,端口號`5432`, 復制時用戶名為`foo`，和密碼為`foopass`， 管理員可以在備服務的`recovery.conf`文件里添加下面行： ``` # The standby connects to the primary that is running on host 192.168.1.50 # and port 5432 as the user "foo" whose password is "foopass". primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' ``` ### 25.2.5.2\. 監控 流復制的一個重要的健康指標是在主服務器生成的WAL記錄數， 而不是在備服務器應用的數量。通過比較在主服務器當前WAL寫的位置和備服務器收到 的最后一個WAL位置，就可以計算出這種滯后。 在主服務器上使用`pg_current_xlog_location`和在備服務器上使用 `pg_last_xlog_receive_location`可以分別檢索到它們 （參閱[Table 9-60](#calibre_link-1642)和 [Table 9-61](#calibre_link-1049)關于詳細信息）。 在備服務器收到最后的WAL位置也會進程狀態的WAL接收進程顯示， 使用`ps`命令顯示（參閱[Section 27.1](#calibre_link-1287)關于詳細信息）。 你可以通過 [`pg_stat_replication`](#calibre_link-1440)視圖回收WAL發送程序列表。 在`pg_current_xlog_location`和`sent_location`字段之間的不同可能表明 主服務器在大負載下，而備庫上`sent_location`和 `pg_last_xlog_receive_location`的不同可能表明網絡延遲，或者備庫也處于重大負載之下。 ## 25.2.6\. Cascading Replication 級聯復制功能允許備用服務器接受復制連接和到其他備庫的流WAL記錄，充當延遲。 這可以用來降低直接連接主庫的數量，同時也盡量減少站點間的帶寬開銷。 同時充當接收器和發送器的待機稱為級聯 待機狀態。更直接地連接到主庫的備庫作為上游服務器已知， 而備用服務器較遠的下游服務器。級聯復制不放在數量限制或 下游服務器的安排，雖然每個備庫連接到一個上流服務器， 而最終鏈接到一個單一的主/主服務器。 級聯備庫不僅僅發送來自主庫的WAL記錄，而且來自歸檔的記錄。 因此即使一些上流連接的復制連接終止， 連接復制繼續往下只要有新的WAL記錄可用。 級聯復制當前是異步的，同步復制（參閱[Section 25.2.7](#calibre_link-1439)）設置當前不影響級聯復制。 熱備用反饋傳播到上游，無論級聯配置。 如果上游備用服務器上升成為新主庫，下游服務器將繼續流向新主庫， 如果`recovery_target_timeline`設置為`'latest'`。 使用級聯復制，建立連鎖備庫從而接受復制連接（即設置 [max_wal_senders](#calibre_link-470)和[hot_standby](#calibre_link-1134)， 以及配置[host-based authentication](#calibre_link-656)）。 在下游備庫指向級聯備庫中你還需要設定`primary_conninfo`。 ## 25.2.7\. 同步復制 PostgreSQL流復制缺省是異步的。如果主服務器崩潰，然后一些事務承諾不得不 復制到備用服務器，造成數據丟失。數據丟失量是與故障轉移時的復制延遲是成比例的。 同步復制提供確認所有變化已經由事務轉移到一個同步備用服務器的能力。 這延伸一個事務提交的耐久性標準。 這種級別的保護是指2-安全復制的計算機科學理論。 當請求同步復制，每次提交的寫事務將等待直到確認收到提交已被寫入到主庫和備用服務器磁盤上的事務日志。 這些數據丟失的可能性是如果主庫和備庫同一時間遭受崩潰。 這可以提供一個更高層次的耐久性，但如果系統管理員對兩個服務器的安置和管理非常謹慎。 等待確認增加用戶的信心，在服務器崩潰的情況下更改將不會丟失，而是增加請求事務的響應時間。 最小等待時間是主庫到備庫的往返時間。 只讀事務和事務回滾不需要等待從備用服務器的回復。 子事務提交不等待從備用服務器的響應，只有頂級提交。 長時間運行動作如加載數據或索引建立不等待直到最后提交信息。 所有的兩階段提交的行動需要提交等待，包括準備和提交。 ### 25.2.7.1\. 基礎配置 一旦流復制已配置，配置同步復制僅需要一個額外的配置步驟： [synchronous_standby_names](#calibre_link-1434)必須設置為 一個非空值。`synchronous_commit`也必須設置為`on`， 但因為這是默認值，通常是沒有改變的。 （參見[Section 18.5.1](#calibre_link-1413)和 [Section 18.6.2](#calibre_link-1417)）。 這種配置將導致每次提交會等待確認備庫書面提交記錄到持久存儲。 `synchronous_commit`可以由個人用戶設置， 所以它可以被配置在配置文件中，特別是 用戶或數據庫中，或動態的應用程序中， 以保證每個事務的基礎上控制耐久性。 一個提交記錄已被寫入到主庫磁盤上，WAL記錄隨后被發送到待機狀態。 每次一批新的WAL數據被寫入磁盤時待機發送答復消息， 除非`wal_receiver_status_interval`在待機狀態設置為零。 如果待機是第一個匹配的待機， 在主庫上指定`synchronous_standby_names`， 從待機狀態得到的答復信息將被用于喚醒用戶的提交記錄已被接收的等待確認。 這些參數允許管理員指定哪些備用服務器應同步備用。 注意，同步的配置復制主要針對主服務器。 命名的備用服務器必須直接連接到主庫上;主庫并不了解下游待機使用級聯復制的服務器。 設置`synchronous_commit`到`remote_write`將 導致每個提交等待確認備庫已經收到提交記錄并且寫入到自己的操作系統， 但不是為了該數據被刷新到磁盤上的備份。 這個設置提供了耐用性較弱保證對比`on`： 在待機狀態下可能會失去操作系統崩潰時的數據， 雖然不是PostgreSQL崩潰。 然而，這是在實踐中有用的設置，因為它可以減少事務響應時間。 如果主庫和備庫崩潰，并且主庫的數據庫同時被破壞了，只能發生數據丟失。 如果要求快速關機，用戶將停止等待。然而，作為使用異步復制的時候，服務器將不完全 關閉直到所有WAL記錄轉移到目前連接的備用服務器。 ### 25.2.7.2\. 規劃性能 同步復制通常需要仔細規劃并且放置備用服務器，確保應用程序執行性能。等待 沒有充分利用系統資源，但事務鎖繼續直到確認轉移。作為一個結果， 不小心的使用同步復制會降低數據庫應用性能，由于響應時間的增加和更高的競爭。 PostgreSQL允許應用程序開發人員通過復制來指定所需的耐久性水平。這可以 對系統的總體說明，雖然它也可以被指定為特定用戶或連接，甚至個別交易。 例如，一個應用程序的任務可能包括：10%的變化是重要的客戶資料，而 90%的變化是不太重要的數據，如果它丟失，企業還可以更好生存，比如用戶之間的聊天信息。 在應用水平（主庫）指定同步復制選項，我們可以為大多數重要的變化提供同步復制 ，沒有放緩總工作量體積。對于允許同步復制的高性能應用的效益來說， 應用程序級別的選項是一個重要而實用的工具。 你應該考慮到網絡帶寬必須大于WAL數據生成率。 ### 25.2.7.3\. 高可用性規劃 當`synchronous_commit`設置為`on` 或者`remote_write`將等待直到同步備用響應，則進行提交。 如果最后，或只發生待機崩潰，則響應不會發生。 為避免數據丟失最好的辦法是確保你不會失去你最后的同步備份。 這可以通過使用`synchronous_standby_names`命名多個 潛在的同步備用實現。 第一個命名的備庫將作為同步備庫使用。如果第一個失敗， 則備用列表將接管同步備用角色。 當一個備庫首先依附在主庫時，不能正確地同步。 這是`catchup`方式所描述的。 一旦備庫和主庫之間的滯后達到零，第一次我們將實時狀態`流`。 備庫被創建后，持續追趕時間可能長。如果備庫關閉， 然后追趕時期將隨著待機時間長度而增加。 一旦已經達到`流`狀態，備庫是唯一能夠成為同步備用。 如果主庫啟動而提交等待確認，這些等待事務將被標記為完全提交，一旦主數據庫恢復。 沒有辦法確保在主庫崩潰的時候所有備庫收到所有優秀的WAL數據。 一些事務可能不會在待機時顯示提交，即使他們表現為主庫已提交。 我們提供的保障是應用程序將不會接收事務成功提交的明確承認， 直到被備庫安全接收WAL數據是已知的。 如果你真的失去了你最后的備用服務器，你應該禁用 `synchronous_standby_names`并且在主服務器 重新加載配置文件。 如果主庫是從剩余備用服務器分離的， 你應該故障轉移到那些其他剩余備用服務器的最佳人選。 如果你需要重新創建備用服務器，當等待事務時，確保pg_start_backup()和 pg_stop_backup()在帶有`synchronous_commit` = `off`的回話中運行， 否則這些請求將永遠等待備庫出現。