在我们的实验室中,我们的postgres 8.3数据库偶尔会从pid文件中孤立出来,当我们试图关闭数据库时,我们会收到以下消息:
Error: pid file is invalid, please manually kill the stale server process postgres
当发生这种情况时,我们立即执行pg_dump,以便稍后恢复数据库。但是,如果我们只是杀死孤立的-9 \f25 postgres -9进程,然后启动它,数据库将只启动上次成功关闭的数据。但是如果你在杀死它之前通过psql连接到它,那么所有的数据都是可用的,这就是pg_dump工作的原因。
有没有一种方法可以优雅地关闭孤立的postgres进程,这样我们就不需要经历pg_dump和恢复了?或者,有没有一种方法可以在终止孤立进程后恢复数据库?
发布于 2009-05-28 14:05:10
根据documentation,你可以发送SIGTERM或SIGQUIT。最好使用SIGTERM。无论哪种方式,都不要使用SIGKILL (正如您从个人经验中了解的那样)。
编辑:另一方面,您遇到的情况是不正常的,可能表明错误配置或bug。请在pgsql-admin邮件列表中寻求帮助。
发布于 2009-05-28 15:10:17
从不使用 -9。
我强烈建议你试着弄清楚这到底是如何发生的。错误消息的确切来源是什么?这不是PostgreSQL错误消息。您是否碰巧混合了不同的启动/停止服务器的方法(例如,有时是初始化脚本,有时是pg_ctl )?这可能会导致事情变得不同步。
但要回答直接的问题-在进程上使用常规kill (no -9)来关闭它。如果有多个postgres进程在运行,请确保杀死所有postgres进程。
每当数据库关闭时,它都会自动执行恢复。kill -9也会发生这种情况--任何提交的数据都应该在上面。这听起来几乎就像你有两个不同的数据目录安装在彼此的顶部或类似的东西-这至少在以前是NFS的一个已知问题。
发布于 2012-01-26 14:51:10
我使用如下脚本,由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 {}
fihttps://stackoverflow.com/questions/920956
复制相似问题