Аномальный PostgreSQL

Случалось ли с вами что-нибудь странное, необычное? Может быть, вы прибивали бэкенд и потом обнаруживали, что он по-прежнему жив? Или, может быть, autovacuum крохотной таблицы выполнялся бесконечно долго, а все сессии в базе данных внезапно переходили в состояние «idle in transaction»? С подобного рода событиями рано или поздно может столкнуться каждый администратор баз данных. И каждое из них особенное, внешне признаки могут быть схожие, но причины происходящего совершенно разные.

Попробуем рассмотреть, что же есть аномалия, что может являться причиной таких событий, и какие существуют подходы в их диагностике. Для начала дадим определение аномалии. Вот что говорит Википедия:
«Аномáлия — отклонение от нормы, от общей закономерности, неправильность».

Старые версии PostgreSQL
Если вы бородатый DBA с большим опытом, то наверняка сами лично сталкивались с ситуацией, когда hash индексы, созданные на мастере, отсутствовали на репликах. Это было так давно, когда ещё нумерация PostgreSQL имела другой вид, типа 9.xx.xx, где первые две цифры относились к мажорной версии, а третья к минорной. Почему же так происходило? Дело в том, что до 10 версии хеш-индексы не журналировались. А нет WAL-а, нет и репликации. Кто-то вправе возразить, что все детские «болячки» пройдены и вылечены, уже вышла 17 версия PostgreSQL и всё самое страшное позади. Возможно и так. Но давайте посмотрим на современные, поддерживаемые версии PostgreSQL. В качестве примера рассмотрим логическую репликацию. Лишь в самой свежей, 17 версии логические слоты стали реплицироваться. Что это значит? Представьте, что у вас есть работающий мастер, на нём созданы слоты логической репликации, в БД существуют публикации и есть подписчики. В какой-то момент вы принимаете решение, что необходимо выполнить переключение мастера на другую ноду — «promoute» реплики, и с удивлением обнаруживаете, что ваша логическая репликация больше не работает, так как на новом мастере слоты логической репликации отсутствуют. Аномалия ли это? Это больше недоработка, как и hash-Индексы в PostgreSQL 9.xx.xx «Форки».

Почему же нельзя просто так взять и установить самую последнюю, самую свежую версию PostgreSQL? К сожалению, на то множество причин. Одна из них в том, что всё большую популярность набирают различные «форки» PostgreSQL. И если некоторые из них (PostgresPro) уже многим хорошо знакомы, то другие — такие как Pangolin, Tantor, Квант-Гибрид — только набирают популярность в нашей стране. Помимо самих «форков», также набирают популярность и ПАКи (программно-аппаратные комплексы), в которых всё уже установлено, настроено, сконфигурировано и т.д. В таких ПАКах, как правило, репозитории отключены, и возможности DBA сильно ограничены. Зачастую в таких ПАКах стоит далеко не самая свежая версия PostgreSQL (форк), а процесс её обновления долгий и сложный: нужно ждать, когда разработчик ПАКа выпустит обновление продукта. Однако, даже если вам «повезло» и у вас есть полная свобода действий, миграция на более новую мажорную версию СУБД всегда будет сопровождаться рисками и требует тщательного тестирования.

Новые версии PostgreSQL
Если со старыми версиями PostgreSQL всё понятно, то какие нас ждут проблемы в новых версиях? О, здравствуй, дивный новый мир! В качестве примера можно привести проблему «After upgrade of Posgres from version 13.5 to 16.2 we experience following error: could not extend file with FileFallocate(): No space left on device». На первый взгляд, может показаться, что у людей закончилось свободное место на диске или Inodes. Но если копнуть поглубже, то можно узнать, что в 16 версии PostgreSQL произошли изменения, касающиеся оптимизации размещения большого количества пустых страниц на диске при их выделении в памяти. Этот метод был добавлен в коммите 4d330a61bb1969df31f2cebfe1ba9d1d004346d8. До 16 версии PostgreSQL расширял файл, записывая туда нулевые страницы. С 16-ой версии для этого использует fallocate (если такой есть). Это может использоваться, например, для транзакций, генерирующих большой объём данных. В release notes это, скорее всего, описано общими словами, без конкретики по реализации.

