資料庫主程序挂了，原有的連接配接還能繼續操作資料庫，你信嗎？下面，由dba+杭州群聯合發起人周正中告訴你，postgresql是怎麼可以做到的。
專家簡介
周正中
網名：德哥@digoal
dba+杭州群聯合發起人之一
postgresql中國社群發起人之一，負責杭州分會，兼任社群cto一職。曾就職于斯凱網絡，負責資料庫部門。現就職于阿裡巴巴，負責rds pg核心組事務。
資料庫主程序挂了，原有的連接配接還能繼續操作資料庫，postgresql就可以做到，并且原來的程序對資料庫的操作是持久化的，不會丢資料哦。這得益于postgresql的程序結構設計。而且postmaster程序隻負責了簡單的工作，例如監聽端口。
有人會問了，wal writer、backgroup writer程序都挂了，資料還能持久化？沒錯，因為backend process也可以完成這些操作，是以不用擔心資料丢失。
建立測試表。
将postgres主程序殺掉。
殺掉主程序後，隻剩下backend process和logger程序，（當然wal buffer和shared buffer還在）。
然後在backend process對應的會話中寫入記錄。可以正常操作。
退出會話後，所有相關的程序都不在了，logger也退出了。
啟動資料庫。
檢視不到之前插入的資料，原因是那個事務是異步的，而wal writter process程序當時已經不在了，backend process雖然可以完成flush wal buffer的功能，但是不像wal writter程序是周期性刷的，而是在申請不到buffer時才會觸發刷buffer的動作。
是以一條記錄就這樣丢失了。
接下來，我們使用同步事務，可以保證資料不丢失。
使用同步事務寫入資料并退出。
可以看到，資料是持久化存儲的。
注意，雖然backend process可以寫wal buffer和shared buffer, 但是不能執行checkpoint, 因為這個操作是checkpoint做的，backend process隻會告知它。當我們在postgres主程序被殺掉後，如果執行一個比較大的操作導緻觸發checkpoint的話，會在日志中看到這樣的資訊。
包括autovacuum, stat collecter process都不在了，是以這些操作也會失敗。
例如：
可以看到對應的日志：
統計資訊程序沒了，是以統計資訊也無法擷取。
這裡還引發一個問題，如果我們使用長連接配接來監控資料庫狀态的話，無法了解主程序是否健康，是以最好還是用短連接配接來監控資料庫，至少可以判斷認證這塊還有主程序是否是正常的。不過短連接配接也有一定的問題，就是可能資料庫的連接配接被占滿了，無法獲得連接配接。有利有弊，長連接配接+短連接配接的方式監控可能更加全面。
[其他]
關于crash自動重新開機的參數：
restart_after_crash (boolean)
對應的代碼，某些場景會導緻資料庫重新開機。
src/backend/postmaster/postmaster.c
例如autovacuum程序被kill。斷開所有backend process，重新開機autovacuum lanucher。
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2015-10-30</b>