PostgreSQL 熱備

當(dāng)hot_standby參數(shù)在一臺(tái)后備服務(wù)器上被設(shè)置為真時(shí)，一旦恢復(fù)將系統(tǒng)帶到一個(gè)一致的狀態(tài)它將開始接受連接。所有這些連接都被限制為只讀，甚至臨時(shí)表都不能被寫入。

后備服務(wù)器上的數(shù)據(jù)需要一些時(shí)間從主服務(wù)器到達(dá)后備服務(wù)器，因此在主服務(wù)器和后備服務(wù)器之間將有一段可以度量的延遲。近乎同時(shí)在主服務(wù)器和后備服務(wù)器上運(yùn)行相同的查詢可能因此而返回不同的結(jié)果。我們說后備服務(wù)器上的數(shù)據(jù)與主服務(wù)器是最終一致的。一旦一個(gè)事務(wù)的提交記錄在后備服務(wù)器上被重播，那個(gè)事務(wù)所作的修改將對(duì)后備服務(wù)器上所有新取得的快照可見?？煺湛梢栽诿總€(gè)查詢或每個(gè)事務(wù)的開始時(shí)取得，這取決于當(dāng)前的事務(wù)隔離級(jí)別。詳見第 13.2 節(jié)。

在熱備期間開始的事務(wù)可能發(fā)出下列命令：

在熱備期間開始的事務(wù)將不會(huì)被分配一個(gè)事務(wù) ID 并且不能被寫入到系統(tǒng)的預(yù)寫式日志。因此，下列動(dòng)作將產(chǎn)生錯(cuò)誤消息：

在正常操作中，“只讀”事務(wù)被允許使用LISTEN和NOTIFY，因此熱備會(huì)話在比普通只讀會(huì)話更緊一點(diǎn)的限制下操作。這些限制中的某些可能會(huì)在一個(gè)未來的發(fā)行中被放松。

在熱備期間，參數(shù)transaction_read_only總是為真并且不可以被改變。但是只要不嘗試修改數(shù)據(jù)庫，熱備期間的連接工作起來更像其他數(shù)據(jù)庫連接。如果發(fā)生故障轉(zhuǎn)移或切換，該數(shù)據(jù)庫將切換到正常處理模式。當(dāng)服務(wù)器改變模式時(shí)會(huì)話將保持連接。一旦熱備結(jié)束，它將可以發(fā)起讀寫事務(wù)（即使是一個(gè)在熱備期間啟動(dòng)的會(huì)話）。

用戶將可以通過發(fā)出SHOW transaction_read_only來了解他們的會(huì)話是不是只讀的。此外，一組函數(shù)（表 9.86）允許用戶訪問關(guān)于后備服務(wù)器的信息。這些允許你編寫關(guān)心數(shù)據(jù)庫當(dāng)前狀態(tài)的程序。這些可以被用來監(jiān)控恢復(fù)的進(jìn)度，或者允許你編寫恢復(fù)數(shù)據(jù)庫到特定狀態(tài)的復(fù)雜程序。

主服務(wù)器和后備服務(wù)器在多方面都松散地連接在一起。主服務(wù)器上的動(dòng)作將在后備服務(wù)器上產(chǎn)生效果。結(jié)果是在它們之間有潛在的負(fù)作用或沖突。最容易理解的沖突是性能：如果在主服務(wù)器上發(fā)生一次大數(shù)據(jù)量的載入，那么著將在后備服務(wù)器上產(chǎn)生一個(gè)相似的 WAL 記錄流，因而后備服務(wù)器查詢可能要競爭系統(tǒng)資源（例如 I/O）。

隨著熱備發(fā)生的還可能有其他類型的沖突。對(duì)于可能需要被取消的查詢和（某些情況中）解決它們的已斷開會(huì)話來說，這些沖突是硬沖突。用戶可以用幾種方式來處理這種沖突。沖突情況包括：