Ядро Linux
Думаем, что где-где, а в этом месте меньше всего ожидали «подвоха». В выпуске ядра Linux 6.3, который был опубликован в апреле, выявлена ошибка, приводящая к повреждению метаданных файловой системы XFS. Ознакомиться со статьёй на Хабре можно тут: https://habr.com/ru/news/738472.

Операционные системы
Дополнительные сложности могут создавать операционные системы. Про Astra Linux можно найти немало мемов в сети. Появляются и новые операционные системы. Следует отметить, что они тоже могут создавать немало ограничений в работе СУБД и требуют тонкой настройки.

Расширения
Возможно, вы когда-нибудь задавались вопросом, насколько надёжна СУБД PostgreSQL? Прежде чем отвечать на этот вопрос, предлагаю посмотреть, какую информацию предоставляет Википедия о качестве исходного кода СУБД: https://ru.wikipedia.org/wiki/PostgreSQL.

«Согласно результатам автоматизированного исследования различного ПО на предмет ошибок, проведённого в 2005 году, в исходном коде PostgreSQL было найдено 20 проблемных мест на 775 000 строк исходного кода (в среднем, одна ошибка на 39 000 строк кода) [32]. Для сравнения: MySQL — 97 проблем, одна ошибка на 8 000 строк кода; FreeBSD (целиком) — 306 проблем, одна ошибка на 2 500 строк кода; Linux (только ядро) — 950 проблем, одна ошибка на 800 строк кода».

И несмотря на довольно качественный код, покрытый многочисленными тестами, критические ошибки, связанные с PostgreSQL, всё же можно повстречать на просторах интернета. Если говорить о «ядре» СУБД, то оно очень стабильно и надёжно. Отсюда вытекает тот факт, что по сравнению с проприетарными СУБД (например, Oracle) open source СУБД, которую негласно принято называть «ванильной» «из коробки», очень ограничена в своём функционале. Однако, чем сложнее функционал, чем больше строк кода, тем сложнее система и более вероятен риск получить ошибку. Философия PostgreSQL — достичь идеального «ядра». Отчасти из-за этого после инсталляции PostgreSQL отсутствует, например, пул соединений (типа pgbouncer) «из коробки». При этом PostgreSQL «расширяемый», обладающий богатой экосистемой и многочисленными доступными расширениями.

Расширения бывают разные. Одни из них проверены временем и включены в пакет contrib, другие нет. Также стоит отметить, что некоторые «большие» расширения, такие как pg_stat_statements или pg_stat_kcache «щупают» разделяемую память СУБД, а значит, должны быть прописаны в параметре shared_preload_libraries, и их установка потребует перезагрузки PostgreSQL. И если в самом ядре аномалии довольно редки, то расширения, особенно те, которые прописываются в параметре конфигурации СУБД shared_preload_libraries, могут быть причинами критических ошибок. В качестве примера можно привести ошибку «ERROR: invalid memory alloc request size 12922605294342592712».

Вместо заключения
Заведя разговор об «аномалиях», мы лишь немного приоткрыли завесу. Мир open source прекрасен и многогранен. Описать все возможные вариации и причины аномалий не представляется возможным. Практическую часть, как и вопросы, связанные с диагностикой аномалий, мы оставили открытой, а значит, будет повод встретиться ещё, ознакомиться с различными подходами к решению подобного рода проблем и уже не бояться столкнуться с аномалиями в работающей системе.
https://www.fors.ru/about-company/expertise/3027/

Авторы:
Роман Фролов, главный инженер-программист,         
Дмитрий Раков, руководитель службы внедрения и сопровождения компании Форс