Pg_dump это не только ценный бэкап, но и средство диагностики целостности базыНа этой неделе столкнулись с очень интересной проблемой.
Проявлялось это так:
- 1С практически не шевелится
- Если удалось зайти в 1с, то при совершенно разных операциях получаем ошибки СУБД с разным набором таблиц, которые почти ни о чём не говорят, кроме как что-то пошло не так
- Нагрузка ЦПУ на сервере PostgreSQL под 100%
Запрашиваем список активных сессий на СУБД
select * from pg_stat_activity
И получаем список транзакций. Которые длятся минуты и десятки минут с текстом:
select * from public._scheduledjobs...;
и т.д.
Попытка завершить транзакции средствами СУБД ни к чему не приводит.
Тем временем прод стоит, паника нарастает…
Всё это происходит на PostgresPRO Enterprise с встроенным кластером BiHA.
Система определяет что мастер не отвечает и перекидывает всю нагрузку на другую ноду кластера – всё совершенно корректно, как доктор прописал!
И что мы видим? – Буквально за 10 минут теперь и "новый мастер" так же уходит в нагрузку по ЦПУ в 100%.
Снимаем отладочную информацию со всех процессов мастера и «нового» мастера командой
kill <pid> -40
для ТехпПоддержки PostgresPro.
И хоть я и очень не люблю так делать, но аварийно останавливаем PostgreSQL через
kill <pid> -9
и на мастере и на «новом» мастере.
Блокируем 1С.
Стартуем PostgreSQL.
И для быстрой диагностики запускаем
vacuum analyze only в несколько потоков на базе.
И опять получаем «зависшие» транзакции analyze на разных scheduledjobs…
Поясню – analyze читает не все данные в таблице, а только
количество строк = 300*default_statistic_target. Обычно default_statistic_target = 100, т.е. мы читаем только 30 000 строк в таблице, и даже при этом уже получаем зависание системы.
Вот это уже страшно… Опять снимаем crash_info, рестартуем службу Postgres и начинаем расстраиваться…
Всё больше подозрений на битые страницы данных…
И тут встаёт вопрос, как быстро проверить все данные в базе?
Ответ –
pg_dump, ведь по сути это select * по всем таблицам базы и сбор информации о DDL схемах как самих таблиц, так и индексов.
Но, база не маленькая и дамп будет формироваться достаточно долго…
Вспоминаем что можно вместо сохранения дампа на диск отправить его в «чёрную дыру»
/dev/null, но при этом сохранив логи самого процесса дампа.
pg_dump -h 127.0.0.1 -p 5432 -U postgres -d ERP> /dev/null 2> dump.log
Такой дамп формируется намного быстрее.
Запускаем и получаем в логе сообщение:
pg_dump: ошибка: ошибка при выполнении запроса:
ERROR: index "pg_attribute_relid_attnum_index" contains unexpected zero page at block 2349
ПОДСКАЗКА: Please REINDEX it.Вот это поворот! Что-то не так с данными системной таблицы атрибутов..
Ну чтож, есть подсказка, давайте ей и воспользуемся:
REINDEX TABLE pg_catalog.pg_attribute;
И после этого опять запускаем analyze, чтобы проверить починилось ли и да, база починилась, analyze прошёл.
Запускаем 1С – проверяем, всё работает.
Запускаем пользователей и естественно у них «такая же нога, но болит!..», а именно, при различных операциях получаем ошибку СУБД с текстом:
ERROR: heap tid from tuple … offset 204 of block 4 in index “pg_namespace_nspname_index”…
Запускаем
REINDEX INDEX pg_namespace_nspname_index;
- ошибка ушла.
Причина по которой разрушились системные индексы пока ещё выясняется.
❗️Сама история говорит о том, что базу надо периодически регламентно проверять на целостность, а лучше не базу, а весь кластер командой:
pg_dumpall -h 127.0.0.1 -p 5432 -U postgres > /dev/null 2> dump.logПри этом лог будет пустой, если дамп не обнаружит ошибок.
Если же хочется иметь лог всей работы дампа в любом случае, то команда будет такой:
pg_dumpall -h 127.0.0.1 -p 5432 -U postgres -v > /dev/null 2> dump.log
Ну и на всякий случай канал в MAX
https://max.ru/explorer1c 