在主服務(wù)器上，這些情況僅僅會(huì)導(dǎo)致等待；并且用戶可以選擇取消這些沖突動(dòng)作中間的一個(gè)。但是，在后備服務(wù)器上則沒有選擇：已被 WAL 記錄的動(dòng)作已經(jīng)在主服務(wù)器上發(fā)生，那么后備服務(wù)器不能在應(yīng)用它時(shí)失敗。此外，允許 WAL 應(yīng)用無限等待是非常不可取的，因?yàn)楹髠浞?wù)器的狀態(tài)將變得逐漸遠(yuǎn)遠(yuǎn)落后于主服務(wù)器的狀態(tài)。因此，提供了一種機(jī)制來強(qiáng)制性地取消與要被應(yīng)用的 WAL 記錄沖突的后備查詢。

該問題情形的一個(gè)例子是主服務(wù)器上的一位管理員在一個(gè)表上運(yùn)行DROP TABLE，而該表正在后備服務(wù)器上被查詢。如果DROP TABLE被應(yīng)用在后備服務(wù)器上，很明顯該后備查詢不能繼續(xù)。如果這種情況在主服務(wù)器上發(fā)生，DROP TABLE將等待直到其他查詢結(jié)束。但是當(dāng)DROP TABLE被運(yùn)行在主服務(wù)器上，主服務(wù)器沒有關(guān)于運(yùn)行在后備服務(wù)器上查詢的信息，因此它將不會(huì)等待任何這樣的后備查詢。WAL 改變記錄在后備查詢還在運(yùn)行時(shí)來到后備服務(wù)器上，導(dǎo)致一個(gè)沖突。后備服務(wù)器必須要么延遲 WAL 記錄的應(yīng)用（還有它們之后的任何事情），要么取消沖突查詢這樣DROP TABLE可以被應(yīng)用。

當(dāng)一個(gè)沖突查詢很短時(shí)，我們通常期望能延遲 WAL 應(yīng)用一小會(huì)兒讓它完成；但是在 WAL 應(yīng)用中的一段長的延遲通常是不受歡迎的。因此取消機(jī)制有參數(shù)，max_standby_archive_delay和max_standby_streaming_delay，它們定義了在 WAL 應(yīng)用中的最大允許延遲。當(dāng)應(yīng)用任何新收到的 WAL 數(shù)據(jù)花費(fèi)了超過相關(guān)延遲設(shè)置值時(shí)，沖突查詢將被取消。設(shè)立兩個(gè)參數(shù)是為了對(duì)從一個(gè)歸檔讀取 WAL 數(shù)據(jù)（即來自一個(gè)基礎(chǔ)備份的初始恢復(fù)或者“追趕”一個(gè)已經(jīng)落后很遠(yuǎn)的后備服務(wù)器）和通過流復(fù)制讀取 WAL數(shù)據(jù)的兩種情況指定不同的延遲值。

在一臺(tái)后備服務(wù)器上這主要是為了該可用性而存在，最好把延遲參數(shù)設(shè)置得比較短，這樣服務(wù)器不會(huì)由于后備查詢導(dǎo)致的延遲落后主服務(wù)器太遠(yuǎn)。但是，如果該后備服務(wù)器是位了執(zhí)行長時(shí)間運(yùn)行的查詢，則一個(gè)較高甚至無限的延遲值更好。但是記住一個(gè)長時(shí)間運(yùn)行的查詢延遲了 WAL 記錄的應(yīng)用，它可能導(dǎo)致后備服務(wù)器上的其他會(huì)話無法看到主服務(wù)器上最近的改變。

一旦max_standby_archive_delay或max_standby_streaming_delay指定的延遲被超越，沖突查詢將被取消。這通常僅導(dǎo)致一個(gè)取消錯(cuò)誤，盡管在重放一個(gè)DROP DATABASE的情況下整個(gè)沖突會(huì)話都將被中斷。另外，如果沖突發(fā)生在一個(gè)被空閑事務(wù)持有的鎖上，該沖突會(huì)話會(huì)被中斷（這種行為可能在未來被改變）。

