Мажорное обновление PostgreSQL: где ломается прод
Переход на новую мажорную ветку — это не обновление пакета, а смена внутреннего формата каталога: новый сервер физически не читает файлы данных предыдущей ветки, и поднять на нём старый кластер нельзя. Поэтому мажорное обновление PostgreSQL всегда идёт отдельной процедурой — с подготовкой, прогоном на копии и разделением «обновили сборку» и «переключили прод». Откат через пакетный менеджер здесь не работает: серверные файлы вернутся, данные — нет.
Первое, что рвётся, — расширения. Часть требует пересборки под новую ветку, часть меняет набор типов, функций и операторов, а индексы поверх пользовательских типов после переноса могут оказаться невалидными. Ошибки после переключения проявляются не на старте, а на конкретных запросах: не находится оператор, приведение типов уходит в исключение, агрегат возвращает другое значение. Поэтому совместимость расширений проверяют до окна, а не внутри него.
Второй источник тихих отказов — параметры конфигурации при переходе. Часть директив удалена, часть переименована, часть сохранила имя, но поменяла смысл или значение по умолчанию. Сервер поднимется, а план запроса, оценка стоимости и поведение сборщика мусора будут другими — диск растёт без единой строки в логе.
И главный ограничитель — окно недоступности базы. Обновление с остановкой укладывается в минуты, но требует полного простоя и не оставляет места для второй попытки. Переход через логическую репликацию простоя почти не даёт, зато растягивает подготовку и требует явной сверки расхождений. Дальше разбираем, как это закрывается на практике.
Что меняется после перехода на новую мажорную ветку
Управляемый переход на новую мажорную ветку даёт эффект не в списке нововведений, а в снятых ограничениях. Планировщик и хранение в новой ветке обслуживают запросы, которые на предыдущей упирались в потолок: параллельные операции над крупными таблицами, секционирование без ручных триггеров, индексы без периодической пересборки. Время недоступности сервиса сводится к моменту переключения — проверка совместимости и прогрев идут на реплике заранее.
Устранённый класс отказов ощущается сильнее всего. Обходные решения живут на расписании: перезапуск по регламенту, ручная чистка раздувания, слежение за размером каталогов. Такие задачи не падают громко — их тихо пропускают, и тогда база деградирует до аварии. После перехода эти операции выполняет сама PostgreSQL, а окна регламентных работ сокращаются.
Предсказуемый откат проектируют до переключения. Прежний кластер остаётся ведущим, изменения уходят на новую ветку потоком, а обратный ход — возврат маршрута приложений на прежний узел, а не восстановление из архива. План репетируют на копии: если после переключения расходятся планы запросов или падает скорость конкретной выборки, возврат занимает минуты.
На выходе — кластер на единой ветке: реплики, правила переключения и обновления безопасности одного уровня, без зоопарка версий. Эффект от обновления измеряют до и после: время отклика ключевых выборок, число регламентных вмешательств, время восстановления при отказе узла.
Способы обновления: сравнение режимов и ограничений
Мажорное обновление PostgreSQL меняет формат каталога данных, поэтому способ перехода выбирают по трём измерениям: допустимое окно простоя, объём базы и наличие несовместимых объектов — расширений, типов, процедурных языков. Универсального варианта нет, и на практике их комбинируют: например, сначала переносят утилитой, а несовпавшие объекты досоздают вручную.
Перенос утилитой обновляет каталог данных на месте и переносит файлы напрямую, поэтому простой измеряется минутами даже на крупной базе. Плата — запас диска под оба каталога и совпадение кодировки с разрядностью. Логическая репликация между версиями разворачивает целевой сервер новой ветки рядом и переливает изменения на ходу: простой сокращается до переключения трафика, но объекты вне публикации, последовательности и права переносят отдельно.
Дамп и восстановление остаётся самым предсказуемым путём, когда заодно перестраивают схему или меняют платформу, — ценой полного простоя на выгрузку и загрузку. Параллельный кластер поднимают на отдельном узле, переводят туда нагрузку и оставляют старый как точку отката, платя вторым набором ресурсов.
Ограничения способов перехода сводятся к одной развилке: либо короткое окно и жёсткие требования к совместимости, либо управляемый перевод с ручной доработкой.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Перенос утилитой | Большая база, короткое окно, совместимые расширения | Нужен запас диска, совпадение кодировки и разрядности |
| Логическая репликация между версиями | Сервис нельзя останавливать, перевод пошаговый | Ручной перенос объектов вне публикации и прав |
| Дамп и восстановление | Смена платформы, перестройка схемы | Простой на всю выгрузку и загрузку |
| Параллельный кластер | Нужен безопасный откат и изоляция | Двойные ресурсы, синхронизация прав и последовательностей |
Порядок работ: от аудита совместимости до переключения
Мажорное обновление PostgreSQL — не одна команда pg_upgrade, а последовательность, где каждый шаг снимает конкретный риск. Между ветками меняются каталоги системных таблиц, поведение по умолчанию и требования к расширениям, поэтому идём от инвентаризации к регламенту отката, который остаётся наготове до конца работ.
-
Инвентаризация объектов. Собираем перечень баз, схем, расширений, пользовательских типов, триггеров, правил и полнотекстовых конфигураций. Отдельно фиксируем кодировку, локаль, владельцев и права — то, что чаще всего теряется при переносе.
-
Аудит совместимости. Сверяем объекты с целевой веткой: что поддерживается, что требует обновления расширения, что удалено. На выходе — список правок в схеме и запросах, которые вносим до переключения, а не после.
-
Тестовый прогон на копии. Разворачиваем копию кластера с тем же объёмом данных и похожим профилем нагрузки и прогоняем обновление целиком: получаем реальную оценку окна простоя и заранее видим проблемы расширений.
-
Настройка и контроль целостности. Переносим параметры, пересобираем статистику, проверяем фоновую очистку, планы тяжёлых запросов и репликацию. Сверяем количество строк в ключевых таблицах, последовательности и права доступа.
-
План переключения. Расписываем шаги: остановка записи, режим только чтение, финальная синхронизация, смена точки подключения приложений, снятие ограничений — с ответственным и оценкой времени на каждом.
-
Регламент отката и передача. Старый каталог и реплику держим нетронутыми до подтверждения результата, критерии возврата фиксируем заранее и проверяем обратный путь на копии. После — документация и наблюдение за новой веткой.
Что остаётся на руках: конфигурации, схемы, регламенты
После обновления у заказчика остаётся не только работающая база, но и комплект артефактов, по которым её можно вести дальше — своими силами или с нашей помощью. Передаём их в репозиторий с историей изменений, а не в переписку и не в заметки одного инженера: следующий специалист восстанавливает картину без устных пояснений.
- Конфигурации кластера — рабочие файлы настроек с пометками, почему выбраны такие размеры буферов, таймауты и режим журнала, и что менялось под нагрузку.
- Схема репликации — топология узлов, их роли, порядок переключения и допустимое отставание реплик.
- Политики доступа и роли — матрица прав, владельцы объектов и расширений, подтверждение, что привилегии перенеслись без потерь.
- Скрипты сверки и отката — запросы для сравнения числа строк и контрольных сумм ключевых таблиц до и после, плюс порядок возврата на прежнюю версию.
- Документация по базе — карта объектов, зависимости приложений от типов и расширений, узкие места, всплывшие при переносе.
- Регламент обновления — пошаговый порядок: подготовка, прогон на копии боевого объёма, остановка записи, перенос, проверки, включение трафика — с окном работ и критериями остановки.
Такой комплект превращает разовое обновление в воспроизводимую процедуру: следующая мажорная версия проходит по уже проверенному маршруту, а не начинается с нуля.
Кейс: переход без длительного простоя и с быстрым откатом
Кластер обслуживал витрины и очередь фоновых задач, поэтому блокировка записи на несколько часов означала остановку приёма данных. На прошлом переходе между мажорными версиями PostgreSQL недоступность растянулась почти на четыре часа, а часть объектов пришлось пересоздавать вручную уже после запуска — ошибки в них всплывали в первые сутки.
| Метрика | До | После |
|---|---|---|
| Недоступность на запись | 3 ч 40 мин | 40–50 с на переключение |
| Инциденты в первые две недели | 7, из них 2 с потерей части записей | 0 |
| Возврат на прежнюю версию | около 2 ч, восстановление из копии | 3–5 мин, обратной репликой |
| Объекты, потребовавшие ручной правки | 34 % | 9 % |
Подготовку начали заранее: перенос дважды прогнали на полной копии кластера, зафиксировали реестр объектов, которые не переезжают автоматически — функции на неродном языке, собственные расширения, представления с агрегатами, — и написали для каждого команду миграции с проверкой на тестовых данных. Это и срезало долю ручной доработки.
Переключение делали в окне низкой нагрузки: приём остановили, довели изменения, подняли новую версию и вернули трафик. Читающие копии всё это время оставались доступны, поэтому внешние отчёты не прерывались.
Обратную реплику на прежней версии держали сутки после переключения — откат проверяли на репетиции и знали, что он занимает минуты, а не часы. Если разбор расходятся, возвращаемся на прежнюю версию и продолжаем работу, пока не найдём причину. Такой план и есть основная страховка: он позволяет перейти без длительного простоя и не зависеть от одной попытки.
Что делать, если база уже работает в кластере с репликами?
Кластер с репликами обновляют не узел за узлом, а как новую топологию репликации. Физическая репликация между мажорными версиями несовместима: формат журнала изменений у них разный, поэтому реплика прежней версии не подключится к обновлённому основному узлу. Отсюда главное следствие — пересборка реплик неизбежна: их строят заново из копии уже обновлённого основного.
Пошаговый переход кластера выглядит так. Сначала убеждаемся, что реплики не отстают и не осталось слотов репликации, удерживающих журналы. Затем переносим данные на основном узле на новую мажорную версию — без переливки самой базы. После этого снимаем копию основного и строим из неё реплики: они встают в поток и догоняют его. Далее сверяем число строк в ключевых таблицах и отставание каждой реплики, и только потом переключаем приложение.
Реплики чтения, обслуживающие отчёты и выгрузки, выводим из балансировки заранее — пока идёт пересборка, приложение не должно слать туда запросы. Если отчётность готова потерпеть, их можно оставить на прежней версии до самого переключения, но запись на них не идёт ни в один момент.
Когда окно недоступности критично, топологию собирают иначе: новый кластер поднимают рядом и наполняют логической репликацией со старого. Переключение тогда занимает секунды, а откат — возврат приложения на прежний узел. Плата — совместимость схемы на обеих версиях и ручная донастройка того, что логическая репликация не переносит.
Технические сомнения перед переходом: вопросы и ответы
Перед переводом кластера на новую мажорную ветку сомнения обычно упираются в пять пунктов: длительность простоя, несовместимые расширения, безопасный откат, объём базы и правки в прикладном коде. Ниже — короткие ответы, детальный разбор идёт дальше.
Насколько долгим будет простой?
Проверку совместимости, прогон на копии и подготовку расширений делаем на работающем кластере. Приём транзакций останавливаем только на перенос каталога — это минуты, а не часы; на крупных базах время сокращает параллельный перенос.
Что делать с несовместимыми расширениями?
Сверяем установленные расширения с целевой веткой до старта работ: часть требует обновления пакета, редкие — замены на аналог. Так несовместимость не всплывает в момент переключения.
Возможен ли безопасный откат?
Пока новая ветка не принята в эксплуатацию, старый каталог и настройки остаются нетронутыми: возврат — это переключение сервиса на прежний каталог. До точки невозврата откат занимает столько же времени, сколько само переключение.
Выдержит ли большой объём базы?
Перенос идёт на уровне файлов каталога, а не построчной выгрузкой, поэтому время растёт не линейно объёму. Для больших баз отдельно проверяем свободное место под новый каталог и журналы, а также время построения индексов.
Придётся ли править прикладной код?
Правки касаются в основном поведения по умолчанию и устаревших конструкций в запросах. Прогоняем приложение на копии новой ветки и снимаем планы запросов — расхождения фиксируем до переключения.
Обсудим задачу и вернёмся с планом работ
Чтобы обсудить задачу предметно, нужен минимум вводных: текущая мажорная ветка и целевая, объём базы и её рост, число баз на инстансе, наличие физических и логических реплик, установленные расширения и их совместимость с новой веткой. Отдельно важно понять характер нагрузки и допустимое окно недоступности, в которое должно уложиться переключение.
По этим данным мы собираем план перехода и сценарий отката, а не общие рекомендации. Возвращаемся с документом, по которому инженер может работать без доуточнений.
- План перехода по этапам: подготовка, проверка на копии данных, переключение, контроль после — с точками, где можно остановиться.
- Сценарий отката: до какой точки возвращаемся, что происходит с данными, накопленными за время переключения, сколько это занимает.
- Оценка сроков: длительность окна недоступности и трудозатраты вашей и нашей команды.
- Список несовместимостей: расширения, устаревшие параметры конфигурации, запросы, требующие правки.
- Порядок обновления реплик и требования к дисковому запасу под новую ветку.
- Передача регламента: чек-лист и инструкция, чтобы следующий мажорный переход ваша команда проводила сама.
Опишите задачу в свободной форме — конфигурацию, ограничения по окну простоя, что уже пробовали и на чём остановились. Вернёмся с оценкой сроков, планом перехода и сценарием отката, которые можно обсуждать предметно, а не на уровне общих слов.
