# 25.5\. 熱備 熱備術語是用來形容連接到服務器，并運行只讀查詢的能力，而服務器在歸檔恢復或備模式。 對復制目的和非常精確的備份恢復到所需的狀態，這是非常有用的。 長期的熱備，也指從恢復到正常運行的服務器的能力， 而用戶繼續運行的查詢和/或保持連接開放。 在熱備用模式運行查詢與正常的查詢操作類似，雖然有幾個使用和管理的差異解釋如下。 ## 25.5.1\. 用戶概述 當備用服務器上[hot_standby](#calibre_link-1134)參數的設置為真時，將開始接受連接， 一旦恢復帶來的系統到一致的狀態。所有這些連接都嚴格只讀的， 甚至可能沒有可寫的臨時表。 數據從主服務器到備服務器上需要一些時間，所以會有一個主備數據庫間的可測量的延遲。 因此，在主備服務器上幾乎同時運行同樣的查詢返回不同的結果。 我們說在備服務器上的數據最終與主服務器上的_一致_。 一旦事務提交記錄在備服務器是上回放， 由事務產生的變化對于在備服務器上的任何新快照來說是可見的。 快照可能是在每個查詢或事務的開始，取決于當前事務的隔離級別。 請參閱[Section 13.2](#calibre_link-1158)獲取更多的信息。 熱備期間開始的事務可能會發出下面的命令： * 查詢訪問-`SELECT`，`COPY TO` * 游標命令-`DECLARE`，`FETCH`，`CLOSE` * 參數-`SHOW`，`SET`，`RESET` * 事務管理命令 * `BEGIN`, `END`, `ABORT`, `START TRANSACTION` * `SAVEPOINT`, `RELEASE`, `ROLLBACK TO SAVEPOINT` * `EXCEPTION`阻塞其它內部的子事物。 * `LOCK TABLE`僅當明確這些模式之一: `ACCESS SHARE`, `ROW SHARE`或者`ROW EXCLUSIVE`。 * 規劃和資源 - `PREPARE`, `EXECUTE`, `DEALLOCATE`, `DISCARD` * 插件和擴展 - `LOAD` 在熱備期間開始的事務，將從不會分配事務ID，并且不能寫入到系統預寫日志。 因此，以下操作將產生錯誤信息： * 數據操縱語言(DML) - `INSERT`, `UPDATE`, `DELETE`, `COPY FROM`, `TRUNCATE`。 請注意，不允許操作在恢復期間正執行觸發器的結果。 此限制也適用于臨時表，因為不分配一個事務ID，不能讀取或寫入表行， 在一個熱備環境這種情況是不可能的。 * 數據定義語言(DDL) - `CREATE`,`DROP`, `ALTER`, `COMMENT`。 甚至臨時表也適用這個限制，因為執行這些操作將需要更新系統空間表。 * `SELECT ... FOR SHARE | UPDATE`因為行鎖，不能不采取更新底層數據文件。 * 在`SELECT`語句上的規則產生DML命令。 * `LOCK`明確要求一個高于`ROW EXCLUSIVE MODE`的模式。 * `LOCK`簡短的缺省形式，因為它請求`ACCESS EXCLUSIVE MODE`. * 事務管理命令明確設置非只讀狀態： * `BEGIN READ WRITE`, `START TRANSACTION READ WRITE` * `SET TRANSACTION READ WRITE`, `SET SESSION CHARACTERISTICS AS TRANSACTION READ WRITE` * `SET transaction_read_only = off` * 兩階段提交命令 - `PREPARE TRANSACTION`, `COMMIT PREPARED`, `ROLLBACK PREPARED` 因為即使只讀事務需要在準備階段寫WAL。（兩種階段提交的第一個階段）。 * 序列更新 - `nextval()`, `setval()` * `LISTEN`, `UNLISTEN`, `NOTIFY` 在正常的操作，允許"只讀"事務更新序列，使用`LISTEN`, `UNLISTEN`和`NOTIFY`， 所以熱備會話下操作會比通常的只讀會話限制稍微更嚴格。 在將來的版本中這些限制中的一些可能會放寬。 熱備間，`transaction_read_only`這個參數總為真，可能不會變。 但只要沒有試圖修改數據庫，在熱備的連接，將行動就像任何其它的數據庫連接。 如果發生失效切換或倒換,數據庫將切換到正常的處理模式。 當服務器改變模式， 會話將保持連接。一旦熱備完成，有可能初始化讀寫事務（即使從熱備間的會話）。 通過發出的`SHOW transaction_read_only`將告訴用戶他們的會話是否只讀的。 另外，一組函數允許用戶訪問關于備服務器的信息（請參閱[Table 9-61](#calibre_link-1049)） 這些允許你寫程序獲知數據庫的當前狀態。這些可以用來監視恢復進程， 或允許你寫復雜的程序來恢復數據庫到特定狀態。 ## 25.5.2\. 處理查詢沖突 主備服務器是許多方式松散連接的。在主服務器上的活動將在備服務器上生效。 作為一個結果，它們之間有潛在的負面交互或沖突.最容易理解的沖突是性能： 如果在主服務器上發生大數據量加載，然后將在備服務器上產生類似的WAL記錄流， 所以備服務器查詢可能競爭系統資源，像I/O。 在熱備也可能發生額外的類型沖突。在該場景下，這些沖突是_硬沖突_。 可能需要取消查詢，在某些情況下，為了解決它們，斷開連接。 給用戶提供幾種解決這些沖突的方法。沖突情況包括： * 在主服務器上采取訪問排斥鎖，包括明確的`LOCK`命令和多種DDL操作，在備服務器查詢訪問表沖突。 * 在主服務器上刪除表空間與備服務器查詢使用該空間的臨時工作文件沖突。 * 在主服務器上刪除一個數據庫與在備服務器上連接到那個數據庫的會話沖突。 * 一個從WAL清空記錄的應用程序vacuum與在備服務器上事務，其快照仍然可以"看到"已刪除的行。 * 一個從WAL清空記錄的應用程序vacuum與在備服務器上查詢訪問該目標頁，不管要刪除的數據是否可見。 在主服務器上，這些情況簡單等待結果，用戶可能選擇取消任何沖突的操作。 盡管，在備服務器上沒有選擇： 在主服務器上已經發生的WAL日志， 所以備服務器應用它一定不會失敗。此外，允許WAL應用無限期等待可能是很不明智的。 因為備服務器的狀態將變為增量遠落后主服務器的。因此，提供一個機制， 強行取消備服務器上與將要應用WAL記錄沖突的查詢。 一個該問題情況的例子是管理員在主服務器上運行`DROP TABLE`一張表，而備服務器當前正查詢這張表。 如果在備服務器上執行了`DROP TABLE`，明確的備服務器查詢不能繼續。 如果這個問題情況發生在主服務器。則`DROP TABLE`將等到其它查詢完成。 但是當`DROP TABLE`運行在主服務器時，主服務器不會有關于備服務器查詢的信息， 因此，將不等待任何備服務器查詢。當備服務器查詢在運行時，WAL改變的記錄來到備服務器， 導致一個沖突。備服務器要么延遲應用WAL記錄（任何事情也都要在它們之后）， 不然取消沖突的查詢，由此可以應用`DROP TABLE`。 當一個沖突查詢短的，通常想要允許它完成而延遲WAL應用程序一點點。 但是長時間的延遲WAL應用程序通常不是想要的。 所以取消機制有參數[max_standby_archive_delay](#calibre_link-1686)和[max_standby_streaming_delay](#calibre_link-1687)， 這定義在WAL應用程序中允許延遲最大值。一旦查詢沖突比應用任何新收取的WAL數據設定有關延遲長， 則取消查詢沖突。 有兩個參數，因此有兩個不同延遲，為從歸檔讀取WAL數據 （即從一個基準備份初始化恢復或"趕上"已經遠落后的備服務器） 和通過流復制讀取WAL數據的指定延遲。 在備服務器存在高可用性的主服務器，最好設置延遲參數相對短， 因此不會由備服務器查詢所導致延遲使遠落后主服務器。 不過，如果備服務器意思為執行長時間的查詢，那么一個高的或無期限的延遲值是可取的。 請記著如果延遲WAL記錄應用程序，則長時間查詢將導致 備服務器上的其它會話不能看到最新的變化。 一旦超過了由`max_standby_archive_delay`或者 `max_standby_streaming_delay`指定的延遲， 將取消查詢沖突。 這通常結果是一個取消錯誤，雖然在回放`DROP DATABASE`整個數據庫的情況下， 將終止沖突會話。此外，如果沖突由空閑事務保持，終止沖突會話。 （這個行為可能在將來版本改變）。 可能立即重試已取消的查詢（在開始一個新事務之后，當然）。 自查詢取消依賴于WAL記錄重播的本質，如果再次執行，已經取消的查詢可能很成功。 請記住這些參數與從備服務器接收WAL數據開始所經過的時間比較。 允許備服務器上任何查詢的寬期限，從不超過該延遲參數， 并且如果備服務器存在落后主服務器，那么期限的可能相當小。 如等待之前查詢執行完成的結果，或不能跟上有大量的更新負載的結果。 備用的查詢和WAL重放之間的沖突最常見的原因是"過早清除"。 通常，PostgreSQL允許清理老行版本，當沒有事務需要根據MVCC的規則 看到他們保證數據的正確性。 然而，這條規則只適用于在主庫上事務執行情況。 所以在主庫上清理刪除主庫上事務仍然可見的行版本，這是可能的。 有經驗的用戶應注意行版本的清理和行版本冷凍將與備用查詢沖突。手動運行 `VACUUM FREEZE`可能引起甚至沒有更新或刪除行的表上的沖突。 用戶應該清楚那些表， 在主服務器上定期和大量更新表將會很快導致取消備服務器上長時間運行的查詢。 在這類情況下，對`max_standby_archive_delay`或者 `max_standby_streaming_delay`設置一個有限值, 類似于設置`statement_timeout`。 如果發現不能接受某些取消備服務器查詢，補救存在的可能性。 第一個選項是設置參數`hot_standby_feedback`， 阻止`VACUUM`刪除最近的死行， 所以清理沖突不會發生。如果你這樣做，你應該知道這將延遲主服務器清理死行，其可能不想要的表膨脹結果。 不過這種情況清理不遜于如果備服務器查詢直接運行在主服務器上， 并且你仍然得到卸載執行在備服務器上的好處。 在這種情況下`max_standby_archive_delay`必須是保持大的， 因為延遲WAL文件可能已經包含了備服務器查詢想要的記錄項。 另一個選項是在主服務器上增加[vacuum_defer_cleanup_age](#calibre_link-1688)， 從而將不會像通常很快的清理掉死行。 這將允許在備服務器上取消它們前，更多時間給執行查詢， 無需設置一個高的`max_standby_streaming_delay`。 雖然用這種方法保證窗口的執行時間是有困難的， 因為`vacuum_defer_cleanup_age`在主服務器執行的事務中是可測的。 查詢數取消，原因可以看作在備用服務器上使用`pg_stat_database_conflicts`系統視圖。 `pg_stat_database`系統視圖也包含摘要信息。 ## 25.5.3\. 管理員概述 如果在`postgresql.conf`中`啟用`了`hot_standby`， 并且目前有個`recovery.conf`文件， 該服務器將運行在熱備模式。不過可能花些時間為允許的熱備連接， 因為該服務器不接受連接直到完成足夠的恢復能提供一致的狀態，其查詢能運行。 在這個期間，將帶有一個錯誤信息拒絕客戶端嘗試連接。為確認該服務器起來了， 要么循環嘗試從應用程序連接，或者在服務器日志里查看這些錯誤信息： ``` LOG: entering standby mode ... then some time later ... LOG: consistent recovery state reached LOG: database system is ready to accept read only connections ``` 在主服務器上每個檢查點一致的信息記錄一次。 在主服務器上沒有將`wal_level`設置為`hot_standby`時，當讀取正在寫的WAL時， 啟用熱備是不可能的。存在這些條件的兩者也可能延遲達到一致性狀態： * 一個寫事務有多于64個子事務 * 很長時間活動的寫事務 如果你正運行基于文件日志傳送（“暖備”）， 你可能需要等到下一個WAL文件到來，其盡可能長如在主服務器設置`archive_timeout`。 有些參數的設置在備服務器將需要重新配置，如果在主服務器改變了它們。 對于這些參數，備服務器上的值要大于或等于主服務器上的。 如果這些參數沒有設置足夠高，那么備服務器將拒絕啟動。 提供了更高的值，重啟該服務器再開始恢復。這些參數是： * `max_connections` * `max_prepared_transactions` * `max_locks_per_transaction` 管理員選擇合適的設置為[max_standby_archive_delay](#calibre_link-1686)和 [max_standby_streaming_delay](#calibre_link-1687)是很重要的。 根據業務的優先級，最好的選擇有所不同。例如：如果服務器是主要任務， 作為高可用性的服務器，那么你想低延遲設置，也許設置為0，盡管這也是很積極的設置。 如果備服務器的任務作為決策支持的額外服務器，那么可能接受設置最大延遲為幾個小時， 或甚至-1意味著永遠等待查詢完成。 在主服務器上寫的事務狀態"提示位"沒有記錄WAL日志，所以在備服務器上將或許再次重寫該提示。 因此，備服務器將仍然進行寫磁盤即使所有用戶是只讀的，數據值自身沒有發生改變。 用戶將仍然寫大量排序的臨時文件和 重新生成緩存的信息文件， 所以在熱備模式數據庫沒有部分是真只讀的。還要注意寫到遠程數據庫使用dblink模塊， 外部數據的操作使用PL函數仍然是可能的，盡管事務是本地只讀的。 在恢復模式里，不接受下面類型的管理命令： * 數據定義語言(DDL) - e.g. `CREATE INDEX` * 權限和所有權 - `GRANT`, `REVOKE`,`REASSIGN` * 維護命令 - `ANALYZE`, `VACUUM`,`CLUSTER`, `REINDEX` 再次，請注意在主服務器的“只讀”模式事務中，允許這里的某些命令。 作為一個總結，你不能創建額外的索引，統計也不能僅在備服務器， 如果需要這些管理命令，應該在主服務器執行，并且最終這些變化將傳播到備服務器。 `pg_cancel_backend()`和`pg_terminate_backend()` 將在用戶后臺工作，但是不啟動進程，其執行恢復。 `pg_stat_activity`將不顯示為一個啟動進程項，也不顯示做恢復事務的活動。 作為一個總結，`pg_prepared_xacts`在恢復中總是空。 如果你愿解決有疑問準備的事務， 在主服務器上查看`pg_prepared_xacts`和發出命令來解決這里的事務。 `pg_locks`將顯示由后臺持有的鎖。 `pg_locks`也顯示由啟動進程所管理的虛擬事務， 其擁有由恢復正回放的事務所持有的`AccessExclusiveLocks`。 請注意該啟動進程不需要鎖定數據庫變化，并且非`AccessExclusiveLocks`鎖， 不會顯示在啟動進程的`pg_locks`里。它們只是推測存在。 Nagios插件check_pgsql將工作，因為用它檢測存在的簡單信息。 check_postgres監控腳本也將工作， 盡管有些報告值能給不同或迷惑的結果。 例如：上次清理時間將不會保持， 因為在備服務器沒有清理發生。 運行在主服務器的清理，將仍然發送它們的改變到備服務器。 在恢復期間WAL文件控制命令將不工作，比如`pg_start_backup`, `pg_switch_xlog`等。 動態加載模塊工作，包括`pg_stat_statements`。 在恢復中咨詢鎖將工作正常，包括死鎖保護。 請注意咨詢鎖從不寫WAL日志，所以對于一個咨詢鎖在主服務器上或回放WAL在備服務器上沖突不可能的。 在主服務器上需要一個咨詢鎖，在備服務器上已經初始化了一個類似咨詢鎖也是不可能的。 咨詢鎖只是與需要它們的服務器相關。 基于觸發器的復制系統像Slony, Londiste和Bucardo將不在備服務器運行， 盡管在主服務器運行的很好，但變化不會發送到備服務器應用。WAL回放不是基于觸發器的， 所以你不能從備服務器中傳送到任何系統，其需要額外的寫或依賴使用觸發器。 不能分配新OID，盡管某些UUID生成器可能仍然工作，只要不依靠它們寫新狀態到數據庫。 當前，在只讀事務中不允許創建臨時表，所以在某些情況下存在的腳本將運行不正確。 這個限制可能在以后的版本中放寬。這是一個SQL標準的兼容性和技術問題。 如果表空間是空，`DROP TABLESPACE`只能成功。 有些備服務器用戶可積極的通過`temp_tablespaces`參數使用 該表空間。如果在表空間有臨時文件，取消所有活動的查詢來確保刪除臨時文件，所以可以刪除表空間， 可以繼續WAL回放。 在主服務器上運行`DROP DATABASE`或者`ALTER DATABASE ... SET TABLESPACE`將產生一個WAL項， 其將導致已連接到在備服務器上的那個數據庫的所有用戶，強制斷開連接。 這個動作立即發生， 不管`max_standby_streaming_delay`的設置。請注意`ALTER DATABASE ... RENAME`不會斷開連接的用戶， 在多數情況下忽視，不過如果某些方式依賴數據庫名，可能在某些情況下導致一個程序混亂。 在正常（非恢復）模式，如果你發出`DROP USER`或者`DROP ROLE`對于一個有登錄權限的角色， 當那個用戶仍然已經連接，那么不會發生什么對于已連接的用戶-他們保持連接。 不過該用戶不能再連接。這個行為在恢復中也適用，所以在主服務器上`DROP USER`不能斷開備服務器上該用戶連接。 在恢復中統計采集器是活動的。所有掃描，讀取，塊，索引使用等，將在備服務器中記錄。 回放活動將不復制在主服務器上的影響，因此回放插入將不增加插入pg_stat_user_tables列。 恢復開始刪除該統計文件， 所以主備服務器的統計將不同，認為這是個特性，而不是一個臭蟲。 在恢復中自動清理是不活躍的。在恢復結束將正常啟動。 在恢復中后臺記錄器是活動的，將執行重啟點（類似于主服務器上的檢查點）和正常塊清理活動。 這可能包含存儲在備服務器上的提示信息更新。 在恢復中接受`CHECKPOINT`命令，盡管執行一個重啟點而不是一個新檢查點。 ## 25.5.4\. 熱備參數參考 各種參數已經在[Section 25.5.2](#calibre_link-1441)和 [Section 25.5.3](#calibre_link-1651)上面提到。 在主服務器上，可以使用參數[wal_level](#calibre_link-1039)和 [vacuum_defer_cleanup_age](#calibre_link-1688)。如果在主服務器上設置， [max_standby_archive_delay](#calibre_link-1686)和 [max_standby_streaming_delay](#calibre_link-1687)沒有影響。 在備服務器,可以使用參數[hot_standby](#calibre_link-1134), [max_standby_archive_delay](#calibre_link-1686)和 [max_standby_streaming_delay](#calibre_link-1687)。 只要服務器保留在備模式，[vacuum_defer_cleanup_age](#calibre_link-1688)沒有影響， 盡管變為相關的，如果備服務器成為主服務器。 ## 25.5.5\. Caveats 有幾個熱備限制。這些可能在將來的版本中解決： * 在哈希索引的操作，不會記錄在目前的WAL日志，索引回放將不更新這些索引。 * 在做快照之前充分認識運行的事務是必需的。 事務使用大量的子事務（當前大于64）將延遲只讀連接的開始直到運行最長寫事務完成。 如果這種情況發生，說明信息將發送到服務器的日志。 * 對于備服務器查詢的有效開始點是產生在主服務器上的每個檢查點。 如果備服務器關機，當主服務器在關機狀態， 不可能重進熱備直到啟動主服務器， 所以在WAL日志里產生進一步的開始點。在最常見的情況下這種情況不是一個問題， 它可能發生。一般地，如果主服務器關機，不再可用，那可能由于一個嚴重的失敗， 需要將備服務器轉化為新主服務器運行。 并且有特意取下主服務器的情況， 協調確保備服務器成為平滑的主服務器，也是標準的處理。 * 在恢復結束，由準備的事務持有的`AccessExclusiveLocks`需要鎖表正常數量的條目的兩倍。 如果你計劃運行大量并發的準備事務，正常地用`AccessExclusiveLocks`或你計劃一個 大事務用多個`AccessExclusiveLocks`， 建議你選擇一個大的`max_locks_per_transaction`值, 可能為在主服務器上兩倍這個參數值。如果你設置`max_prepared_transactions`為0， 根本不需要考慮這個。 * 串行化事務隔離級別在熱備份中仍然不可用（參閱[Section 13.2.3](#calibre_link-727) and [Section 13.4.1](#calibre_link-1166)獲取更多信息）。 在熱備份模式中嘗試設置事務為串行化隔離級別將產生一個錯誤。