Как известно, админы делятся на три категории: тех, кто бэкапы не делает; тех, кто уже делает, и тех, кто уже проверяет их на консистентность. В ходе нашей истории админы заказчика перешли из второй категории в третью.

Все началось с того, что сервер статистики контактного центра заказчика (на тот момент ещё потенциального) сбросил все пользовательские сессии и перестал отвечать на запросы. Соответственно к нему подкатили тележку с монитором и перезагрузили. Это обычно надо делать раз в 90 дней по инструкции от вендора, но тут это не делалось больше 500 дней. В общем, сервер отметил юбилей аптайма.

Дальше быстро выяснилось, что на рестарте посыпалась база и пропали конфиги. Но главное, что сервер стартанул, бэкапы куда-то писались. Всё хорошо, железо работает, диски в порядке, надо просто накатить бэкап.

Но после накатывания бэкапа система просто легла.

В этот момент нас позвали отмечать день рождения сервера. Без него не работала балансировка нагрузки на операторов внутри КЦ.

Что это была за система?

Система Avaya Call Management System (CMS). Это кусок колл-центра, который собирает статистику по звонкам, операторам, нагрузке исторические и реал-тайм данные. На этом же сервере каждое утро собираются отчёты о работе. В реальном времени сервер говорит, какие операторы сейчас в каких статусах находятся, какие звонки обрабатываются, сколько звонков висит в очереди. В целом система нужна, чтобы следить за группами операторов, за колл-центром, чтобы правильно распределять нагрузку, потому что можно переносить операторов из ненагруженных линий в нагруженные и так далее. Обычно там просто сидят супервизоры и следят за всем происходящим. Прямых аналогов нет, обычно используются самописные решения или же всё вообще делается вручную. Аваевскую систему выбирают за надёжность и многофункциональность.

Если этот сервак отваливается, то в первую очередь нарушается работа по распределению нагрузки на операторов. Возникают простаивающие агенты в одних сегментах и перегрузки в других, то есть сервер выступает в архитектуре в роли балансировщика. Правда, ручного, потому что управляют им супервизоры.

Сбои со статистикой ведут к тому, что маркетологи не знают, как идут рекламные кампании, и это означает, что они сидят в неизвестности.

Первый день пятница

Ситуация абсолютно обычная. У кого-то что-то упало, нам никто деталей не сказал, но надо срочно. Это норма во всех странах, детали появляются потом, когда есть время их искать и рассказывать. На тот момент предполагалось, что мы, может быть, что-то придумаем и мгновенно спасём контакт-центр.

Приезжаем на место (напомню, что сервер лёг и удалённого доступа нет), подключаемся с монитором и клавиатурой, ещё раз смотрим, как система не стартует.

Я подключился не сразу. Когда подключился увидел, что диск переполнился ошибками из-за проблем бэкапа. Некоторые сервисы не стартовали почистили логи, стартовали руками.

У нас условно есть три части системы: железный сервер, который входит в ПАК, поставляемый сразу с софтом в виде чёрного ящика от вендора, CMS и база данных. Бэкапы CMS (конфигураций) и базы делаются в разные места.

ОК, система запустилась, но только база пустая данных никаких нет.

Уже дальше мы узнали и историю про юбилей, и про рестарт, и про всё остальное. Вообще-то для серверов такого класса нормально работать месяцами и годами без перерыва, но у Аваи есть регламент. Там в зависимости от нагрузки системы перезагрузка делается раз в 90 или раз в 180 дней. Очевидно, что регламент пять-шесть раз уже не соблюли. Это тоже нормально, до этого места инструкции дочитывают далеко не все, а если дочитывают, то считают, что это перестраховка вендора. Потому что это и есть перестраховка вендора.

Итак, у нас на руках железный оракловский сервер, с которым что-то не то (но это не посыпавшийся раньше времени диск), на нём Solaris c базjq Informix от IBM + пакет CMS от вендора. Решение продаётся как программно-аппаратный комплекс, то есть всё там как поставил вендор, так никто и не трогал.

Бэкапы БД делались. Итерации были по 180 дней, бэкапирование настроено в планировщике системы. Логи бэкапов никто особо не читал, консистентность не проверяли, назад до этого юбилея сервака накатывать не пытались.

Складировались бэкапы прямо на этот же сервер.