被取消的查詢可能會(huì)立即被重試（當(dāng)然是在開始一個(gè)新的事務(wù)后）。因?yàn)椴樵內(nèi)∠蕾囉?WAL 記錄被重放的本質(zhì)，如果一個(gè)被取消的查詢被再次執(zhí)行，它可能會(huì)很好地成功完成。

記住延遲參數(shù)是從 WAL 數(shù)據(jù)被后備服務(wù)器收到后流逝的時(shí)間。因此，留給后備服務(wù)器上任何一個(gè)查詢的寬限期從不會(huì)超過延遲參數(shù)，并且如果后備服務(wù)器已經(jīng)由于等待之前的查詢完成而落后或者因?yàn)檫^重的更新負(fù)載而無法跟上主服務(wù)器，寬限期可能會(huì)更少。

在后備查詢和 WAL 重播之間發(fā)生沖突的最常見原因是“過早清除”。正常地，PostgreSQL允許在沒有事務(wù)需要看到舊行版本時(shí)對(duì)它們進(jìn)行清除，這樣可以保證根據(jù) MVCC 規(guī)則的正確的數(shù)據(jù)可見性。不過，這個(gè)規(guī)則只能被應(yīng)用于執(zhí)行在主控機(jī)上的事務(wù)。因此有可能主控機(jī)上的清除會(huì)移除對(duì)一個(gè)后備服務(wù)器事務(wù)還可見的行版本。

有經(jīng)驗(yàn)的用戶應(yīng)當(dāng)注意行版本清除和行版本凍結(jié)都可能與后備查詢沖突。即便在一個(gè)沒有被更新或被刪除行的表上運(yùn)行一次手工VACUUM FREEZE也可能導(dǎo)致沖突。

用戶應(yīng)當(dāng)清楚，主服務(wù)器上被正常和重度更新的表將快速地導(dǎo)致后備服務(wù)器上長時(shí)間運(yùn)行的查詢被取消。在這樣的情況下，max_standby_archive_delay或max_standby_streaming_delay的有限制設(shè)置可以被視作statement_timeout設(shè)置。

如果發(fā)現(xiàn)后備查詢?nèi)∠臄?shù)量不可接受，還是有補(bǔ)救的可能。第一種選項(xiàng)是設(shè)置參數(shù) hot_standby_feedback，它阻止VACUUM 移除最近死亡的元組并且因此清除沖突不會(huì)產(chǎn)生。如果你這樣做，你應(yīng)當(dāng) 注意這將使主服務(wù)器上的死亡元組清除被延遲，這可能會(huì)導(dǎo)致不希望發(fā)生 的表膨脹。不過，清除的情況不會(huì)比在主服務(wù)器上直接運(yùn)行后備查詢時(shí)更糟， 并且你仍然能夠享受將執(zhí)行分流到后備服務(wù)器的好處。如果后備服務(wù)器頻繁地連接和 斷開，你可能想要做些調(diào)整來處理無法提供hot_standby_feedback 反饋的時(shí)期。例如，考慮增加max_standby_archive_delay，這樣 在斷開連接的期間查詢就不會(huì)快速地被 WAL 歸檔文件中的沖突取消。你也應(yīng)該考慮 增加max_standby_streaming_delay來避免重新連接后新到達(dá)的流 WAL 項(xiàng)導(dǎo)致的快速取消。

另一個(gè)選項(xiàng)是增加主服務(wù)器上的vacuum_defer_cleanup_age，這樣死亡行不會(huì)像平常那么快地被清理。這將允許在后備服務(wù)器上的查詢能在被取消前有更多時(shí)間執(zhí)行，并且不需要設(shè)置一個(gè)很高的max_standby_streaming_delay。但是，這種方法很難保證任何指定的執(zhí)行時(shí)間窗口，因?yàn)? vacuum_defer_cleanup_age是用主服務(wù)器上被執(zhí)行的事務(wù)數(shù)來衡量的。

