2009-05-28 27 views
3

偶爾在我們的實驗室,我們的Postgres 8.3數據庫將得到pid文件孤立的,我們在嘗試關閉數據庫時,這條消息:我如何優雅地殺掉舊的服務器進程Postgres的

Error: pid file is invalid, please manually kill the stale server process postgres

發生這種情況時,我們立即執行pg_dump,以便稍後恢復數據庫。但是,如果我們只是殺掉孤兒postgres進程然後啓動它,那麼數據庫將僅使用上次成功關閉的數據啓動。但是如果你在殺死它之前給它psql,數據全部可用,那麼爲什麼pg_dump有效。

有沒有辦法正常關閉孤立的postgres進程,所以我們不必經過pg_dump和恢復?或者是否有辦法在殺死孤立進程後恢復數據庫?

回答

4

根據documentation,您可以發送SIGTERM或SIGQUIT。 SIGTERM是首選。無論哪種方式都不會使用SIGKILL(正如您從個人經驗中所瞭解的那樣)。

編輯:另一方面,你遇到的不正常,可能表明錯誤配置或錯誤。請在pgsql-admin郵件列表上尋求幫助。

3

從不使用kill -9。

我強烈建議您嘗試弄清究竟是如何發生的。錯誤信息來自哪裏?這不是PostgreSQL錯誤消息。你有沒有機會混合不同的方式來啓動/停止服務器(例如,有時候有initscripts,有時候會用pg_ctl)?這可能會導致事情不同步。

但是要回答直接的問題 - 在過程中使用正常殺死(無-9)來關閉它。如果有多個運行,確保你殺死所有的postgres進程。

數據庫將在關閉時始終執行自動恢復。這種情況也發生在kill -9之後 - 所有承諾的數據都應該在那裏。這聽起來像是你有兩個不同的數據目錄安裝在另一個之上或類似的東西 - 這至少在以前是NFS的一個已知問題。

+1

爲什麼不用-9? – Magne 2013-12-09 09:33:51

0

我使用腳本,每分鐘運行一次cron。

#!/bin/bash 

DB="YOUR_DB" 

# Here's a snippet to watch how long each connection to the db has been open: 
#  watch -n 1 'ps -o pid,cmd,etime -C postgres | grep $DB' 

# This program kills any postgres workers/connections to the specified database 
# which have been running for 2 or 3 minutes. It actually kills workers which 
# have an elapsed time including "02:" or "03:". That'll be anything running 
# for at least 2 minutes and less than 4. It'll also cover anything that 
# managed to stay around until an hour and 2 or 3 minutes, etc. 
# 
# Run this once a minute via cron and it should catch any connection open 
# between 2 and 3 minutes. You can temporarily disable it if if you need to run 
# a long connection once in a while. 
# 
# The check for "03:" is in case there's a little lag starting the cron job and 
# the timing is really bad and it never sees a worker in the 1 minute window 
# when it's got "02:". 
old=$(ps -o pid,cmd,etime -C postgres | grep "$DB" | egrep '0[23]:') 
if [ -n "$old" ]; then 
    echo "Killing:" 
    echo "$old" 
    echo "$old" | awk '{print $1}' | xargs -I {} kill {} 
fi 
相關問題