То есть сначала уронили рестартом систему, ребутнули с тележки и поставили бэкап системы CMS, который уронил окончательно железный сервак. Мы починили сервак, но там не было вообще никаких полезных данных. Предстояли интересные выходные.

Дальнейшее исследование

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

К утру мы всё ещё думали, что справимся быстро (в КЦ уже начались проблемы). Решили не трогать бренную земную оболочку сервера, а сразу снять с него образ и развернуть на виртуалке. Это стандартная процедура и для форензики, и для восстановления чего-то, где может посыпаться дальше диск, и вообще очень удобно в конечном итоге в плане не навреди ещё.

Сначала мы развернули виртуалку на стенде прямо у заказчика и начали препарировать там. Фактически Авая сделала больше, чем должна была, подарив лицензию на виртуальную систему. Ну, точнее, заказчику. Выяснили, что бэкап встаёт с ошибкой устройства, но в остальном норм, правда, система пустая. Довольно быстро стало понятно, что бэкап битый полностью.

Чуть позже уже переехали на стенд нашей офисной лаборатории, где была чистая виртуальная машина плюс сами бэкапы системы целиком и базы отдельно.

Откатили виртуалку из снапшота на начальное состояние (до бэкапа системы) и пробуем использовать только бэкап базы. Он восстанавливается удачно, но там нет данных.

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

В лаборатории

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

Сразу стало понятно, что свежий бэкап неконсистентен и вообще похож на записанный прямо из /dev/random. То есть последний месяц (который не бэкапился) пропал просто в силу того, что его никто никуда не резервировал. Следующие полгода пропали из-за битого бэкапа. И только в следующей итерации нашлись таблицы, где были реальные данные. То есть минус семь месяцев от момента аварии, и, как позже выяснилось, целых данных там было не очень много, не больше года, а часто по некоторым показателям и меньше.

Вручную с таблицы перенесли данные в базу данных и скормили всё это нашей виртуалке.

То есть в итоге оставили систему в рабочем режиме со старыми данными, руками настраиваем всё то, что не удалось восстановить из бэкапа системы (пользовательские учётки, коннекторы к другим системам, скрипты).

Там, собственно, и стало понятно, что колл-центр как-то будет учиться обходиться без статистики за периоды. А это довольно больно: они не смогут проводить ретроспективы, делать поквартальное сравнение, использовать исторические данные для прогнозирования смен и так далее. Вся система поощрений операторов тоже была завязана на статистику на этом сервере, то есть заказчик как-то выплатил премии, разбирая потом технические логи самих соединений и записи других систем, но было довольно сложно и неприятно.

Дальше мы занялись тем, что из убитой базы данных с частично сохранившейся информацией делали подходящую для работы этого КЦ. По факту пришлось вбивать руками тысячи операторов, групп и их навыков. Причём за выходные. В понедельник система заработала в достаточной степени, чтобы гладко писать статистику дальше и делать ежедневные отчёты, но с историческими данными ничего больше придумать не вышло.

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

Выводы

История на самом деле печальная: да, мы частично восстановили систему (вендор был готов в рамках своих сервисных соглашений только поднять с нуля чистую систему). Да, запустили колл-центр в понедельник со сбором статистики очень оперативно (по меркам проблемы).

Выводы достаточно очевидные: запишите где-нибудь процедуры обслуживания серверов, чтобы их не пропустили, раз. И проверяйте бэкапы два. Если у вас есть что-то критичное или держите это в виртуальной среде, или имейте второе железное решение для бесшовных перезагрузок (ну или готовьтесь к простою). Складируйте бэкапы не на сам сервер, который надо бэкапить. Имейте партнёра со SLA на такие поломки ну или хотя бы просто проверенные контакты, потому что, когда что-то падает, обычно надо решать сразу. Повезло, что это было перед выходными и что на выходных КЦ под минимальной нагрузкой.

Дальше у заказчика уже несколько месяцев работает виртуалка вместо ПАКа. Мы поддерживаем и эту систему, поэтому бэкапы сейчас делаются правильно. И есть где их проверять на тестовых стендах.

Инструкция по диагностике проблем в работе баз данных в случае аварии.

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

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

Чтобы в следующий раз диагностика и устранение причин аварии происходили быстрее, мы совместно с DevOps-инженером Алексеем Поповым решили написать план эвакуации при пожаре: пошаговую инструкцию, которую можно было бы использовать для быстрого исследования инцидента.