查詢?nèi)∠臄?shù)量和原因可以使用后備服務(wù)器上的pg_stat_database_conflicts系統(tǒng)視圖查看。pg_stat_database系統(tǒng)視圖也包含匯總信息。

如果hot_standby在postgresql.conf中被設(shè)置為on并且存在一個(gè)standby.signal文件，服務(wù)器將運(yùn)行在熱備模式。但是，可能需要一些時(shí)間來允許熱備連接，因?yàn)樵诜?wù)器完成足夠的恢復(fù)來為查詢提供一個(gè)一致的狀態(tài)之前，它將不會(huì)接受連接。在此期間，嘗試連接的客戶端將被一個(gè)錯(cuò)誤消息拒絕。要確認(rèn)服務(wù)器已經(jīng)可連接，要么循環(huán)地從應(yīng)用嘗試連接，要么在服務(wù)器日志中查找這些消息：

LOG: entering standby mode ... then some time later ... LOG: consistent recovery state reached LOG: database system is ready to accept read only connections

在主服務(wù)器上，一旦創(chuàng)建一個(gè)檢查點(diǎn)，一致性信息就被記錄下來。當(dāng)讀取在特定時(shí)段（當(dāng)在主服務(wù)器上wal_level沒有被設(shè)置為replica或者logical的期間）產(chǎn)生的 WAL 時(shí)無法啟用熱備。在同時(shí)存在這些條件時(shí)，到達(dá)一個(gè)一致狀態(tài)也會(huì)被延遲：

如果你正在運(yùn)行基于文件的日志傳送（“溫備”），你可能需要等到下一個(gè) WAL 文件到達(dá)，這可能和主服務(wù)器上的archive_timeout設(shè)置一樣長。

如果后備服務(wù)器上某些參數(shù)在主服務(wù)器上已經(jīng)被改變，它們的設(shè)置將需要重新配置。對(duì)這些參數(shù)，在后備服務(wù)器上的值必須等于或者大于主服務(wù)器上的值。因此，如果想要增加這些值，就應(yīng)該在把這些更改應(yīng)用到主服務(wù)器之前，先在所有的后備服務(wù)器上做同樣的事情。反過來，如果想要減小這些值，就應(yīng)該在把這些更改應(yīng)用到所有后備服務(wù)器之前，先在主服務(wù)器上做同樣的事情。如果這些參數(shù)沒有被設(shè)置得足夠高，后備服務(wù)器將拒絕開始。較高的值被提供之后，服務(wù)器重新啟動(dòng)再次開始恢復(fù)。這些參數(shù)是：

管理員為max_standby_archive_delay和max_standby_streaming_delay選擇適當(dāng)?shù)脑O(shè)置很重要。最好的選擇取決于業(yè)務(wù)的優(yōu)先級(jí)。例如如果服務(wù)器主要的任務(wù)是作為高可用服務(wù)器，那么你將想要低延遲設(shè)置，甚至是零（盡管它是一個(gè)非常激進(jìn)的設(shè)置）。如果后備服務(wù)器的任務(wù)是作為一個(gè)用于決策支持查詢的額外服務(wù)器，那么將其最大延遲值設(shè)置為很多小時(shí)甚至 -1 （表示無限等待）可能都是可以接受的。

在主服務(wù)器上寫出的事務(wù)狀態(tài) "hint bits" 是不被 WAL 記錄的，因此后備服務(wù)器上的數(shù)據(jù)將可能重新寫出該提示。這樣，即使所有用戶都是只讀的，后備服務(wù)器仍將執(zhí)行磁盤寫操作；但數(shù)據(jù)值本身并沒有發(fā)生改變。用戶將仍寫出大的排序臨時(shí)文件并且重新生成 relcache 信息文件，這樣在熱備模式中數(shù)據(jù)庫沒有哪個(gè)部分是真正只讀的。還要注意使用dblink模塊寫到遠(yuǎn)程數(shù)據(jù)庫以及其他使用 PL 函數(shù)位于數(shù)據(jù)庫之外的操作仍將可用，即使該事務(wù)是本地只讀的。

