首先引用 PostgreSQL 9.1 Release Notes 裡面的一段話 :

解釋一下什麼是時間線檔案 : 檔案名如 000000xx.history 

這個檔案在standby 資料庫被 promote 時産生，放在被promote的standby資料庫的pg_xlog目錄 。

這個檔案産生的同時，被promote的資料庫的timeline随之改變。可以在被promote的資料庫的伺服器上執行pg_controldata檢視到latest checkpoint's timelineid : 這條記錄的改變 。

假設以上的切換是在primary節點幹淨的關閉(-m fast或-m smart)資料庫的情況下做的，并且關庫過程中standby節點和primary節點保持暢通，那麼正常情況下standby節點将接收到primary節點關庫後的最後一次checkpoint資訊。也就是說，standby在promote後，原來的主節點可以作為新的主節點的standby庫的基礎備份，但是需要設定recovery.conf的recovery_target_timeline = 'latest' , 并且需要000xxxx.history這個檔案作為恢複檔案。其實就是本文開篇時提到的這個動作 “ scan the archive directory for new timelines periodically . "

postgresql 9.0 已經存在這個過程，可以參考我以前寫的blog ： 

http://blog.163.com/digoal@126/blog/static/163877040201141154024306/

下面來測試一下9.1 : 

首先是建立一個primary-standby環境。

 primary庫操作 : 

1. 建立primary 資料庫，略 . 

2. 修改primary 資料庫相關參數 .

3. 新增replica 使用者.

4. 修改pg_hba.conf

增加一條

5. 建立~/.pgpass檔案,省的待會切換為standby的時候再配置.為對方的ip。

vi /home/postgres/.pgpass

 standby庫操作 : 

1. 安裝postgresql軟體

編譯條件與原庫一樣。

2. 編譯與主庫一樣pg插件,

如果主庫新增了插件，那麼備庫需要新增一樣的插件。

譬如說我的主庫新增了pgfincore和oracle_fdw的插件，那麼在備庫也要新增這兩個插件，否則使用到這些插件的時候會報錯。甚至資料庫會起不來。

3. 建立相關目錄(主資料目錄,表空間目錄,pg_xlog目錄,或者賦予對應的父目錄權限,日志目錄)。

如果不使用pg_basebackup來建立standby的話，這些操作會更加明朗一下。

4. 新增.pgpass , 為對方的ip。

5. 使用pg_basebackup這個9.1新增的指令來建立standby基備。在此之前, 重新開機一下主庫使之配置生效.

6. 拷貝/opt/pgsql/share/recovery.conf.example到$pgdata下面

修改

postgres@172_168_3_xx-> cat recovery.done |grep -v "^#"

7. 啟動standby資料庫

至此環境搭建完畢。

接下來測試的是角色切換，譬如說我們要對主庫添加記憶體或者維護主機的伺服器或者存儲。需要把主庫停掉。但是在維護完後還要起來。

維護可能需要幾個小時，業務肯定受不了。那麼需要激活備庫先頂一段時間。

接下來就是整個切換過程。

一、 檢查操作：

檢查主庫和備庫的複制正常進行中。

二、 主庫操作：

停止主庫 , 千萬不要用-m immediate,這個不會産生關機checkpoint,也不會發送checkpoint給standby。會造出過程不可逆。

停庫日志解析 : 

停庫結束後，主庫還有幾個程序，一個是主程序，一個是記錄日志的程序，一個是sender程序。是以這種關閉是會把所有的資訊發送給standby庫的。

程序如下 :

資料發完，這些程序會自動關閉。

備庫日志 :

在主庫關閉過程中，備庫上可以看到類似以上的日志，表明主庫正在發關閉過程的xlog資訊給備庫。主庫關閉後，備庫連不到主庫，是以有後面那段報錯，這是正常的。此時就可以對備庫進行激活操作了，這樣的主備角色切換不會丢失任何資料。

四、 備庫操作：

确認主庫正常關庫後，激活備庫.

備庫激活成主庫後，把應用改為連接配接新的主庫。

接到promote信号後，資料庫日志如下 :

激活前後程序差異解析 : 

激活前,recovery狀态.程序如下 :

激活後,open狀态.程序如下 : 

激活後多了 wal writer process , autovacuum launcher process , archiver process , wal sender process . 

少了 startup process , wal receiver process . 

五、 維護原來的主庫。

六、 維護好後，把原來的主庫作為standby 啟動。

1. 拷貝/opt/pgsql/share/recovery.conf.example到$pgdata下面

2. 啟動資料庫

3. 此時，這個老主庫會報錯，

這個就是在找時間線檔案。這裡的時間線檔案内容如下 : 

這個報錯可在源碼檔案src/backend/replication/libpqwalreceiver/libpqwalreceiver.c中找到。

對應部分 :

4. 我們到新主庫的pg_xlog找到這個檔案，然後再老的主庫pg_xlog目錄建立這個檔案寫入同樣的内容就解決了。或者直接scp過去。

5. 檢查複制，確定複制正常。

6. 主庫和備庫接近一緻後，再來一次主庫和備庫角色切換的操作。

    6.1 關閉新主庫。

    6.2 激活老主庫。

激活完後，新增了一個時間線檔案内容如下，每次時間線變更的記錄都将累計下來 :

  6.3 然後配置新主庫變回standby。

當然，這個時間線檔案也可以放在archive directory。

然後通過以下的recovery.conf裡面配置的指令來尋找。