Последняя проблема касалась работы базы данных и взаимодействия web-приложения с базой. Поэтому инструкция касается диагностики именно базы данных. Также хочу отметить, что эта схема не истина в последней инстанции, а всего лишь наш опыт, перенесенный на бумагу. Мы намеренно не стали включать слишком экзотические причины аварии, поскольку схема становится слишком громоздкой и нечитаемой.

Я буду признателен за комментарии и описания аналогичных проблем, которые происходили у вас.

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

Ниже я распишу каждый шаг схемы и инструментарий, применяемый нами для каждого шага.

Шаг 1. Проверка нагрузки ядер процессоров на сервере БД (Load Average)

В большинстве случаев внешним проявлением проблемы в работе базы данных является возросшая нагрузка на ядра процессоров сервера БД. Лучшей метрикой для диагностирования этого факта я считаю LOAD AVERAGE. При этом мне больше нравится эта метрика в пересчете на ядро процессора сервера БД. LA (Load Average) на ядро более 1 плохо. Это значит, что запрос к БД ожидает какое-то время, прежде чем выполниться.

Для отслеживания этой метрики мы применяем систему мониторинга Zabbix с возможностью настройки оповещений в различные каналы. Пример такой метрики при возникновении аварии:

Шаг 2. Нагрузка на ядро процессора (LA) изменилась более чем на 30 % по отношению к тому же времени того же дня недели?

При возникновении серьёзной аварии LA обычно растёт лавинообразно. Тем не менее, даже повышение на 30 % признак какой-то аномалии. Если рост LA заметен и превышает заданный лимит, то самое время перейти к шагу 3 и проверить количество подключений к базе данных. Если же роста LA нет, то лучше переходить к шагу 27.

ШАГ 3. Проверка количества подключений приложений к БД и динамика его роста

Это ещё один маркер, который даёт чёткое понимание, что с БД что-то пошло не так. Тут в большей степени интересна динамика роста количества подключений к базе.

В качестве инструмента мониторинга используем всё тот же Zabbix. Максимально разрешенное количество подключений к БД можно узнать, выполнив команду SHOW_MAX_CONNECTIONS.

Шаг 4.Количество подключений к БД резко выросло за короткий промежуток времени?

Скорее всего, вы заметите, что количество подключений либо резко возросло, либо постепенно росло, уперлось в лимит и стало ровным. В зависимости от этого нужно переходить либо к шагу 7, либо к шагу 5.

Шаг 5. Увеличить количество подключений, поставив пулер подключений

Если вы видите, что количество подключений драматически не изменялось, а постепенно росло и достигло разрешенного лимита, то дело, скорее всего, в том, что нагрузка на БД превысила лимит и запросы стоят в очереди, ожидая освобождения подключения. Быстрое решение в этом случае увеличить количество подключений. Это можно сделать в конфиге базы данных с помощью атрибута MAX_CONNECTIONS. Не стоит этим увлекаться, потому что большое количество подключений это не нормально. Такую меру нужно применять в качестве экстренного лекарства, чтобы выиграть некоторое время для дальнейшего изучения проблемы.

Обращаю внимание, что если у вашей БД есть одна или несколько реплик (не дай бог еще и каскадных), то в первую очередь необходимо поменять количество подключений на этих репликах, причем начиная с последней в каскаде. И только потом на мастере.

Если же приложение работает всё-таки оптимально, то стоит задуматься над использованием пулера подключений (самый распространенный PGBouncer). Этот сервис берёт на себя управление подключениями и делает это достаточно эффективно. Приложение для взаимодействия с БД будет обращаться к PGBouncer, а тот в свою очередь будет перенаправлять запрос к БД через свои подключения. Подробнее об этой технологии можно почитать тут: http://personeltest.ru/aways/habr.com/ru/company/okmeter/blog/420429/.

Я также встречался с ситуацией, когда пулер подключений (PGBouncer) был установлен, но в его работе возникали проблемы. Стоит обратить внимание на лимит подключений к БД в самом пулере. Также у PGBouncer (не знаю, как в аналогах) есть одна особенность реализации: при установлении подключения к БД открывается файловый дескриптор. Поэтому на нагруженных крупных экосистемах с большим количеством сервисов и баз, использующих централизованный PGBouncer, может возникнуть проблема с ограничением числа одновременно открытых файловых дескрипторов на уровне операционной системы

