Postgresql - настройка как проблема Upstart

Мне нужно, чтобы Postgresql был настроен для запуска с системой Upstart, потому что я использую события Upstarts для запуска другого приложения, которое зависит от запуска pgsql. Это учебник / скрипт, который я использовал:

http://bradleyayers.blogspot.com/2011/10/upstart-job-for-postgresql-91-on-ubuntu.html [ 113]

Когда я перезагружаю сервер (shutdown -r now), postgresql не запускается (не отображается как задание с помощью команды top). Затем я попытался запустить только следующую команду вручную:

root@server:~# exec su -c "/usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgresql/9.1/main -c config_file=/etc/postgresql/9.1/main/postgresql.conf" postgres

И моя сессия ssh просто отключается, ничего не возвращая. Если я повторно подключусь и снова проверю запущенные задания, pgsql все еще не запущен. Поэтому я попытался выполнить команду без «exec», и вот ответ:

root@server:~# su -c "/usr/lib/postgresql/9.1/bin/postgres -D /var/lib/postgresql/9.1/main -c config_file=/etc/postgresql/9.1/main/postgresql.conf" postgres

2012-12-03 19:31:36 MSK FATAL:  could not create lock file "/var/run/postgresql/.s.PGSQL.5432.lock": No such file or directory

Я предполагаю, что проблема связана с самой postgresql, а не с системой upstart. Я предполагаю, что упомянутый файл должен существовать, чтобы к нему можно было получить доступ, но по какой-то причине этого не происходит. кто-то еще наткнулся на это, или есть потенциальное решение этого?

1
задан 2 February 2014 в 08:05

2 ответа

Ошибка означает, что Postgres не может создать свой файл блокировки в каталоге /var/run/postgresql. Предполагается, что предварительный скрипт создаст его, и он установит право собственности на postgres. Для меня это выглядит так, будто этот скрипт вообще не запускался. Поэтому проверьте вывод start postgres (как суперпользователя), существование и разрешения ls -l /var/run/postgresql.

К вашему сведению: exec полезен в заданиях Upstart, поэтому в разделе script, в котором запущен сценарий оболочки, не остается дополнительного идентификатора PID. В сеансе оболочки он завершает работу вашей оболочки при выходе из исполняемой программы.

0
ответ дан 2 February 2014 в 08:05

У меня было то же требование настроить pg этот путь. Для меня я хотел несколько кластеров, каждого с их собственным независимым планировщиком (pgagent). Когда я закрылся, отдельный кластер pgagent остановится автоматически, но когда я запускаю кластер, я хочу, чтобы pgagent запустился автоматически для того кластера также. Если я забываю запускать планировщик, когда я запускаю кластер, я в беде.

Я Погуглил вокруг, но никогда не находил хорошее решение выполнения PostgreSQL при Выскочке. Большинство решений явно запустило администратора почты вместо того, чтобы использовать команды pg_wrapper. С путем работает Выскочка, это кажется опасным и могло привести к потере данных в редких ситуациях.

Таким образом я вырвался вперед и попытался создать свои собственные Новомодные сценарии, которые сделают задание. Я нашел, что было очень трудно получить корректный PID и кластера и его pgagent экземпляра. В конечном счете однако я понял, что с PostgreSQL, Вы на самом деле не заботитесь о PIDs. Вы заботитесь о версиях и кластерах. После того как я понял, что, все это объединилось, и я создал следующие три сценария:

Первое я называю pg_versions.conf.

description "PostgreSQL Version Controller"
author "Brian Myers"

start on runlevel [2345]
stop on runlevel [016]

env DEFAULT_VERSIONS="9.3"

pre-start script
  if [ -z $VERSIONS ]; then
    VERSIONS=$DEFAULT_VERSIONS
  fi
  for version in $VERSIONS 
  do
    for cluster in $(pg_lsclusters -h | grep $version | cut -d" " -f 2) 
    do
      if [ `tail -1 /etc/postgresql/$version/$cluster/start.conf` = "auto" ]; then
        start pg_cluster version=$version cluster=$cluster
      fi
    done
  done
end script

