Далее я опишу проблемы, с которыми столкнулся лично и по пунктам как их решал. Далее все про Linux системы. Ребята с Windows, извините, но думаю у вас будет что-то похожее.
Так как Дзен не дает теперь отдельно редактировать описание поста поздороваюсь с вами тут. Здравствуйте, уважаемые подписчики и гости канала!
Вообще, ребята, я искренне надеюсь, что это никому из вас не понадобится, но уверен, что найдутся пара человек, которых это может спасти. Так как тема поста сама по себе стрёмная и связана с полной или частичной неработоспособностью БД или частичной утерей данных я обязан написать про отказ от ответственности.
Минутка рекламы. Подборка видео всех видео по PG - https://dzen.ru/suite/37b67ffa-176d-493a-b1a8-4762f79e3753
Отказ от ответственности
Внимание! Эти решения я принимал на свой страх и риск, далее я постараюсь пояснить как и почему я делал те или иные действия, но решение использовать мой опыт или нет лежит полностью на вас! Вы используете эту информацию на свой страх и риск, автор не несет никакой ответственности за появление неточной или ложной информации, а также за использование вами данных, содержащихся в этой статье либо найденных по ссылкам с них.
Падение Postgres - Нехватка места на диске
Обычно PG работает до упора, а когда диск заполнится на 100%, СУБД больше не может записать ничего на диск и падает. И больше не включается. У нас в каждой инсталляции есть системный диск и диск с данными. Это и позволяло выполнять такую махинацию. Что делать, если у вас один диск с ОС и данными PG я не знаю, может быть просто удаление временных файлов тоже пойдет, я не пробовал.
Далее про то, что делать, если оно упало и у вас два диска:
1. Проверить место на диске (команда: df -h)
Если места нет, то надо или решать вопрос о добавлении места на диск, либо чистить временные файлы и перезапускать. Если решаете вопрос экстенсивно добавлением места, то тут останавливаетесь.
2. Очистка файлов.
Обычно файлы БД лежат в /var/lib/postgresql/[version]/data/
Если вы их там не нашли и не знаете где они лежат, то идете в конфиг PG: /etc/postgresql/[version]/main/postgresql.conf и смотрите параметр "data_directory"
2.1 Находим папку pgsql_tmp. Например: /var/lib/postgresql/[version]/data/base/pgsql_tmp
2.2 Видим в папке гигабайтные файлы с именем типа такого: pgsql_tmp38883.0
⚠️ Внимание! Далее опасная зона! Не делайте подобную махинацию с файлами не из pgsql_tmp
2.3 Останавливаем postgresql
Если БД не под docker-ом, то: service postgresql stop
Если БД под docker-ом, то вам лучше обратится к тому, кто ее запускал на сервере.
2.4 Перемещаем один из временных файлов к себе в home dir (это перемещение на другой диск, чтобы чуть освободить место на диске с данными БД)
2.5 Делаем симлинк на старое место, чтоб PG увидел его
2.6 Запускаем postgresql
Если БД не под докером: service postgresql start
2.7 Убеждаемся, что место на диске стало больше
2.8 Останавливаем postgresql еще раз
2.9 Если симлинка нет, то удаляем временный файл из home dir
2.10 Если симлинк есть, удаляем симлинк и возвращаем файл на место
2.11 Запускаем postgresql
На этом этапе PG должен запуститься и вы сможете почистить место с работающей СУБД.
Итак, что это было?
У нас такое было на 9.5 когда места было не совсем достаточно и в добавок запускалось много параллельных запросов с WITH-ами, которые писали временные файлы на диск. В итоге это приводило к тому, что в какие-то рандомные моменты место просто кончалось, а временных файлов можно быть и на 20 и на 30 ГБ. Когда диск переполнялся PG останавливался и почему-то не стирал временные файлы. По итогу достаточно было чуть чуть освободить диск для БД, чтобы PG запустился и все почистил.
Падение Postgres - unexpected chunk number 0
Ошибка стрёмная и выглядит она так:
Что помогло
Помогла, как ни странно вот такая банальность:
reindex table pg_toast.pg_toast_934615451
Название таблицы или тост-таблицы у вас будет свое.
У ребят из PostgresPRO сохранилась переписка, которая помогла мне решить проблему.
Падение Postgres - invalid page in block
Очень стрёмная тема. Выглядит так: ERROR: invalid page in block 51951 of relation base/135941/3495105329 У вас не проходят некоторые запросы к БД, которые ранее проходили.
Что помогло
1. Ищем на чем именно падает
1.1 select relname from pg_class where relfilenode=3495105329;
relfilenode=3495105329 - это id взят из примера ошибки. В принципе PG вам уже все, что надо сказал, и остается просто выполнить команды.
1.2 получаем имя таблицы
⚠️ Внимание! Далее опасная зона! Внимательно почитайте про zero_damaged_pages перед тем, как принимать такое решение. Эта настройка разрушает поврежденные данные!
2. set zero_damaged_pages=on;
3. vacuum full имя_схемы.имя_таблицы;
4. set zero_damaged_pages=off;
Так же, как и в прошлый раз у ребят из PostgresPRO сохранилась переписка, которая помогла мне решить проблему.
Падение Postgres - the database system is in recovery mode
Эта ошибка может потрепать ваши нервы. Она вызывает что-то вроде ребута БД и ваши пользователи не могут пользоваться ей. У нас это было из-за использования plpython2 , который числится unsafe расширением. При том, что он падуч я очень благодарен, что это расширение существует, так как в свое время оно очень нам помогло.
Что помогло
1. Идем в логи БД - обычно в /var/log/postgresql
2. Ищем строку the database system is in recovery mode
Видим в логах БД: 2020-05-14 09:31:25 MSK [18891-1] myuser@mydb FATAL: the database system is in recovery mode
3. Далее посмотрите логи около лога про "recovery mode". У нас это только из-за segfault. Делаем: cat postgresql-9.5-main.log | grep "Segmentation fault"
4. Находим строку, с которй все началось: 2020-05-14 09:31:14 MSK [61554-107] LOG: server process (PID 6535) was terminated by signal 11: Segmentation fault
5. Ищем по pid процесса: cat postgresql-9.5-main.log | grep '6535'
Находим примерное такое:
2020-05-14 08:52:21 MSK [6535-70] myuser@mydb STATEMENT:
2020-05-14 09:02:19 MSK [6535-71] myuser@mydb ERROR: error fetching next item from iterator
2020-05-14 09:02:19 MSK [6535-72] myuser@mydb DETAIL: plpy.Error: object_name must be not null
2020-05-14 09:02:19 MSK [6535-73] myuser@mydb CONTEXT: Traceback (most recent call last):
2020-05-14 09:02:19 MSK [6535-74] myuser@mydb STATEMENT:
2020-05-14 09:31:14 MSK [61554-107] LOG: server process (PID 6535) was terminated by signal 11: Segmentation fault
6. Далее идем в просмотровщик миднайткомандера или чего-то типа него и по F7 ищем подстроку "plpy.Error: object_name must be not null"
И вот по сути мы видим основную ошибку, функцию, которая ее вызвала и SQL запрос, в котором эта функция вызывается. Запрос я прикладывать не стал - там только его верхушка с SELECT, но суть, надеюсь, ясна.
---
А на этом всё, спасибо за внимание!
Подписывайтесь на канал, ставьте лайки, оставляйте комментарии - это помогает продвижению в Дзене.
Кроме этого:
Подписывайтесь в Telegram: https://t.me/lets_goto_it