Шаг 7. Проверка наличия блокировок и запросов в ожидании в базе данных

Это одна из частых причин замедления работы БД. Зачастую при крупных миграциях может возникнуть длительная блокировка нескольких строк в таблицах базы данных. В результате запросы, которые обращаются к этим строкам, не могут выполниться и остаются в ожидании (занимая при этом подключение). Через непродолжительное время большая часть подключений может оказаться занятой, и уже все запросы (даже те, которые не затрагивают заблокированные строки) начинают томиться в ожидании.

Способ проверки этой гипотезы динамика с количеством запросом к БД в статусе "IDLE IN TRANSACTION". Мы используем механизм периодического замера количества запросов в этом статусе, с выводом соответствующего графика в Grafana.

Шаг 8. В БД много блокировок и запросов в ожидании

Если ответ на этот вопрос да, то мы уже на полпути к решению. Отправляемся пробовать быстрое решение (шаг 9). Если же большого количества блокировок (повторяюсь большого количества! Блокировки это нормально, если их стандартное количество) и запросов В ожидании не наблюдается, то переходим к шагу 11.

ШАГ 9. Убить все блокировки в БД

Иногда такая мера приводит к быстрой победе. Если, к примеру, транзакция, в ходе которой открыт запрос, была инициирована сервисом, в работе которого возникла проблема, и при этом сервис уже был перегружен/переразвёрнут, то может помочь простое устранение блокировок.

Сделать это можно устранив процесс, вызвавший блокировку pg_terminate_backend(pid);.

Шаг 10. Ситуация исправилась?

Итак, мы устранили все блокировки в базе данных. Через несколько минут ситуация может прийти в норму. Тогда мы молодцы. Или не прийти тогда переходим к шагу 37.

Шаг 11. Получение списка выполняемых запросов, отсортированных по частоте и стоимости

Для этого необходимо выполнить команду PG_STAT_STAEMENTS. При вызове этой утилиты мы соберём журнал всех выполняемых в БД запросов и сможем оценить, какие из них на текущий момент времени занимают больше всего ресурсов (по частоте и стоимости выполнения). Рекомендуется сбросить ранее накопленную статистику командой PG_STAT_STAEMENTS_RESET () и начать её собирать заново, уже во время инцидента. Таким образом мы получим чистую статистику со стоимостью запросов уже на этапе инцидента.

Шаг 12. Изучить SlowLog (запросы, которые выполняются дольше критичного времени)

Эта операция, возможно, сразу даст ответ, какие запросы нужно оптимизировать, без более трудоемкого анализа результатов PG_STAT_STATEMENTS. Обычно мы оба шага (11 и 12) выполняем параллельно, чтобы сразу получить представление о нагрузке на БД. Еще один плюс SlowLog получив выборку из него за более длительный период времени, мы сможем вычленить запросы, которых раньше не было (т. е. они выполнялись быстро), но в какой-то момент стали выполняться медленно, скорее всего из-за аварии.

Шаг 13. Есть дорогие запросы, которые ранее выполнялись быстро?

На этом шаге главной проблемой является определение, с какой скоростью выполнялись запросы ранее (до аварии). Утилиты SlowLog и PG_STAT_STATEMENTS дадут понимание о скорости выполнения запросов сейчас. Но чтобы найти проблемный запрос, нужно понимать, с какой скоростью запросы выполнялись ранее. Для этой цели я рекомендую использовать дополнительные утилиты PGHero или NewRelic. Это достаточно удобные инструменты, которые позволяют понять динамику скорости выполнения запросов.

Если видна деградация в скорости выполнения каких-то определенных запросов, то переходим к шагу 14. Если зафиксировать снижение скорости выполнения какого-то запроса не удалось, то переходим к шагу 30.

Шаг 14. Проверка плана по дорогим запросам

Если вам удалось выделить конкретный запрос с ярко выраженной негативной динамикой скорости выполнения, то следующий шаг детальный анализ запроса посредством утилиты EXPLAIN ANALYZE. Подробно о том, как работает эта команда и как интерпретировать результаты её выполнения, можно ознакомиться тут: https://thoughtbot.com/blog/reading-an-explain-analyze-query-plan.

