LINUX.ORG.RU
ФорумAdmin

Postgres получает smart shutdown при старте ОС

 ,


0

2

Добрый день. Длительное время бьюсь с проблемой того, что postgresql не запускается самостоятельно на некоторых серверах. PostgreSQL version: 9.5.7 Operating system: Debian GNU/Linux 8.8 (jessie) Суть: Сервер выключается. При включении postgresql получает получает SIGTERM (smart shutdown) При выключении

2020-04-17 05:25:19 MSK [906]: [4-1] db=,user=,app=,client= LOG:  received fast shutdown request
2020-04-17 05:25:19 MSK [906]: [5-1] db=,user=,app=,client= LOG:  aborting any active transactions
2020-04-17 05:25:19 MSK [1245]: [2-1] db=,user=,app=,client= LOG:  autovacuum launcher shutting down
2020-04-17 05:25:19 MSK [1242]: [173-1] db=,user=,app=,client= LOG:  shutting down
2020-04-17 05:25:20 MSK [1242]: [174-1] db=,user=,app=,client= LOG:  checkpoint starting: shutdown immediate
2020-04-17 05:25:21 MSK [1242]: [175-1] db=,user=,app=,client= LOG:  checkpoint complete: wrote 35 buffers (0.1%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=0.000 s, sync=0.293 s, total=0.634 s; sync files=15, longest=0.043 s, average=0.019 s; distance=10542 kB, estimate=143239 kB
2020-04-17 05:25:21 MSK [1242]: [176-1] db=,user=,app=,client= LOG:  database system is shut down
[/cut]

При последующем старте ОС

2020-04-17 07:55:43 MSK [980]: [3-1] db=,user=,app=,client= LOG:  received smart shutdown request
2020-04-17 07:55:43 MSK [1289]: [1-1] db=,user=,app=,client= LOG:  database system was shut down at 2020-04-17 05:25:20 MSK
2020-04-17 07:55:46 MSK [1289]: [2-1] db=,user=,app=,client= LOG:  MultiXact member wraparound protections are now enabled
2020-04-17 07:55:50 MSK [1457]: [1-1] db=,user=,app=,client= LOG:  shutting down
2020-04-17 07:55:57 MSK [1457]: [2-1] db=,user=,app=,client= LOG:  checkpoint starting: shutdown immediate
2020-04-17 07:55:57 MSK [1457]: [3-1] db=,user=,app=,client= LOG:  checkpoint complete: wrote 0 buffers (0.0%); 0 transaction log file(s) added, 1 removed, 0 recycled; write=0.001 s, sync=0.000 s, total=0.423 s; sync files=0, longest=0.000 s, average=0.000 s; distance=16384 kB, estimate=16384 kB
2020-04-17 07:55:57 MSK [1457]: [4-1] db=,user=,app=,client= LOG:  database system is shut down
[/cut]

После того, как обнаруживается, что postgres не запустился, в ручном режиме все запускается без каких-либо проблем. Да даже, если кто-то пальцем перезапускает сервер, старт происходит корректно.

Единственное, что объединяет - выключение сервера происходит по команде от ИБП раньше был apcupsd

shutdown -h now
теперь nut-monitor
shutdown -h +0

Debian GNU/Linux 8.8 (jessie)

Мне в похожей ситуации помог совет местного anonymous о замене systemd на sysvinit.

Запуск Postgresql 9.4 на Debian 8 после незапланированного отключения (комментарий)

apt-get install -y sysvinit-core

В документации на сайте PostgreSQL есть информация, как правильно его настраивать под systemd. Но разбираться было некогда тогда, а сейчас не найду.

Toxo2 ()
Ответ на: комментарий от Toxo2

Спасибо за совет. Но это относительно большие изменения конфигурации. В проде более 1000 физических серверов типовой конфигурации с systemd. Плюс - само выключение происходит относительно штатно, в отличие того, что Вы описали в своей проблеме. Запуск штатными средствами после обнаружения проблемы происходит без каких-либо проблем.

adramelech ()
Ответ на: комментарий от adramelech

В проде более 1000 физических серверов

Да уж. Немного разный уровень у нас. Извините )

