PostgreSQL Replication之第四章 設定非同步複製（4）

標籤：

4.4 基於流和基於檔案的恢複

生活並不總只是黑色或白色；有時也會有一些灰色色調。對於某些情況下，流複製可能恰到好處。在另一些情況下，基於檔案複製和PITR是您所需要的。但是也有許多情況下，您既需要流複製，也需要基於檔案的複製。一個例子是：當您較長一段時間中斷複製，您可能想再次使用歸檔來重新同步(resync)slave，而不是再次執行完全的基礎備份。這也可能是有用的---保留一個歸檔一段時間以後調查或重放操作。好訊息是PostgreSQL允許您混合基於檔案和基於流的複製。您沒有必要決定基於流的好還是基於檔案的好，您可以同時使用兩種方式的優勢。您該怎麼做呢？事實上，您已經看到了所有的步驟；我們只需按照正確的方式把它們放在一起。

為了讓這對您來說更容易，我們已經為您編寫了一個完整的例子。

4.4.1 master配置

master上，我們在postgresql.conf中使用如下配置：

wal_level = hot_standby

# minimal, archive, or hot_standby

# (change requires restart)

archive_mode = on

# allows archiving to be done

# (change requires restart)

archive_command = ‘cp %p /archive/%f‘

# command to use to archive a logfile segment

# placeholders: %p = path of file to archive

# %f = file name only

max_wal_senders = 5

# we used five here to have some spare capacity

除此之外，我們必須添加一些配置到pg_hba.conf來允許流機制。下面是一個例子：

# Allow replication connections from localhost, by a user with the

# replication privilege.

local replication hs trust

host replication hs 127.0.0.1/32 trust

host replication hs ::1/128 trust

host replication all 192.168.0.0/16 md5

在我們的例子中，我們只是簡單地開了一個完整的網路以允許複製(保持例子簡單).

一旦我們做了這些改變，我們就可以重新啟動master，並做一個如本章前面所做的基礎備份。

4.4.2 slave配置

一旦我們配置了master並做了基礎備份，我們就可以開始配置我們的slave系統。為了簡單起見，我們假設我們只是用一個slave；我們不會級聯複製到其他系統。

我們只需要改變slave的postgresql.conf中的一行：

hot_standby = on # to make the slave readable

下一步，我們可以寫一個簡單的recovery.conf檔案，並把它放到主要資料目錄：

restore_command = ‘cp /archive/%f %p‘

standby_mode = on

primary_conninfo = ‘ host=sample.postgresql-support.de port=5432 ‘

trigger_file = ‘/tmp/start_me_up.txt‘

我們啟動slave,會發生如下事情：

1. PostgreSQL 會調用 restore_command 命令來從歸檔取交易記錄。

2.直到歸檔中沒有更多的記錄檔才會停止調用restore_command。

3. PostgreSQL 會嘗試建立流串連。

4.如果資料存在它將執行流操作。

°如果沒有資料存放區在, 它將調用 restore_command 命令從歸檔取交易記錄。

° 它將一直執行該操作，直到歸檔裡沒有更多的資料。

° 它將再次嘗試建立流串連。

只要您需要就可以保持流操作。如果您想把slave轉換為master，您可以再次使用pg_ctl promote 或 recovery.conf中定義的 trigger_file。

 

4.4.3 錯誤情境

雙重策略的最重要的優勢是您可以建立一個叢集，它提供一個更高的安全層級，而不僅僅是基於流或簡單的基於檔案的重放。

在本節，我們可以討論一些在雙重策略叢集中典型的錯誤情境。

master和slave之間的網路連接中斷

如果網路出現故障，master可能將不能再成功地執行archive_command操作。XLOG檔案的曆史必須保持繼續，因此，為了以後的歸檔，master必須對那些XLOG檔案進行排隊。這可能是一個危險的情境，因為如果檔案流被永久地中斷，您可能用完master上XLOG的空間。

如果流串連失敗，PostgreSQL將會嘗試通過基於檔案的通道來保持同步自身。如果基於檔案的通道也失敗了，slave將呆在那裡等待網路連接回來。一旦網路回來，它將嘗試擷取XLOG並簡單地繼續。

[請記住，slave需要不間斷的XLOG流；如果沒有XLOG檔案丟失或如果流串連仍然可以為slave提供slave需要操作的XLOG,,它只能繼續重放XLOG。]

重新啟動slave

只要歸檔有XLOG來做slave的備份，重新啟動slave將不會有任何傷害，slave將只會再次啟動並嘗試從任何可用的來源獲得XLOG。不會出現崩潰或任何其他這類問題。

重新啟動master

如果master重新啟動，這種情況同樣沒有什麼可以批判的。slave將會通過流串連通知master找不到了。它會嘗試通過兩個渠道擷取XLOG，但它不會成功，直到master回來。同樣沒有像崩潰之類的不好的事情 發生。重新啟動兩個伺服器，操作就可以簡單地恢複了。

在歸檔中損壞的XLOG                       

如果XLOG在歸檔匯總損壞，我們要區分兩種情況：

1. slave正在流傳輸： 如果流沒問題並且是完整的, slave 將不會注意到在歸檔中有一些XLOG檔案在某種程度上被損壞。只要流串連是可用的，slave永遠不需要從XLOG檔案讀取。

2. 如果我們沒有使用流，而是從一個檔案重放， PostgreSQL 將會檢查每條 XLOG 記錄並看它的校正和是否正確。如果發生任何錯誤, slave 將不會繼續重放損壞的XLOG。 這將確保不會衍生出來其他問題，沒有損壞的XLOG被重放。您的資料庫可能是不完整的，但這將是明智的，到出錯點都是一致的。

當然，有太多的事情會出錯，但是鑒於這些相似的情況，您可以清楚地看到，該設計已經是儘可能的可靠了。

原文地址：http://www.cnblogs.com/songyuejie/p/4743516.html

PostgreSQL Replication之第四章 設定非同步複製（4）