?
Dokumen ini menggunakan Manual laman web PHP Cina Lepaskan
熱備術語是用來形容連接到服務器,并運行只讀查詢的能力,而服務器在歸檔恢復或備模式。 對復制目的和非常精確的備份恢復到所需的狀態(tài),這是非常有用的。 長期的熱備,也指從恢復到正常運行的服務器的能力,而用戶繼續(xù)運行的查詢和/或保持連接開放。
在熱備用模式運行查詢與正常的查詢操作類似,雖然有幾個使用和管理的差異解釋如下。
當備用服務器上hot_standby參數(shù)的設置為真時,將開始接受連接,一旦恢復帶來的系統(tǒng)到一致的狀態(tài)。 所有這些連接都嚴格只讀的,甚至可能沒有可寫的臨時表。
數(shù)據(jù)從主服務器到備服務器上需要一些時間,所以會有一個主備數(shù)據(jù)庫間的可測量的延遲。 因此,在主備服務器上幾乎同時運行同樣的查詢返回不同的結果。我們說在備服務器上的數(shù)據(jù)最終與主服務器上的一致。 一旦事務提交記錄在備服務器是上回放,由事務產(chǎn)生的變化對于在備服務器上的任何新快照來說是可見的。 快照可能是在每個查詢或事務的開始,取決于當前事務的隔離級別。請參閱Section 13.2獲取更多的信息。
熱備期間開始的事務可能會發(fā)出下面的命令:
查詢訪問-SELECT,COPYTO
游標命令-DECLARE,FETCH,CLOSE
參數(shù)-SHOW,SET,RESET
事務管理命令
BEGIN,END,ABORT,STARTTRANSACTION
SAVEPOINT,RELEASE,ROLLBACKTOSAVEPOINT
EXCEPTION阻塞其它內(nèi)部的子事物。
LOCKTABLE,但是僅當明確在這些模式之一: ACCESSSHARE,ROWSHARE或ROWEXCLUSIVE.
規(guī)劃和資源-PREPARE,EXECUTE, DEALLOCATE,DISCARD
Pluginsandextensions-LOAD
在熱備期間開始的事務,將從不會分配事務ID,并且不能寫入到系統(tǒng)預寫日志。 因此,以下操作將產(chǎn)生錯誤信息:
數(shù)據(jù)操縱語言(DML)-INSERT, UPDATE,DELETE,COPYFROM, TRUNCATE. 請注意,不允許操作在恢復期間正執(zhí)行觸發(fā)器的結果。此限制也適用于臨時表,因為不分配一個事務ID,不能讀取或?qū)懭氡硇校? 在一個熱備環(huán)境這種情況是不可能的。
數(shù)據(jù)定義語言(DDL)-CREATE, DROP,ALTER,COMMENT。 甚至臨時表也適用這個限制,因為執(zhí)行這些操作將需要更新系統(tǒng)空間表。
SELECT...FORSHARE|UPDATE,因為行鎖,不能不采取更新底層數(shù)據(jù)文件。
在SELECT語句上的規(guī)則產(chǎn)生DML命令。
LOCK明確要求一個高于ROWEXCLUSIVEMODE的模式。
LOCK簡短的缺省形式,自它請求ACCESSEXCLUSIVEMODE.
事務管理命令明確設置非只讀狀態(tài):
BEGINREADWRITE, STARTTRANSACTIONREADWRITE
SETTRANSACTIONREADWRITE, SETSESSIONCHARACTERISTICSASTRANSACTIONREADWRITE
SETtransaction_read_only=off
兩階段提交命令-PREPARETRANSACTION, COMMITPREPARED,ROLLBACKPREPARED 因為即使只讀事務需要在準備階段寫WAL。(兩種階段提交的第一個階段)。
序列更新-nextval()
,setval()
LISTEN,UNLISTEN,NOTIFY
在正常的操作,允許"只讀"事務更新序列,使用LISTEN、UNLISTEN、和 NOTIFY,所以熱備會話下操作會比通常的只讀會話限制稍微更嚴格。在將來的版本中這些限制中的一些可能會放寬。
熱備間,transaction_read_only這個參數(shù)總為真,可能不會變。但只要沒有試圖修改數(shù)據(jù)庫, 在熱備的連接,將行動就像任何其它的數(shù)據(jù)庫連接。如果發(fā)生失效切換或倒換,數(shù)據(jù)庫將切換到正常的處理模式。 當服務器改變模式,會話將保持連接。一旦熱備完成,有可能初始化讀寫事務(即使從熱備間的會話)。
通過發(fā)出的SHOWtransaction_read_only將能告訴用戶他們的會話是否只讀的。 另外,一組函數(shù)允許用戶訪問關于備服務器的信息。(請參閱Table 9-57) 這些允許你寫程序獲知數(shù)據(jù)庫的當前狀態(tài)。這些可以用來監(jiān)視恢復進程,或允許你寫復雜的程序來恢復數(shù)據(jù)庫到特定狀態(tài)。
主備服務器是許多方式松散連接的。在主服務器上的活動將在備服務器上生效。作為一個結果, 它們之間有潛在的負面交互或沖突.最容易理解的沖突是性能:如果在主服務器上發(fā)生大數(shù)據(jù)量加載, 然后將在備服務器上產(chǎn)生類似的WAL記錄流,所以備服務器查詢可能競爭系統(tǒng)資源,像I/O。
在熱備也可能發(fā)生額外的類型沖突。在該場景下,這些沖突是硬沖突。可能需要取消查詢,在某些情況下, 為了解決它們,斷開連接。給用戶提供幾種解決這些沖突的方法。沖突情況包括:
在主服務器上采取訪問排斥鎖,包括明確的LOCK命令和多種DDL操作,在備服務器查詢訪問表沖突。
在主服務器上刪除表空間與備服務器查詢使用該空間的臨時工作文件沖突。
在主服務器上刪除一個數(shù)據(jù)庫與在備服務器上連接到那個數(shù)據(jù)庫的會話沖突。
一個從WAL清空記錄的應用程序vacuum與在備服務器上事務,其快照仍然可以"看到"已刪除的行。
一個從WAL清空記錄的應用程序vacuum與在備服務器上查詢訪問該目標頁,不管要刪除的數(shù)據(jù)是否可見。
在主服務器上,這些情況簡單等待結果,用戶可能選擇取消任何沖突的操作。盡管,在備服務器上沒有選擇: 在主服務器上已經(jīng)發(fā)生的WAL日志,所以備服務器應用它一定不會失敗。此外,允許WAL應用無限期等待可能是很不明智的。 因為備服務器的狀態(tài)將變?yōu)樵隽窟h落后主服務器的。因此,提供一個機制,強行取消備服務器上與將要應用WAL記錄沖突的查詢。
一個該問題情況的例子是管理員在主服務器上運行DROPTABLE一張表,而備服務器當前正查詢這張表。 如果在備服務器上執(zhí)行了DROPTABLE,明確的備服務器查詢不能繼續(xù)。如果這個問題情況發(fā)生在主服務器。則DROPTABLE將等到 其它查詢完成。但是當DROPTABLE運行在主服務器時,主服務器不會有關于備服務器查詢的信息,因此,將不等待任何備服務器查詢。 當備服務器查詢在運行時,WAL改變的記錄來到備服務器,導致一個沖突。備服務器要么延遲應用WAL記錄(任何事情也都要在它們之后),不然取消沖突的查詢, 由此可以應用DROPTABLE。
當一個沖突查詢短的,通常想要允許它完成而延遲WAL應用程序一點點。但是長時間的延遲WAL應用程序通常不是想要的。 所以取消機制有參數(shù)max_standby_archive_delay和max_standby_streaming_delay, 這定義在WAL應用程序中允許延遲最大值。一旦查詢沖突比應用任何新收取的WAL數(shù)據(jù)設定有關延遲長,則取消查詢沖突。 有兩個參數(shù),因此有兩個不同延遲,為從歸檔讀取WAL數(shù)據(jù)(即從一個基準備份初始化恢復或已經(jīng)遠落后的備服務器趕上) 和通過流復制讀取WAL數(shù)據(jù)的指定延遲。
在備服務器存在高可用性的主服務器,最好設置延遲參數(shù)相對短,因此不會由備服務器查詢所導致延遲使遠落后主服務器。 不過,如果備服務器意思為執(zhí)行長時間的查詢,那么一個高的或無期限的延遲值是可取的。請記著如果延遲WAL記錄應用程序,則長時間查詢將導致 備服務器上的其它會話不能看到最新的變化。
在備服務器查詢和WAL回放之間沖突,最常見的原因是"早清除"。 正常地,PostgreSQL允許清除舊版本行,當根據(jù)MVCC規(guī)則確保正確的數(shù)據(jù)可見性,沒有事務需要見到它們。 盡管,這個規(guī)則只能應用于主服務器執(zhí)行的事務。所以在主服務器上清空將刪除行版本,在備服務器上對于一個事務仍然可見。
有經(jīng)驗的用戶應該知道行版本清理和行版本凍結都與備服務器查詢沖突。運行手工的VACUUMFREEZE很可能導致沖突,即使表上沒有 更新和刪除行。
一旦超過了由max_standby_archive_delay或max_standby_streaming_delay指定的延遲,將取消查詢沖突。 這通常結果是一個取消錯誤,雖然在回放DROPDATABASE整個數(shù)據(jù)庫的情況下,將終止沖突會話。此外,如果沖突由空閑事務保持, 終止沖突會話。(這個行為可能在將來版本改變)。
可能立即重試已取消的查詢(在開始一個新事務之后,當然)。自查詢?nèi)∠蕾囉赪AL記錄正回放的本質(zhì),如果再次執(zhí)行,已經(jīng)取消的查詢可能很成功。
請記住這些參數(shù)與從備服務器接收WAL數(shù)據(jù)開始所經(jīng)過的時間比較。允許備服務器上任何查詢的寬期限,從不超過該延遲參數(shù), 并且如果備服務器存在落后主服務器,那么期限的可能相當小。如等待之前查詢執(zhí)行完成的結果,或不能跟上有大量的更新負載的結果。
用戶應該清楚那些表,在主服務器上定期和大量更新表將會很快導致取消備服務器上長時間運行的查詢。 在這類情況下,對max_standby_archive_delay或max_standby_streaming_delay設置一個有限值, 類似于設置statement_timeout。
如果發(fā)現(xiàn)不能接受某些取消備服務器查詢,補救存在的可能性。第一個選項是連接主服務器,并保持一個查詢活動的按照備服務器上運行查詢
所需要的時間。這阻止VACUUM刪除最近的死行,因此清理沖突不會發(fā)生。這能使用contrib/dblink和pg_sleep()
,
或通過其它機制。如果你這樣做,你應該知道這將延遲主服務器清理死行,其可能不想要的表膨脹結果。不過這種情況清理不遜于如果備服務器查詢直接運行在
主服務器上,并且你仍然得到卸載執(zhí)行在備服務器上的好處。在這種情況下max_standby_archive_delay必須是保持大的,因為延遲WAL文件可能已經(jīng)
包含了備服務器查詢想要的記錄項。
另一個選項是在主服務器上增加vacuum_defer_cleanup_age,從而將不會像通常很快的清理掉死行。 這將允許在備服務器上取消它們前,更多時間給執(zhí)行查詢,無需設置一個高的max_standby_streaming_delay。 雖然用這種方法保證窗口的執(zhí)行時間是有困難的,因為vacuum_defer_cleanup_age在主服務器執(zhí)行的事務中是可測的。
如果在postgresql.conf啟用了hot_standby,并且目前有個recovery.conf文件, 該服務器將運行在熱備模式。不過可能花些時間為允許的熱備連接,因為該服務器不接受連接直到完成足夠的恢復能提供一致的狀態(tài), 其查詢能運行。在這個期間,將帶有一個錯誤信息拒絕客戶端嘗試連接。為確認該服務器起來了,要么循環(huán)嘗試從應用程序連接,或者 在服務器日志里查看這些錯誤信息:
LOG:enteringstandbymode ...thensometimelater... LOG:consistentrecoverystatereached LOG:databasesystemisreadytoacceptreadonlyconnections
在主服務器上每個檢查點一致的信息記錄一次。在主服務器上沒有將wal_level設置為 hot_standby時,當讀取正在寫的WAL時,啟用熱備是不可能的。 存在這些條件的兩者也可能延遲達到一致性狀態(tài):
一個寫事務有多于64個子事務
很長時間活動的寫事務
如果你正運行基于文件日志傳送(“暖備”),你可能需要等到下一個WAL文件到來,其可能長如在主服務器設置的archive_timeout。
有些參數(shù)的設置在備服務器將需要重新配置,如果在主服務器改變了它們。對于這些參數(shù), 備服務器上的值要大于或等于主服務器上的。如果這些參數(shù)沒有設置足夠高,那么備服務器將拒絕啟動。 提供了更高的值,重啟該服務器再開始恢復。這些參數(shù)是:
max_connections
max_prepared_transactions
max_locks_per_transaction
管理員選擇合適的設置為max_standby_archive_delay和max_standby_streaming_delay是很重要的。根據(jù)業(yè)務的優(yōu)先級,最好的選擇有所不同。 例如:如果服務器是主要任務,作為高可用性的服務器,那么你想低延遲設置,也許設置為0,盡管這也是很積極的設置。 如果備服務器的任務作為決策支持的額外服務器,那么可能接受設置最大延遲為幾個小時,或甚至-1意味著永遠等待查詢完成。
在主服務器上寫的事務狀態(tài)"提示位"沒有記錄WAL日志,所以在備服務器上將或許再次重寫該提示。 因此,備服務器將仍然進行寫磁盤即使所有用戶是只讀的,數(shù)據(jù)值自身沒有發(fā)生改變。用戶將仍然寫大量排序的臨時文件和 重新生成緩存的信息文件,所以在熱備模式數(shù)據(jù)庫沒有部分是真只讀的。 還要注意寫到遠程數(shù)據(jù)庫使用dblink模塊,外部數(shù)據(jù)的操作使用PL函數(shù)仍然是可能的,盡管事務是本地只讀的。
在恢復模式里,不接受下面類型的管理命令:
數(shù)據(jù)定義語言(DDL)-如CREATEINDEX
權限和所有權-GRANT,REVOKE, REASSIGN
維護命令-ANALYZE,VACUUM, CLUSTER,REINDEX
再次,請注意在主服務器的“只讀”模式事務中,允許這里的某些命令。
作為一個總結,你不能創(chuàng)建額外的索引,統(tǒng)計也不能僅在備服務器, 如果需要這些管理命令,應該在主服務器執(zhí)行,并且最終這些變化將傳播到備服務器。
pg_cancel_backend()
將在用戶后臺工作,但是不啟動進程,其執(zhí)行恢復。pg_stat_activity
將不顯示為一個啟動進程項,也不顯示做恢復事務的活動。作為一個總結,pg_prepared_xacts在恢復中總是空。
如果你愿解決有疑問準備的事務,在主服務器上查看pg_prepared_xacts和發(fā)出命令來解決這里的事務。
pg_locks將顯示由后臺持有的鎖。pg_locks也顯示 由啟動進程所管理的虛擬事務,其擁有由恢復正回放的事務所持有的AccessExclusiveLocks。 請注意該啟動進程不需要鎖定數(shù)據(jù)庫變化,并且因此非AccessExclusiveLocks其它鎖,不會顯示在啟動進程的pg_locks里。 它們只是推測存在。
Nagios插件check_pgsql將工作,因為用它檢測存在的簡單信息。 check_postgres監(jiān)控腳本將也工作,盡管有些報告值能給不同或迷惑的結果。 例如:上次清理時間將不會保持,自在備服務器沒有清理發(fā)生。運行在主服務器的清理,將仍然發(fā)送它們的 改變到備服務器。
在恢復期間WAL文件控制命令將不工作,比如pg_start_backup
,pg_switch_xlog
等。
動態(tài)加載模塊工作,包括pg_stat_statements。
在恢復中咨詢鎖將工作正常,包括死鎖保護。 請注意咨詢鎖從不寫WAL日志,所以對于一個咨詢鎖在主服務器上或回放WAL在備服務器上沖突不可能的。 在主服務器上需要一個咨詢鎖,在備服務器上已經(jīng)初始化了一個類似咨詢鎖也是不可能的。 咨詢鎖只是與需要它們的服務器相關。
基于觸發(fā)器的復制系統(tǒng)像Slony,Londiste和Bucardo將不在備服務器運行, 盡管在主服務器運行的很好,但變化不會發(fā)送到備服務器應用。WAL回放不是基于觸發(fā)器的,所以你不能從備服務器中繼到任何系統(tǒng),其需要額外的寫或 依賴使用觸發(fā)器。
不能分配新OID,盡管某些UUID生成器可能仍然工作,只要不依靠它們寫新狀態(tài)到數(shù)據(jù)庫。
當前,在只讀事務中不允許創(chuàng)建臨時表,所以在某些情況下存在的腳本將運行不正確。 這個限制可能在以后的版本中放寬。這是一個SQL標準的兼容性和技術問題。
如果表空間是空,DROPTABLESPACE只能成功。有些備服務器用戶可積極的通過temp_tablespaces參數(shù)使用 該表空間。如果在表空間有臨時文件,取消所有活動的查詢來確保刪除臨時文件,所以可以刪除表空間,可以繼續(xù)WAL回放。
在主服務器上運行DROPDATABASE或ALTERDATABASE...SET TABLESPACE將產(chǎn)生一個WAL項,其將導致已連接到在備服務器上的那個數(shù)據(jù)庫的所有用戶,強制斷開連接。 這個動作立即發(fā)生,不管max_standby_streaming_delay設置。請注意ALTERDATABASE...RENAME不會斷開連接的用戶, 在多數(shù)情況下忽視,不過如果某些方式依賴數(shù)據(jù)庫名,可能在某些情況下導致一個程序混亂。
在正常(非恢復)模式,如果你發(fā)出DROPUSER或DROPROLE對于一個有登錄權限的角色,當那個用戶仍然已經(jīng)連接,那么不會 發(fā)生什么對于已連接的用戶-他們保持連接。不過該用戶不能再連接。這個行為在恢復也適用,所以在主服務器上DROPUSER 不能斷開備服務器上該用戶連接。
在恢復中統(tǒng)計采集器是活動的。所有掃描,讀取,塊,索引使用等,將在備服務器中記錄。 回放活動將不復制在主服務器上的影響,因此回放個插入,將不增加插入pg_stat_user_tables列。 恢復開始刪除該統(tǒng)計文件,所以性主備服務器的統(tǒng)計將不同,認為這是個特性,而不是一個臭蟲。
在恢復中自動清理是不活動的。在恢復結束將正常啟動。
在恢復中后臺記錄器是活動的,將執(zhí)行重啟點(類似于主服務器上的檢查點)和正常塊清理活動。這可能包含 存儲在備服務器上的提示信息更新。在恢復中接受CHECKPOINT命令,盡管執(zhí)行一個重啟點而不是一個新檢查點。
各種參數(shù)已經(jīng)在上面提到Section 25.5.2和Section 25.5.3。
在主服務器上,可以使用參數(shù)wal_level和 vacuum_defer_cleanup_age。 max_standby_archive_delay和max_standby_streaming_delay 如果在主服務器上設置沒有影響。
在備服務器,可以使用參數(shù)hot_standby, max_standby_archive_delay和 max_standby_streaming_delay。 只要服務器保留在備模式, vacuum_defer_cleanup_age沒有影響,盡管變?yōu)橄嚓P的,如果備服務器成為主服務器。
有幾個熱備限制。這些可能在將來的版本中解決:
在哈希索引的操作,不會記錄在目前的WAL日志,索引回放將不更新這些索引。
在做快照之前充分認識運行的事務是必需的。事務使用大量的子事務(當前大于64)將延遲 只讀連接的開始直到運行最長寫事務完成。如果這種情況發(fā)生,說明信息將發(fā)送到服務器的日志。
對于備服務器查詢的有效開始點是產(chǎn)生在主服務器上的每個檢查點。如果備服務器關機,當主服務器在關機狀態(tài), 不可能重進熱備直到啟動主服務器,所以在WAL日志里產(chǎn)生進一步的開始點。在最常見的情況下這種情況不是一個問題,它可能發(fā)生。 一般地,如果主服務器關機,不再可用,那可能由于一個嚴重的失敗,需要將備服務器轉(zhuǎn)化為新主服務器運行。 并且有特意取下主服務器的情況,協(xié)調(diào)確保備服務器成為平滑的主服務器,也是標準的處理。
在恢復結束,由準備的事務持有的AccessExclusiveLocks需要鎖表正常數(shù)量的條目的兩倍。如果你計劃 運行大量并發(fā)的準備事務,正常地用AccessExclusiveLocks或你計劃一個大事務用多個AccessExclusiveLocks, 建議你選擇一個大的max_locks_per_transaction值,可能為在主服務器上兩倍這個參數(shù)值。如果你設置max_prepared_transactions 為0,根本不需要考慮這個。