在恢復(fù)模式期間，下列類型的管理命令是不被接受的：

注意這些命令中的某些實(shí)際上在主服務(wù)器上的“只讀”模式事務(wù)期間是被允許的。

結(jié)果是，你無法創(chuàng)建只存在于后備服務(wù)器上的額外索引以及統(tǒng)計(jì)信息。如果需要這些管理命令，它們應(yīng)該在主服務(wù)器上被執(zhí)行，并且最后那些改變將被傳播到后備服務(wù)器。

pg_cancel_backend()和pg_terminate_backend()將在用戶后端上工作，而不是執(zhí)行恢復(fù)的 Startup 進(jìn)程。pg_stat_activity不會(huì)為 Startup 進(jìn)程顯示一個(gè)項(xiàng)，也不會(huì)把恢復(fù)事務(wù)顯示為活動(dòng)。結(jié)果是在恢復(fù)期間pg_prepared_xacts總是為空。如果你希望解決不能確定的預(yù)備事務(wù)，查看主服務(wù)器上的 pg_prepared_xacts并且發(fā)出命令來解決那里的事務(wù)或者在恢復(fù)結(jié)束后來解決它們。

和平常一樣，pg_locks將顯示被后端持有的鎖。pg_locks也會(huì)顯示一個(gè)由 Startup 進(jìn)程管理的虛擬事務(wù)，它擁有被恢復(fù)重播的事務(wù)所持有的所有AccessExclusiveLocks。注意 Startup 進(jìn)程不請(qǐng)求鎖來做數(shù)據(jù)庫更改，并且因此對(duì)于 Startup 進(jìn)程除AccessExclusiveLocks之外的鎖不顯示在 pg_locks中，它們僅被假定存在。

Nagios的插件check_pgsql將可以工作，因?yàn)樗鼨z查的簡單信息是存在的。check_postgres監(jiān)控腳本也將能工作，盡管某些被報(bào)告的值可能給出不同或者混亂的結(jié)果。例如，上一次清理時(shí)間將不會(huì)被維護(hù)，因?yàn)樵诤髠浞?wù)器上不會(huì)發(fā)生清理。在主服務(wù)器上運(yùn)行的清理仍會(huì)把它們的改變發(fā)送給后備服務(wù)器。

WAL 文件控制命令在恢復(fù)期間將不會(huì)工作，如pg_start_backup、pg_switch_wal等。

可動(dòng)態(tài)載入的模塊可以工作，包括pg_stat_statements。

咨詢鎖在恢復(fù)期間工作正常，包括死鎖檢測。注意咨詢鎖從來都不會(huì)被 WAL 記錄，因此在主服務(wù)器或后備服務(wù)器上一個(gè)咨詢鎖不可能會(huì)與 WAL 重播發(fā)生沖突。也不可能會(huì)在主服務(wù)器上獲得一個(gè)咨詢鎖并且在后備服務(wù)器上開始一個(gè)相似的咨詢鎖。咨詢鎖只與它們被取得的那個(gè)服務(wù)器相關(guān)。

基于觸發(fā)器的復(fù)制系統(tǒng)（如Slony、Londiste和Bucardo）將根本不會(huì)運(yùn)行在后備服務(wù)器上，然而只要改變不被發(fā)送到要被應(yīng)用的后備服務(wù)器，它們將在主服務(wù)器上運(yùn)行得很好。WAL 重播不是基于觸發(fā)器的，因此你不能用后備服務(wù)器接替任何需要額外數(shù)據(jù)庫寫操作或依賴觸發(fā)器使用的系統(tǒng)。

新的 OID 不能被分配，然而某些UUID生成器仍然能工作，只要它們不依賴于向數(shù)據(jù)庫寫新的狀態(tài)。

當(dāng)前，在只讀事務(wù)期間不允許創(chuàng)建臨時(shí)表，因此在某些情況中現(xiàn)有的腳本將不會(huì)正確運(yùn)行。這個(gè)限制可能會(huì)在稍后的發(fā)行中被放松。這既是一個(gè) SQL 標(biāo)準(zhǔn)符合問題也是一個(gè)技術(shù)問題。