Шаг 15. Требуется новый индекс?

Исходя из анализа результатов выполнения командыEXPLAIN ANALIZE можно сделать вывод о том, нужен ли новый индекс, или достаточно существующих. Если новый индекс нужен, то добро пожаловать на шаг 29. Если индексов достаточно переходим к шагу 16.

Шаг 16. Индекс есть, но не используется (а раньше использовался)

Такая ситуация может возникнуть в любой момент. При выборе способа обработки данных планировщик запросов опирается на накопленную статистику содержимого таблиц в базе данных. И в какой-то момент времени статистика может начать давать неверные результаты, и тогда планировщик решит не использовать индекс, хотя по-хорошему он должен был бы использоваться. Это также может случиться после крупных миграций данных или при превышении какого-то объёма данных в таблице, при котором планировщик сделает выбор в пользу последовательного перебора вместо использования индекса.

В любом случае, если вы видите, что индекс создан и есть, но при этом EXPLAIN ANALYZE говорит о том, что он не используется, то переходим к шагу 17. Если же индекс используется переходим к шагу 20.

ШАГ 17. Обновление статистики таблиц базы данных

Простая операция, которая может спасти положение. Для сбора статистики большей точности достаточно выполнить команду ANALYZE илиset default_statistics_target = 500; ANALYZE . 500 это количественный коэффициент образца таблицы, который PostgreSQL выбирает для расчёта статистики. Подробнее о механизме работы статистики и карт видимости можно почитать тут: https://postgrespro.ru/docs/postgrespro/10/routine-vacuuming.

Шаг 18. Ситуация исправилась?

Если после обновления статистики содержимого таблиц скорость выполнения запросов нормализовалась ура-ура, мы молодцы. Если проблема наблюдается по-прежнему переходим к шагу 19.

Шаг 19. Пересоздание индекса

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

