как изящно убить устаревший процесс сервера postgres

Question

Иногда в нашей лаборатории наша база данных postgres 8.3 теряется из файла pid, и мы получаем это сообщение при попытке закрыть базу данных:

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

Когда это происходит, мы немедленно делаем pg_dump, чтобы мы могли восстановить базу данных позже. Но если мы просто уничтожим -9 потерянный процесс postgres и затем запустим его, база данных начнет работать только с данными последнего успешного завершения работы. Но если вы psql до того, как его убить, все данные будут доступны, поэтому pg_dump работает.

Есть ли способ изящно завершить потерянный процесс postgres, чтобы нам не пришлось проходить через pg_dump и восстанавливать? Или есть способ восстановить базу данных после уничтожения потерянного процесса?

Answer 1

Согласно документации вы можете отправить SIGTERM или SIGQUIT. SIGTERM является предпочтительным. В любом случае никогда не используйте SIGKILL (как вы знаете из личного опыта).

Изменить: с другой стороны, то, что вы испытываете, не является нормальным и может указывать на неправильную конфигурацию или ошибку Пожалуйста, обратитесь за помощью в список рассылки pgsql-admin .

Answer 2

Никогда использовать kill -9.

И я настоятельно советую вам попытаться выяснить, как именно это происходит. Откуда именно приходит сообщение об ошибке? Это не сообщение об ошибке PostgreSQL. Вы случайно не используете разные способы запуска / остановки сервера (иногда initscripts и pg_ctl, например)? Это может привести к потере синхронизации.

Но чтобы ответить на прямой вопрос - используйте обычное kill (нет -9) в процессе, чтобы выключить его. Убедитесь, что вы уничтожили все процессы postgres, если запущено более одного.

База данных всегда будет выполнять автоматическое восстановление при каждом завершении работы. Это должно произойти и с kill -9 - любые зафиксированные данные должны быть там. Это почти звучит так, будто у вас есть две разные директории данных, смонтированные одна над другой или что-то в этом роде - это было известной проблемой с NFS по крайней мере раньше.

Answer 3

Я использую скрипт, подобный следующему, запускаемый 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