Как исправить ошибку запуска?

Question

[Nickolay P]

На сервере было произведено экстренное отключение, после которого перестал запускаться постгрес, в логах мы видели следующее :

postg@postgresql FATAL: the database system is starting up 
LOG: startup process (PID 11760) was terminated by signal 6: Aborted 
postg@postgresql FATAL: the database system is starting up 
LOG: database system is shut down 
invalid primary checkpoint record

В попытках запустить сервер и постгрес, спустя 3-4 ребута постгрес запускается (на данный момент), однако, спустя 2 минуты работы процессор загружается на 100% и сервер перестает отвечать, падает ssh и далее за ним все остальное.

spoiler

Comments

[Nickolay P]

Бекап мы создали после того, как сервер упал в ошибку. Если мы восстановим этот бекап, наш постгрес будет такой же нерабочий, как и сейчас (по логике)?

[mayton2019]

А более старый бекап?

[Nickolay P]

Нет, у нас как раз планировался бекап на завтра-послезавтра (автоматический), но все сложилось так, что актуального в момент бага у нас нет..

Answer 1

[Rsa97]

Восстанавливайте базу из бэкапа. Вы же делали регулярный бэкап?

Answer 2

[Melkij]

Берёте бекап и восстанавливаетесь из него.

Затем внимательно и придирчиво задаёте вопросы софту и железу на предмет где и как продолбали fsync, где ошибка в настройках, нарушающая гарантии durability?

А из повреждённой базы можно попробовать аккуратно достать то что ещё читается и обойти то что чтению уже не подлежит. Разумеется, не под продовой нагрузкой. Долго, дорого.

Answer 3

[Zerg89]

1этап Проверка целостности fs fsck -f -y /dev/sdX
2 этап База просто пытается восстановится из транзакционных логов или восстановится из соседних баз кластера,
чтобы не висло запустите процесс с меньшим приоритетом, чем больше число тем ниже приоритет
systemctl start postgres <b>-nice 20</b>

Comments

[mayton2019]

Да. По внешнему виду идет рекавери но кажется что процесс циклиться и запускает дочерние процессы. Я-бы сказал что база мертва если нет динамики. Сколько ждать? День? Месяц? Нужно иметь какой-то обозримый срок.

[Zerg89]

mayton2019, врятли, судя по скрину процессы работают, cpu и s r-running
Htop -u postgres может показать больше что конкретно процесс пытается делать и нету ли дедлока, может потребоваться запуск с одним дочерним процессом чтобы их избежать
А конкретно сколько времени займёт, даже приблизительно зная возможности железа и объем базы врятли кто-то может расчитать

[Zerg89]

mayton2019, ps целостность fs проверили?

[mayton2019]

Zerg89,

врятли, судя по скрину процессы работают, cpu и s r-running

глядя на top процессов невозможно определить факт зацикливания алгоритма.
Это кстати может быть и редкий баг восстановления БД из WAL который просто
не оттестирован.

[Zerg89]

mayton2019, единственное что могу посоветовать развернуть на виртуалке базу из бекапа и подкинуть ему транзакционные логи для восстановления с минимальной потерей данных

[mayton2019]

Zerg89, это вопрос точняк не для QNA.

Если база для них имеет ценность - пускай подключают платный Postgres support в рф.
Если не очень - то пускай пересоздают заново из скриптов.

Политика бекапов конешно капец-капец... Но такова жисть. Зато теперь знают слабые
места этой политики.

[Zerg89]

mayton2019, ps хд почему-то думал что автору комент пишу)