只有在表空間為空時(shí)DROP TABLESPACE才能成功。某些后備服務(wù)器用戶可能正在通過他們的temp_tablespaces參數(shù)使用該表空間。如果在該表空間中有臨時(shí)文件，所有活動(dòng)查詢將被取消來保證臨時(shí)文件被移除，這樣該表空間可以被移除并且 WAL 重播可以繼續(xù)。

在主服務(wù)器上運(yùn)行DROP DATABASE或ALTER DATABASE ... SET TABLESPACE將產(chǎn)生一個(gè) WAL 項(xiàng)，它將導(dǎo)致所有連接到后備服務(wù)器上那個(gè)數(shù)據(jù)庫的用戶被強(qiáng)制地?cái)嚅_連接。這個(gè)動(dòng)作會(huì)立即發(fā)生，不管max_standby_streaming_delay的設(shè)置是什么。注意ALTER DATABASE ... RENAME不會(huì)斷開用戶，這在大部分情況中不會(huì)有提示，然而如果它依賴某種基于數(shù)據(jù)庫名的方法，在某些情況中會(huì)導(dǎo)致程序混亂。

在普通（非恢復(fù)）模式中，如果你為具有登錄能力的角色發(fā)出DROP USER或DROP ROLE，而該用戶仍然連接著，則對(duì)已連接用戶不會(huì)發(fā)生任何事情 - 他們保持連接。但是用戶不能重新連接。這種行為也適用于恢復(fù)，因此在主服務(wù)器上的一次DROP USER不會(huì)使后備服務(wù)器上的用戶斷開。

在恢復(fù)期間統(tǒng)計(jì)收集器是活動(dòng)的。所有掃描、讀、阻塞、索引使用等將在后備服務(wù)器上被正常的記錄。被重播的動(dòng)作將不會(huì)重復(fù)它們?cè)谥鞣?wù)器上的效果，因此重播一個(gè)插入將不會(huì)導(dǎo)致pg_stat_user_tables的 Inserts 列上的遞增。在恢復(fù)的開始 stats 文件會(huì)被刪除，因此來自主服務(wù)器和后備服務(wù)器的 stats 將不同；這被認(rèn)為是一種特性而不是缺陷。

在恢復(fù)期間自動(dòng)清理不是活動(dòng)的。它將在恢復(fù)末尾正常啟動(dòng)。

檢查點(diǎn)進(jìn)程和后臺(tái)寫入進(jìn)程在恢復(fù)期間是活動(dòng)狀態(tài)的。檢查點(diǎn)進(jìn)程將執(zhí)行重啟動(dòng)點(diǎn)（與主服務(wù)器上的檢查點(diǎn)相似），后臺(tái)寫入進(jìn)程將執(zhí)行正常的塊清理活動(dòng)。 這可以包括存儲(chǔ)在后備服務(wù)器上的提示位信息的更新。在恢復(fù)期間，CHECKPOINT命令會(huì)被接受，然而它會(huì)執(zhí)行一個(gè)重啟點(diǎn)而不是一個(gè)新的檢查點(diǎn)。

多個(gè)參數(shù)已經(jīng)在第 26.5.2 節(jié)和第 26.5.3 節(jié)中提到過。

在主服務(wù)器上，可以使用參數(shù)wal_level和vacuum_defer_cleanup_age。在主服務(wù)器上設(shè)置max_standby_archive_delay和 max_standby_streaming_delay不會(huì)產(chǎn)生效果。

在主服務(wù)器上，可以使用參數(shù)hot_standby、max_standby_archive_delay和max_standby_streaming_delay。只要服務(wù)器保持在后備模式 vacuum_defer_cleanup_age就沒有效果，然而當(dāng)后備服務(wù)器變成主服務(wù)器時(shí)它將變得相關(guān)。

熱備有一些限制。這些限制很可能在未來的發(fā)行中被修復(fù)：