Тем не менее, раз пока соответствующих желающих нет, рискну предложить на тестовой машине изменить в /lib/systemd/system/postgresql@.service в ExecStop или сразу на smart или по мотивам вот этой статьи http://rhaas.blogspot.com/2015/03/postgresql-shutdown.html оставить fast, но предварительно ещё и checkpoint.

(это я попытался гуглом отработать билет в калашный ряд, пардон)

[Добавлено] Проверил на виртуалке с заменой на smart - заработало «вежливое» выключение postgresql, но только после перезагрузки. Забыл про systemctl daemon-reload видимо.

Toxo2 ()
Последнее исправление: Toxo2 (всего исправлений: 2)
Ответ на: комментарий от Toxo2

сразу на smart или оставить fast

я уже перекурил всю документацию по pg_ctl fast - идет по дефолту ), смысла на smart переходить не особо вижу. Пробовал оставить bug report у postgresql - там отмахнулись, что sigterm (smart) при старте приходит из ОС.

Главное проблема, что на стенде воспроизвести проблему не удалось. Как уже я не извращался со способами выключения/перезагрузки. Нештатная перезагрузка (если не возникло проблем с фс) проблему не показывает. Т.е. нажать ресет/ дернуть питание резко/halt/etc - при следующем запуске автостарт происходит нормально

adramelech ()
Ответ на: сразу на smart или оставить fast от adramelech

смысла на smart переходить не особо вижу

Посыл был в том, что всё-таки fast (который по умолчанию в postgres) по какой-то причине некорректно его выключает. Может железо на некоторых серверах слабое и не успевает сделать graceful shutdown. А не успевает - оставляет флаг в кишках postgres, из-за которого это и происходит.

Это просто объяснил логику своих рассуждений. Возможно - фантазия опять.

Toxo2 ()
Ответ на: комментарий от Toxo2

Посыл был в том

Спасибо, я понял в какую сторону Вы смотрите. Но честно, не вижу смысла пробовать подобное не зная причин, или хотя бы получится воспроизвести.

А не успевает - оставляет флаг в кишках postgres, из-за которого это и происходит

Это было самое первое, о чем думал. Но различные варианты проб повторить это не увенчались успехом

-различные варианты жесткой перезагрузки самой машины

-пробовал посылать -9 после попытки выключить в нормальных режимах

adramelech ()
Ответ на: Посыл был в том от adramelech

Последняя фантазия на сегодня.

Если всё-таки отталкиваться от

там отмахнулись, что sigterm (smart) при старте приходит из ОС

Может просто поискать по всей файловой системе вызовы pg_ctl или pg_ctlcluster? Например, обработчики событий от UPS неверно настроены?

Пока больше ничего не придумывается.

Toxo2 ()
Ответ на: комментарий от Toxo2

Виноват, недооценил всю мощь фонтана фантазий )

Еще один вариант:
если исходить, что это NUT при старте посылает SIGTERM всему, что видит, то прописать зависимость postgresql@.service от nut-server.service. Мол, сначала NUT, потом postgres.

Точно помню, что давным-давно имел какое-то приключение с UPS такого толка, что при запуске сервиса вся машина просто сразу уходила в shutdown. Т.е. сам факт того, что сервис может неверно толковать сигналы от UPS - бесспорен. Или в проводах (там был COM-порт), или в протоколе была проблема - не помню.

Кажется теперь точно всё, иссяк.

Toxo2 ()
Ответ на: комментарий от Toxo2

приключение с UPS такого толка

очень быстро словили то, что это пакет, как по мне, не очень адекватно отрабатывает сигнал LB (low battery), там сразу идет команда на выключение. При этом перехода в режим работы от батарейки не было (исправили в конфигах). Такая реакция происходила, когда батарейка была уже в плохом состоянии и требовала замены. Предыдущий пакет apcupsd в этом случае спамил в лог о необходимости замены батареи.

поискать по всей файловой системе вызовы pg_ctl или pg_ctlcluster

В ближайшее время это хочу проверить, возможно получится найти корень зла.

В нашей организации сейчас задумались об изменении набора команд для ИБП (чтобы он сначала тушил необходимые демоны, а потом уже подавал команду на выключение, благо скрипты и конфиги там простые для понимания)

Также есть вариант с подменой/создания «wrapper'a» самого скрипта shutdown с той же целью

adramelech ()