為什麼 RDS PostgreSQL 總是在重啟時恢復？

我正在執行 PostgreSQL 9.6.3 的 RDS 實例：select version();返回PostgreSQL 9.6.3 on x86_64-pc-linux-gnu [...].

我發現，在從 RDS 控制台發出停止並啟動後，數據庫總是報告數據庫系統未正確關閉，需要恢復。此行為已由至少一個其他 RDS PostgreSQL 使用者 ( https://forums.aws.amazon.com/message.jspa?messageID=809401#809401 ) 獨立驗證。

查詢

select name, setting
from pg_settings
where name in ('fsync', 'wal_sync_method', 'synchronous_commit');

報告fsync = on, wal_sync_method = fdatasync（對於 Linux 系統正確）和synchronous_commit = on.

發出停止後，我在日誌中看到以下內容：

2017-10-12 16:37:36 UTC::@:[3464]:LOG: received fast shutdown request
2017-10-12 16:37:36 UTC::@:[3464]:LOG: aborting any active transactions
2017-10-12 16:37:36 UTC::@:[3515]:LOG: autovacuum launcher shutting down
2017-10-12 16:37:36 UTC::@:[3512]:LOG: shutting down
2017-10-12 16:37:36 UTC::@:[3512]:LOG: checkpoint starting: shutdown immediate
2017-10-12 16:37:36 UTC::@:[3512]:LOG: checkpoint complete: wrote 1 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 1 recycled; write=0.007 s, sync=0.002 s, total=0.145 s; sync files=1, longest=0.002 s, average=0.002 s; distance=16384 kB, estimate=16402 kB
2017-10-12 16:37:36 UTC::@:[3464]:LOG:  database system is shut down

發出啟動後的以下內容：

2017-10-12 17:05:33 UTC::@:[3293]:LOG: database system was interrupted; last known up at 2017-10-12 16:37:50 UTC
2017-10-12 17:05:33 UTC::@:[3293]:LOG: database system was not properly shut down; automatic recovery in progress
2017-10-12 17:05:33 UTC::@:[3293]:LOG: redo starts at 165/1160
2017-10-12 17:05:33 UTC::@:[3293]:LOG: unexpected pageaddr 164/D2000000 in log segment 000000010000016500000003, offset 0
2017-10-12 17:05:33 UTC::@:[3293]:LOG: redo done at 165/20000A0
2017-10-12 17:05:33 UTC::@:[3293]:LOG: last completed transaction was at log time 2017-10-12 16:50:53.823582+00
2017-10-12 17:05:33 UTC::@:[3293]:LOG: checkpoint starting: end-of-recovery immediate
2017-10-12 17:05:33 UTC::@:[3293]:LOG: checkpoint complete: wrote 2 buffers (0.0%); 0 transaction log file(s) added, 0 removed, 3 recycled; write=0.029 s, sync=0.002 s, total=0.046 s; sync files=2, longest=0.002 s, average=0.001 s; distance=49147 kB, estimate=49147 kB
2017-10-12 17:05:33 UTC::@:[3293]:LOG: MultiXact member wraparound protections are now enabled

鑑於我對 PostgreSQL（快速）關閉和啟動順序的理解，上述日誌消息似乎表明 PostgreSQL 正在編寫並完成關閉前的最終檢查點，然後成功關閉。

但是，根據 xlog.c 第 6023 行和 xlog.c 第 6503 行的程式碼（https://github.com/postgres/postgres/blob/ca9cfed883333d5801716eb01cf28b6b5be2b5cd/src/backend/access/transam/xlog.c；不能發布超過 2 個連結），分別對應於database system was interrupted [...]和database system was not properly shut down [...]log 行，看起來至少pg_control文件沒有刷新到磁碟。這讓我很擔心，因為我希望 Amazon 已經註意確保儲存 PostgreSQL 數據和日誌文件的捲適合用途（即它們在fsync真正完成之前不會報告完成）。

這種行為還有其他解釋嗎？

最初發布該問題的 AWS 開發人員論壇主題中提供了該問題的答案。

概括

RDS PostgreSQL（截至 2018 年 4 月可用的版本）並不總是在重啟後恢復；但是，如果 RDS 實例在未指定的超時時間內沒有關閉，RDS 將強制終止實例，要求 PostgreSQL 在重啟時恢復。

回復全文

感謝您使用 RDS！

我看到這個執行緒在其他地方被引用，並認為我會快速輸入。我與 PostgreSQL 服務團隊密切合作，我可以確認您觀察到的行為是正確的。截至今天（2018 年 4 月），有時，如果關閉沒有足夠快地完成，RDS 自動化將超時並強制終止。類似這樣的各種行為其實早就存在了，大家可能之前也觀察過。在此執行緒上討論的少數特定案例中，我無法真正評論為什麼 PostgreSQL（或其他數據庫引擎）需要比平時更長的時間才能關閉 - 這可能有許多不同的可能原因。

需要明確的是，關於是否以及如何以及何時發生強制終止的細節可能會隨著時間的推移而變化，具體取決於許多變數。永遠不會改變的是 RDS 團隊對客戶數據的持久性和可用性的承諾。這意味著 (1) 我們的工程師在設計時考慮到了安全性，避免了可能以任何方式增加損壞風險的事情；(2) 我們的工程師始終注意停機時間——無論是以分鐘、秒還是毫秒為單位——都值得最小化，因為盡可能安全。

我希望這會有所幫助，聽到您所觀察到的內容是設計使然！

-傑里米

引用自：https://dba.stackexchange.com/questions/188685