779
PostgreSQL 恢複進程startup hang住的原因分析一例
最近在一個跨廣域網的PostgreSQL primary standby環境中遇到一個比較奇特的問題。
首先primary standby是跨廣域網的，但這不是問題的重點。重點是歸檔也是跨光域網並且使用NFS來讓standby訪問歸檔文件。
standby通過NFS獲取歸檔，通過TCP連接primary實現流複製。
但是不知道什麼原因，NFS出現了問題，即standby無法正常的訪問歸檔文件了，訪問NFS的命令會hang住。
接下來描述一下問題，然後再從PostgreSQL源碼分析問題的原因。
1. standby的restore_command命令(cp /nfsdir/%f %p)hang住，停留在拷貝某個歸檔xlog的狀態。
2. 手工kill 這個cp命令，緊接著standby數據庫crash了。
3. 重啟standby數據庫，發現hang在cp /nfsdir/0000009.history %p的狀態，然而實際上0000009.history是不存在的，主庫的時間線是8，備庫的時間線也是8，那麼是什麼原因導致standby要去找一個不存在的時間線文件呢？
這個原因要到源代碼去尋找答案。
我們一般配置流複製環境，會設置recovery_target_timeline=latest，這樣做的目的是配置一個hot_standby，如果上遊切換了時間線，可以自動跟上。
而這個就可以解釋為什麼standby recovery的時候要去找一個不存在的時間線文件？
見源碼：
src/backend/access/transam/timeline.c
/*
* Find the newest existing timeline, assuming that startTLI exists.
*
* Note: while this is somewhat heuristic, it does positively guarantee
* that (result + 1) is not a known timeline, and therefore it should
* be safe to assign that ID to a new timeline.
*/
TimeLineID
findNewestTimeLine(TimeLineID startTLI)
{
TimeLineID newestTLI;
TimeLineID probeTLI;
/*
* The algorithm is just to probe for the existence of timeline history
* files. XXX is it useful to allow gaps in the sequence?
*/
newestTLI = startTLI;
for (probeTLI = startTLI + 1;; probeTLI++) # 問題就出在這裏, 探測下一個時間線是否存在。
{
if (existsTimeLineHistory(probeTLI))
{
newestTLI = probeTLI; /* probeTLI exists */
}
else
{
/* doesn't exist, assume we're done */
break;
}
}
return newestTLI;
}
src/backend/access/transam/xlog.c
/*
* See if there is a recovery command file (recovery.conf), and if so
* read in parameters for archive recovery and XLOG streaming.
*
* The file is parsed using the main configuration parser.
*/
static void
readRecoveryCommandFile(void)
......
else if (strcmp(item->name, "recovery_target_timeline") == 0)
{
rtliGiven = true;
if (strcmp(item->value, "latest") == 0)
rtli = 0;
.....
/*
* If user specified recovery_target_timeline, validate it or compute the
* "latest" value. We can't do this until after we've gotten the restore
* command and set InArchiveRecovery, because we need to fetch timeline
* history files from the archive.
*/
if (rtliGiven)
{
if (rtli)
{
/* Timeline 1 does not have a history file, all else should */
if (rtli != 1 && !existsTimeLineHistory(rtli))
ereport(FATAL,
(errmsg("recovery target timeline %u does not exist",
rtli)));
recoveryTargetTLI = rtli;
recoveryTargetIsLatest = false;
}
else
{
/* We start the "latest" search from pg_control's timeline */ # 問題出在這裏，我配置的就是recovery_target_timeline=latest, 所以需要調用findNewestTimeLine. 控製文件是8，所以find 0000009.history.
recoveryTargetTLI = findNewestTimeLine(recoveryTargetTLI);
recoveryTargetIsLatest = true;
}
}
找到原因後，把NFS的問題解決掉，重啟數據庫就好了，再也不會hang住。
[參考]
1. src/backend/access/transam/xlog.c
2. src/backend/access/transam/timeline.c
最後更新：2017-04-01 13:37:07