Пересоздаем индекс. Сделать это можно командой REINDEX (подробнее читайте тут: https://postgrespro.ru/docs/postgrespro/9.5/sql-reindex).

Переходим к шагу 31.

Шаг 20. Профиль работы с кешем (Hit/Miss)

Запрос вдруг неожиданно начал тормозить, но при этом индекс используется. Следующий шаг проверить работу кеша базы данных. Для этого лучше всего подойдёт метрика Hit/Miss количества записей, полученных запросом из кеша или выбираемых из базы данных с нуля. Мы для этих целей используем Zabbix.

Если вы по аналогичной метрике делаете вывод, что профиль работы с кешем изменился, то переходим к шагу 21. Иначе нас ждёт шаг 22.

Шаг 21. Расширить размер буфера БД

Эта мера даст нам какое-то время, но только том в случае, если можно расшириться на значительный объём. По сути, мы какую-то часть данных БД перегоним в кеш, что ускорит доступ к этим данным. Расширение размера буфера кеша БД определяется параметром shared_buffers в конфиге базы.

Будьте внимательны: расширение размера буфера кеша потребует перезагрузки БД. Впрочем, если у вас и так всё безбожно тормозит, это не должно стать большой проблемой.

Шаг 22. Изменились параметры запроса?

Иногда может быть так, что скорость выполнения запроса снижается изза дополнительных параметров, которые выступают в качестве условия выборки данных. Например, если в роли фильтра выступал какой-то атрибут, идентификаторы которого перечислялись в предикате запроса (where atribut_id in (id1, id2, id3)), и какой-то момент вместо 23 идентификаторов стали передаваться несколько сотен, то очевидно, что скорость выполнения запросов упадёт. Возможно, понадобится создание нового индекса, который учитывал бы такой вариант выборки данных. Такое может случиться после очередного релиза смежной системы, читающей данные из вашего сервиса.

Чтобы идентифицировать подобную ситуацию, достаточно вытащить из логов аналогичный запрос, который был несколько дней назад, и сравнить его с таким же запросом сейчас. Обычно разницу в драматическом количестве параметров запроса видно сразу.Если вы нашли такую ситуацию переходим к шагу 26. Иначе к шагу 23.

Шаг 23. Изменилось ли количество и размер временных файлов?

В процессе выполнения запроса база данных генерирует временные данные, используемые для получения данных в нужном формате. Обычно для этого используется оперативная память, объём которой определяется параметром Work_Mem, настраиваемым в конфигурации базы данных. Если этой памяти недостаточно, база данных может создавать временный файлы, в которые записываются промежуточные данные для выполнения запроса. Для определения такой ситуации мы используем метрику по количеству временных файлов от всё того же Zabbix.

Если вы увидели, что количество временных файлов, создаваемых базой данных, резко выросло, то переходим к шагу 25. Иначе к шагу 24.

Шаг 24. Пересоздать индекс

Пересоздаём индекс. Сделать это можно командой REINDEX (подробнее можно почитать тут: https://postgrespro.ru/docs/postgrespro/9.5/sql-reindex).

Переходим к шагу 31.

Шаг 25. Увеличить размер Work_mem, либо оптимизировать запрос на стороне приложения

Если вы увидели, что количество создаваемых временных файлов резко увеличилось, тот в качестве быстрого (но опасного!) решения можно попробовать увеличить размер доступной памяти для обработки временных данных. Управляет этим атрибут Work_mem, настраиваемый в конфигурации базы данных.

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

Переходим к шагу 31.

Шаг 26. Создать новый индекс с учётом новых входных параметров

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

Шаг 27. Создать новый индекс с учётом новых входных параметров запроса

Тут всё понятно: запрос идентифицирован, новый набор атрибутов также понятен создаём новый индекс. При этом рекомендую обновить статистику таблиц, чтобы новый индекс сразу начал применяться планировщиком запросов. Далее переходим к шагу 31.

Шаг 28. Исправление самого запроса на стороне приложения, исключение новых параметров

Вероятно, в ряде случаев проще и быстрее будет сразу же оптимизировать запрос на стороне приложения (либо откатить изменения, приведшие к изменению параметров запроса). Переходим к шагу 31.

Шаг 29. Создать новый индекс

В том случае, если по результатам EXPLAIN ANALYZE пришло понимание, что базе нужен новый индекс, то проще всего его досоздать. Это можно сделать командой CREATE INDEX с указанием параметра CONCURRENTLYдля неблокирующего построения (подробнее можно почитать тут: https://postgrespro.ru/docs/postgresql/11/sql-createindex). Далее переходим к шагу 31.

Шаг 30. Проверка влияния дополнительных факторов (взаимодействие с жёстким диском, сторонние процессы на сервере, работа других БД)

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

• работа жёстких дисков/систем хранения данных;

• нагруженные запросы на другие базы данных, находящиеся на том же сервере что и ваша;

• сторонние процессы, выполняемые на сервере БД (например, работа антивируса);

• создание репликационных баз данных, в процессе чего происходит создание слепка данных с вашего мастера;

• сетевые проблемы и потери при взаимодействии приложения и базы данных.

Если таковые факторы найдены, то постарайтесь их устранить и переходите к шагу 31.

Шаг 31. Ситуация исправилась?

Ситуация стабилизировалась и проблема решена? Мы молодцы! В противном случае пора собирать всю королевскую рать и обращаться к DB-администратору.

Шаг 32. В БД много блокировок и запросов в ожидании?

По аналогии с Шагом 8 - проверяем динамику количества запросов к БД в статусе "IDLE IN TRANSACTION". Мы используем механизм периодического замера количества запросов в этом статусе, с выводом соответствующего графика в Grafana. Подчеркну, что блокировки нормальное явление, они периодически будут возникать. Но вот если у вас произошло резкое увеличение количества блокировок, то переходите к шагу 37. Если же диагностировать увеличение количества блокировок и запросов в ожидании не удалось, то переходите к шагу 33.

Шаг 33. Проверка логов PG Bouncer и логов приложений при подключении к PG Bouncer

Иногда приложение обращается к базе данных не напрямую, а через специализированный пулер подключений (самый распространенный PGBouncer). Но помимо многочисленных преимуществ он всё-таки представляет собой ещё одну точку отказа. Поэтому если в базе данных не наблюдается повышенного LA, а блокировок и запросов в ожидании нет, то рекомендуется посмотреть внимательно на журналы пулера подключений и приложения, которое к нему подключается. Переходим к шагу 34.

Шаг 34. Есть проблемы с PGBouncer?

Если в журналах есть ошибки, то рекомендуется перейти к шагу 35. Иначе переходим к шагу 36.

Шаг 35. Исправление проблемы с работой PGBouncer/подключение приложения напрямую к БД, в обход PGBouncer

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

Это временная мера для быстрого восстановления доступности сервиса. Это не решение проблемы!

Переходим к шагу 31.

Шаг 36. Требуется консультация аналитика

Если вы дошли до этого пункта, то это означает, что случай нетипичный, и для устранения поломки нужно привлечь узкопрофильного специалиста Database analyst. Рекомендую для быстрого погружения в проблему транслировать ему сразу же все журналы и метрики, которые вы изучали на пути к этому пункту.

Шаг 37. Было ли недавнее изменение схемы данных БД?

Ситуация, когда неожиданно, без объявления войны в базе данных растёт аномальное количество блокировок и запросов в ожидании, крайне редка. Чаще всего это следствие релиза или миграции с изменением схемы данных БД. Если такое было в последнее время, то переходим к шагу 45. Если изменений в схеме данных не было, то переходим к шагу 38.

Шаг 38. Проверка журналов БД (или PG_STAT_ACTIVITY) для выявления запроса, вызвавшего блокировку

Блокировки инициируются какими-то запросами. Поэтому следующим шагом важно определить запрос, при выполнении которого возникли самые частые блокировки. Сделать это можно на основе журналов БД либо при помощи утилиты PG_STAT_ACTIVITY.

Шаг 39. Выявление сервисаинициатора запроса, вызвавшего блокировку

После того, как мы выявили запрос, вызвавший блокировку, надо определить сервис или приложение, которое инициировало этот запрос. Проще всего это сделать на основе журналов БД.

Шаг 40. Сервис, инициировавший запрос, работает штатно?

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

Необходимо проверить приложение, инициировавшее запросы, которые приводят к блокировкам. Если проблемы в работе сервиса, инициировавшего блокирующий запрос, найдены, то переходим к шагу 43. Иначе добро пожаловать на шаг 41.

Шаг 41. Были ли недавно релизы сервиса, инициировавшего блокирующий запрос?

Если релизы сервиса, который инициирует блокирующие запросы, совпадают по времени с началом проблемы в БД, то неплохой мыслью будет откатить последний релиз. Это может помочь (переходим к шагу 43).

Если релизов не было, то переходим к шагу 44.

Шаг 42. Диагностика и починка сервиса, инициировавшего блокирующие запросы

Мы определили, что запросы, вызывающие блокировки, генерирует сервис, в котором на данный момент также возникли проблемы в работе. Гипотеза состоит в том, что ошибки в работе сервиса приводят и к ошибкам в работе БД. Целесообразно будет откатить последний релиз (если он был) или сосредоточиться на починке этого сервиса. Если мы приведем сервис в нормальное состояние, то, вероятно, и база данных начнёт работать в соответствии с ожиданиями.

После починки сервиса переходим к шагу 31.

Шаг 43. Откат последнего релиза

Для ускорения решения проблемы проще всего откатить последний релиз сервиса, инициирующего проблемные запросы. В этом случае мы сразу увидим, исчезла проблема или нет. После этой операции переходим к шагу 31.

Шаг 44. Требуется консультация аналитика

Если вы дошли до этого пункта, то это означает, что случай нетипичный, и для устранения поломки нужно привлечь узкопрофильного специалиста Database analyst. Рекомендую для быстрого погружения в проблему транслировать ему сразу же все журналы и метрики, которые вы изучали на пути к этому пункту.

Шаг 45. Откатить миграцию возможно?

Мы выяснили, что в проблемной базе данных недавно был релиз, изменивший схему данных. Быстрее и проще всего откатить миграцию изменения схемы. Если это возможно, то переходим к шагу 46. Если невозможно к шагу 47.

Шаг 46. Откатить миграцию

Необходимо откатить последнюю миграцию или миграции. Проще всего это сделать через утилиту Alembic, если вы её применяете. Затем переходим к шагу 31.

Шаг 47. Ожидать завершения миграции

Лучше всего дождаться завершения миграции. Меньше проблем будет в дальнейшем. Затем переходим к шагу 31.

Заключение

Надеюсь, эта схема поможет вам в трудной ситуации (например, во время аварии). Она собрала значительную часть наших болячек и травмоопасного опыта.

Хочу выразить огромную благодарность Алексею Попову за помощь в подготовке статьи. Без его рецензии и консультаций статья была бы не столь полной и точной.