?
This document uses PHP Chinese website manual Release
25.2. 日志傳送備份服務器
連續(xù)歸檔可以配合隨時準備取代失效主服務器的一個或多個備份服務器，用于創(chuàng)建一個高可用性(HA)集群。 這個能力通常被稱為熱備份或日志傳送(LogShipping)。
雖然主服務器和備份服務器只是松散的耦合在一起，但它們必須同時運行。 主服務器以連續(xù)歸檔模式運行，備份服務器以連續(xù)恢復模式運行并從主服務器不停的讀取WAL文件。 因為數(shù)據(jù)庫的表無需為此進行任何改變，所以與其它復制方法相比，額外的管理開銷很小。 并且這種方法對主服務器的性能影響也很小。
直接移動WAL或在數(shù)據(jù)庫服務器之間"傳送"日志記錄通常被稱為日志傳送(LogShipping)。 PostgreSQL實現(xiàn)了基于文件的日志傳送，意思是WAL記錄每次移動一個完整的文件(WAL段)。 WAL文件可以被輕易的在任意兩個地點之間傳送，不管是與鄰近的系統(tǒng)還是地球另一面的系統(tǒng)。 所需帶寬取決于主服務器的事務發(fā)生速度。 基于記錄的日志傳送也可以通過Section 25.2.5中討論的自定義過程實現(xiàn)。
日志傳送是異步的，也就是WAL記錄在事務提交之后才被傳送。 也就是說主服務器遭遇致命故障后尚未傳送的事務數(shù)據(jù)將會丟失。 數(shù)據(jù)丟失的長度可以使用archive_timeout加以限制，比如限制為幾秒鐘。 當然這么小的設置也導致了傳送帶寬的大幅增長。 如果你期望將丟失的數(shù)據(jù)限制在一分鐘之內(nèi)，可能更好的辦法是使用基于記錄的日志傳送。 參考Section 25.2.5。
因為不停的執(zhí)行恢復過程，備份服務器在通常情況下是不能被訪問的。 由于恢復速度非常快，備份服務器通常在啟用后只有很短的時間不能使用。 因此，我們認為這個方案可以作為熱備份來提供高可用性。 將服務器從一個已歸檔的基礎備份中恢復將可能耗費大量時間，所以這個方案只能用于災難恢復而不能用于提供高可用性。
25.2.1. 規(guī)劃
至少從數(shù)據(jù)庫服務器的角度看，創(chuàng)建主服務器和備份服務器并令兩者盡可能完全相同是非常明智的。 特別是表空間的路徑名必須保持完全一致，這樣主服務器和備份服務器就必須擁有同樣的表空間掛載路徑(如果使用了表空間的話)。 需要記住的是如果在主服務器上執(zhí)行了CREATE TABLESPACE命令， 那么該命令需要的任何新掛載點必須在執(zhí)行該命令之前同時在主服務器和備份服務器上創(chuàng)建。 硬件不必完全相同，但是經(jīng)驗顯示維護兩個完全相同的系統(tǒng)比維護兩個不同的系統(tǒng)要少許多麻煩。 無論如何，應盡量保持體系結構相同，比如一個是32-bit系統(tǒng)另一個是64-bit系統(tǒng)將不能正常工作。
通常，在主版本不同的服務器之間傳送日志是不可能的，但是次版本不同是可以的，因為它們的磁盤格式相同， 不過我們鼓勵你盡可能使用完全相同的版本。 在進行版本升級的時候，正確的做法是首先升級備份服務器， 因為新版本的服務器通?？梢宰x取老版本的WAL文件，但反之則不然
25.2.2. 備用服務器操作
在備用模式，該服務器連續(xù)應用從主服務器收取的WAL。備服務器可以從一個WAL歸檔（參閱restore_command）或 直接通過一個TCP連接（流復制）從主服務器上讀取WAL。備服務器也可以在備用集群pg_xlog嘗試查找恢復任何WAL。 這通常發(fā)生在服務器重啟后，當備服務器重播，在備服務器重啟前，從主服務器流復制的WAL，但是你也可以手工復制文件到pg_xlog， 在任何時候可以重播它們。
在啟動，備服務器恢復可用在所有的WAL開始存檔位置,調用restore_command。 一旦它到達可用WAL的結束，restore_command失敗，將嘗試恢復pg_xlog目錄下任何可用的WAL。 如果那也失敗了，并且已經(jīng)配置了流復制，則嘗試連接到主服務器，從在歸檔或pg_xlog找到最后一條有效的記錄開始WAL流。 如果那也失敗了，或沒有配置流復制，或連接斷開，備服務器再次回到步驟1，循環(huán)嘗試從歸檔里恢復文件。從歸檔，pg_xlog， 通過連續(xù)流復制直到服務器停止或有觸發(fā)器文件觸發(fā)的失效切換時。
當找到一個觸發(fā)文件（trigger_file）時，退出備用模式并且服務器切換到正常運行。在失效切換前，將立即恢復歸檔或pg_xlog 任何可用的WAL，但不做嘗試連接主服務器。
25.2.3. 為備用服務器準備主服務器
在主服務器上設置連續(xù)歸檔到一個備服務器可訪問的存檔目錄，像描述在Section 24.3。 即使主服務器關掉，從備服務器應該可以訪問這個歸檔位置。即它應該駐留在被服務器自身或其它可信賴的服務器，而不是主服務器。
如果你想使用流復制，在主服務器上設置認證，允許從備用服務器復制連接； 在pg_hba.conf提供一個或多個合適項使用數(shù)據(jù)庫字段設置replication。 還要在主服務器的配置文件確保設置max_wal_senders足夠大。
啟動備用服務器做一個基準備份，描述在Section 24.3.2.
25.2.4. 建立備用服務器
要建立備用服務器，從主服務器恢復基準備份（參閱Section 24.3.3）。 在備用服務器的集群數(shù)據(jù)目錄，創(chuàng)建一個恢復命令文件recovery.conf,開啟standby_mode。 設置restore_command為一條從WAL歸檔復制文件的簡單命令。
Note: 不要使用內(nèi)置在這里描述的備用模式pg_standby或類似的工具。如果該文件不存在，restore_command應該立即返回。 如果必要服務器將再次嘗試這個命令。參閱Section 25.4關于使用工具像pg_standby。
如果你想使用流復制，在primary_conninfo填寫一個libpq連接串，其包括主機名（或IP地址）和連接到主服務器需要的其它詳細信息。 如果主服務器需要個密碼驗證，也要在primary_conninfo指定所需要的密碼。
如果你要建立高可用目的備服務器，設置WAL歸檔，像主服務器的連接和身份驗證，因為在失效切換后，備服務器要作為主服務器運行。 你還需要設置trigger_file它可能失效切換。如果你建立報告目的備服務器，沒有規(guī)劃失效切換到它，不必須要trigger_file。
如果你使用WAL歸檔，其大小可以使用archive_cleanup_command 這個參數(shù)設置最小，用來刪除那些備服務器不再需要的文件。專門設計的pg_archivecleanup 這個實用程序就是在通常的單備配置里，使用archive_cleanup_command的。 請注意不過，如果你使用備份目的歸檔，你仍要保留需要恢復的至少最新的基準備份文件，即使備服務器不再需要。
recovery.conf一個簡單例子是：
standby_mode='on' primary_conninfo='host=192.168.1.50port=5432user=foopassword=foopass' restore_command='cp/path/to/archive/%f%p' trigger_file='/path/to/trigger_file' archive_cleanup_command='pg_archivecleanup/path/to/archive%r'
你可能有任何數(shù)目的備服務器，但是如果你用流復制，確保你在主服務器上設置的max_wal_senders足夠大允許它們同時連接。
25.2.5. 流復制
與基于文件日志傳送相比，流復制允許保持備服務器更新。 備服務器連接主服務器，其產(chǎn)生的流WAL記錄到備服務器，而不需要等待填寫WAL文件。
流復制是異步的，所以在主事務提交和變化成為在備服務器可見之間,還有一個小的延遲。 這個延遲遠小于基于文件日志傳送，通常1秒內(nèi)足夠與負載保持。使用流復制，為減少數(shù)據(jù)丟失窗口 archive_timeout不是必要的。
如果使用流復制而不是基于文件連續(xù)歸檔，你要在主服務器設置wal_keep_segments為 一個足夠大的值以使不太早的回收舊WAL段，當備服務器可能仍需要它們趕上。如果備服務器落后太多， 需要用一個新基準備份重新初始化。如果你設置一個備服務器可訪問的WAL歸檔，wal_keep_segments是不必要的， 作為備服務器總是使用歸檔來趕上。
要使用流復制，建立一個基于文件的日志傳送備服務器描述在Section 25.2。 該步將一個基于文件的日志傳送備服務器轉為流復制備服務器，在recovery.conf文件中設置primary_conninfo 指向主服務器。在主服務器上設置listen_addresses和身份驗證選項（見pg_hba.conf），因此備用服務器 可以連接到在主服務器的replication偽數(shù)據(jù)庫（參閱Section 25.2.5.1）。
在系統(tǒng)上支持保持活動的的套接字選項，設置tcp_keepalives_ idle， tcp_keepalives_interval和tcp_keepalives_count幫助主機及時發(fā)現(xiàn)斷開的連接。
設置備用服務器的最大并發(fā)連接數(shù)。（參閱max_wal_senders關于詳細信息）。
當啟動了備服務器并且正確設置了primary_conninfo,該備服務器在回放所有可用的WAL文件后，將連接到主服務器。 如果成功建立了該連接，你將在備服務器中看到WAL接收進程，并且在主服務器相應的一個WAL發(fā)送進程。
25.2.5.1. 身份驗證
復制的訪問權限設置是很重要的，所以只有受信任的用戶可以讀取WAL流，因為很容易從中提取權限信息。 備服務器必須驗證作為主服務器的超級用戶。所以需要在主服務器上創(chuàng)建一個有SUPERUSER和LOGIN權限的角色。
由一條pg_hba.conf記錄指定replication在database字段，控制客戶端的復制驗證。 例如，如果備服務器是運行在主機IP192.168.1.100和復制時超級用戶名為foo，管理員可以在主服務器 pg_hba.conf文件里添加下面行：
#Allowtheuser"foo"fromhost192.168.1.100toconnecttotheprimary #asareplicationstandbyiftheuser'spasswordiscorrectlysupplied. # #TYPEDATABASEUSERCIDR-ADDRESSMETHOD hostreplicationfoo192.168.1.100/32md5
主服務器的主機名和端口號，連接用戶名，和在recovery.conf文件指定的密碼。 該密碼也可以在備服務器的~/.pgpass文件里設置。 （在database字段指定replication）。 例如，如果主服務器是運行的主機IP192.168.1.50,端口號5432, 復制時超管用戶名為foo，和密碼為foopass，管理員可以在備服務的recovery.conf文件里 添加下面行：
#Thestandbyconnectstotheprimarythatisrunningonhost192.168.1.50 #andport5432astheuser"foo"whosepasswordis"foopass". primary_conninfo='host=192.168.1.50port=5432user=foopassword=foopass'
25.2.5.2. 監(jiān)控
流復制的一個重要的健康指標是在主服務器生成的WAL記錄數(shù)，而不是在備服務器應用的數(shù)量。
通過比較在主服務器當前WAL寫的位置和備服務器收到的最后一個WAL位置，就可以計算出這種滯后。
在主服務器上使用pg_current_xlog_location和在備服務器上使用pg_last_xlog_receive_location
可以分別檢索到它們（參閱Table 9-56和Table 9-57關于詳細信息）。
在備服務器收到最后的WAL位置也會進程狀態(tài)的WAL接收進程顯示，使用ps命令顯示（參閱Section 27.1關于詳細信息）。