post-stop script
  if [ -z $VERSIONS ]; then
    VERSIONS=$DEFAULT_VERSIONS
  fi
  for version in $VERSIONS 
  do
    for cluster in $(pg_lsclusters -h | grep $version | cut -d" " -f 2) 
    do
      stop pg_cluster version=$version cluster=$cluster
    done
  done
end script

Затем pg_cluster.conf.

description "PostgreSQL Cluster Controller"
author "Brian Myers"

instance $version-$cluster

pre-start script
  if [ `pg_lsclusters -h | grep $version | grep $cluster | cut -d" " -f 4` = "down" ]; then
    pg_ctlcluster $version $cluster start || :
    start pg_agent version=$version cluster=$cluster || :
  fi
end script

post-stop script
  if [ -e "/var/run/postgresql/pgagent-$version-$cluster.pid" ]; then
    stop pg_agent version=$version cluster=$cluster
  fi
  if [ `pg_lsclusters -h | grep $version | grep $cluster | cut -d" " -f 4` = "online" ]; then
    pg_ctlcluster $version $cluster stop
  fi
end script

И наконец pg_agent.conf.

description "PgAgent Controller"
author "Brian Myers"

instance ${version}-${cluster}

setuid postgres

pre-start script
  PORT=`pg_lsclusters -h | grep $version | grep $cluster | cut -d" " -f 3`
  if [ -z `psql -c "select schema_name FROM information_schema.schemata WHERE schema_name = 'pgagent';" -d postgres -p $PORT | grep pgagent` ]; then
    stop ; exit 0
  fi
  PGAGENTDIR=`which pgagent`
  PGAGENTOPTIONS="host=/var/run/postgresql dbname=postgres user=postgres port=$PORT"
  start-stop-daemon --start --oknodo --name "pga$version$cluster" --exec $PGAGENTDIR -- $PGAGENTOPTIONS
  pgrep -f "$PGAGENTDIR.+$PORT" > /var/run/postgresql/pgagent-$version-$cluster.pid
end script

post-stop script
  start-stop-daemon --stop --oknodo --pidfile /var/run/postgresql/pgagent-$version-$cluster.pid
  if [ -w /var/run/postgresql/pgagent-$version-$cluster.pid ]; then
    rm -f /var/run/postgresql/pgagent-$version-$cluster.pid
  fi
end script

Если Вы хотите больше, чем просто 9,3 версий, просто добавьте версии к env DEFAULT_VERSIONS="9.3" строка разделяется пробелами.

С ними я могу:

Запустите все кластеры не уже выполнение: sudo initctl start pg_versions

Запустите все кластеры для конкретной версии не уже выполнение: sudo initctl start pg_versions version=9.3

Запустите конкретный кластер, автоматически запустив pgagent для того кластера, но только если кластер является включенным pgagent: sudo initctl start pg_cluster version=9.3 cluster=main

Запустите pgagent кластера, если кластер является включенным pgagent: sudo initctl start pg_agent version=9.3 cluster=main

Изменение начинает останавливаться для получения обратного поведения. Конечно, все запускает на начальной загрузке и закрывается на остановке через pg_ctlcluster, так никакая потеря данных. Я действительно должен был отключить init.d сценарии через задницу.

Я уверен, что они могли быть очищены или сделаны еще лучшими способами. pg_agent сценарий, например - я никогда не мог выяснять, почему использование сценария или должностного лица не могло получить корректный PID. В конечном счете я сдался и управлял изодромным с предварением файлом сам, но это - все еще тайна. Это были, вероятно, мои очень мягкие навыки сценариев оболочки.

Обратите внимание также на это, если Вы закрываете кластеры вручную с pg_ctlcluster эти Новомодные задания все еще покажут выполнением даже при том, что связанные версии/кластеры не. Не грандиозное предприятие, потому что можно просто перезапустить их с также pg_ctlcluster или initctl, но по этой причине я предлагаю использовать initctl управлять Вашими кластерами, если Вы развертываете эти задания.

В любом случае они работают вполне хорошо на меня.

2
ответ дан 2 February 2014 в 08:05

Другие вопросы по тегам:

Похожие вопросы: