Миграция PostgreSQL без простоя: что покажут замеры
Переезд между крупными версиями PostgreSQL можно провести с короткой паузой на переключение, но не обещать честный ноль секунд. Разбираем схему логической репликации, риски и метрики, по которым сравнить простой до и после.
«Без простоя» — это короткое переключение, а не магия
При переходе с PostgreSQL 16 на 17 логическая репликация позволяет перенести данные на новый кластер, пока старый продолжает принимать записи. Но в момент смены приложения записи всё равно нужно остановить и дождаться отставших изменений. Поэтому сравнивать стоит не абстрактное «до и после», а длительность недоступности записи, время догоняющей репликации, нагрузку на старый кластер и объём потерянных или повторно обработанных операций.
Ниже — схема для переезда с PostgreSQL 16 на 17. Это не пошаговая инструкция с командами: конкретная конфигурация зависит от схемы, объёма данных и приложения. Цифры для вашего сервиса нужно получить нагрузочным прогоном — универсального достоверного результата для такой миграции нет.
Что именно сравнивать
Сравнение со штатным обновлением через pg_upgrade показывает цену выбора. Этот инструмент переносит кластер между основными версиями, но для работы приложения старый кластер обычно останавливают на время обновления и проверки. Логическая репликация дольше требует двух работающих кластеров, зато большую часть данных переносит до переключения.
| Метод | Что происходит | Цена и ограничение |
|---|---|---|
pg_upgrade | Кластер обновляют на месте или рядом, используя существующие файлы данных. | Окно простоя включает остановку, обновление и проверки. Его длительность зависит от размера кластера, дисков и выбранного режима. |
| Логическая репликация | Новый PostgreSQL 17 заранее получает изменения из работающего PostgreSQL 16. | Нужны дополнительный сервер, место и время на начальную копию. Переключение требует остановить записи и проверить, что подписчик догнал издателя. |
| Физическая репликация | Передаются изменения на уровне кластера и файлов хранения. | Не подходит как обычный способ обновить кластер между основными версиями: физическая репликация рассчитана на совместимые версии и конфигурации, а не на такой перенос. |
Таблица не обещает, что логическая репликация всегда быстрее. Если база невелика, а окно обслуживания приемлемо, pg_upgrade может оказаться проще и дешевле. Если длительный простой недопустим, цена второго кластера и репетиции обычно оправдана.
Как устроен переезд на логической репликации
В PostgreSQL 16 издатель публикует изменения выбранных таблиц, а подписчик на PostgreSQL 17 получает их и применяет. Начальную копию таблиц система тоже может выполнить при настройке подписки. При этом логическая репликация переносит изменения строк, а не всю базу как неделимый объект: схему, часть объектов и настройки нужно подготовить отдельно.
Ключевой нюанс: изменения DDL — например, создание таблицы или изменение столбца — автоматически таким способом не переносятся. Последовательности также требуют отдельной синхронизации. До миграции сверяют схему, роли, расширения, права, задания и объекты, которые не входят в репликацию. Для таблиц заранее проверяют наличие подходящего ключа или другой настройки идентификации строк: без неё обновление и удаление могут не применяться ожидаемым образом.
«Низкий replication lag — ещё не готовность к переключению. Готовность означает, что новый кластер содержит все подтверждённые записи, а приложение и сопутствующие процессы проверены на нём».
Пока идёт перенос, важно наблюдать не только за отставанием подписчика. Долгая начальная копия и медленное применение изменений могут удерживать WAL на издателе и занять дисковое пространство. Если место закончится, проблема затронет уже работающий старый кластер.
Замеры до и после: что записать
До репетиции зафиксируйте обычную нагрузку и согласованный предел простоя. Затем повторите миграцию на копии производственной базы с сопоставимыми версиями, объёмом данных, дисками и потоком записей. Если прогон на меньшем стенде — так и укажите: его результаты нельзя напрямую выдавать за время переключения в проде.
| Показатель | До миграции | После переключения | Как читать результат |
|---|---|---|---|
| Недоступность записи | Измерить при текущем способе обновления | От начала запрета записи до подтверждения готовности приложения | Главная цифра для владельца сервиса. Отдельно отметьте, были ли недоступны чтение и фоновые задачи. |
| Отставание репликации | Не применимо | Максимум во время переноса и значение перед переключением | Смотрите состояние подписки и время последнего применённого сообщения; при финальном переключении нужен согласованный способ подтвердить догон. |
| WAL и свободное место | Обычный темп накопления WAL и остаток диска | Пик за время начальной копии и репликации | Показывает, выдержит ли старый кластер миграцию без риска заполнить диск. |
| Задержка и ошибки запросов | Базовый уровень приложения | Первые минуты и часы после переключения | Новый сервер может быть догнавшим, но всё ещё проигрывать по настройкам, прогретости кэша или планам запросов. |
В PostgreSQL 16 состояние подписок можно наблюдать через статистику подписчика, включая время последнего полученного сообщения и последнюю обработанную позицию. На издателе следите за слотами репликации и удерживаемым WAL. Не сводите всё к одному числу задержки в миллисекундах: оно не доказывает само по себе, что перенесены все нужные объекты и корректно синхронизированы последовательности.
Если точного замера старого способа нет, не подставляйте расчётное число вместо факта. Запишите, сколько заняли остановка приложения, обновление, проверки и возврат трафика при последней репетиции. После переезда сравните те же интервалы и одинаковые показатели.
Где схема ломается
- Схема разошлась. Изменение таблицы на издателе не появилось на подписчике. Заморозьте DDL на время миграции или отдельно применяйте и проверяйте изменения схемы на обеих сторонах.
- Репликация не успевает. Поток записи быстрее, чем подписчик применяет изменения. Проверьте производительность диска и CPU, размер начальной копии и накопление WAL; не переключайтесь, пока не подтверждено отставание в пределах принятого плана.
- Закончился диск. Удерживаемые слотом WAL-файлы разрастаются, если потребитель отстаёт или остановился. Заранее задайте пороги оповещения и план действий, включая безопасную отмену миграции.
- Последовательность выдала уже использованное значение. Состояние последовательностей не следует считать автоматически перенесённым. При остановленных записях проверьте их значения и синхронизируйте до открытия записи на новом кластере.
- Приложение записывает в обе базы. Одновременная запись в старый и новый кластеры не становится безопасной от того, что между ними есть подписка. Возможны конфликты и расхождения; переключайте единый источник записи по заранее отрепетированному плану.
Откат тоже имеет границу. Пока приложение не пишет в PostgreSQL 17, можно вернуть трафик на старый кластер после проверки состояния. Как только на новом кластере появились новые записи, простое возвращение старого адреса может потерять эти данные. Для такого случая нужен отдельный план обратной синхронизации или восстановления операций.
План переключения без ложного обещания нуля
- Зафиксируйте допустимую паузу записи и критерии отмены. Проверка: владелец сервиса подтвердил измеримые пороги и ответственных.
- Поднимите PostgreSQL 17 и подготовьте схему, роли, расширения и конфигурацию. Проверка: приложение может подключиться к тестовому кластеру с нужными правами.
- Настройте публикацию и подписку, перенесите начальные данные, затем дайте репликации поработать под нагрузкой. Проверка: таблицы сверены, подписка активна, свободного места достаточно.
- На время переключения запретите новые записи в старый кластер и остановите фоновые процессы, которые пишут в базу. Проверка: новые транзакции записи больше не появляются.
- Дождитесь применения оставшихся изменений, отдельно синхронизируйте последовательности и проверьте критичные таблицы. Проверка: контрольные сверки совпали, ошибок применения нет.
- Переключите приложение на PostgreSQL 17, включайте запись постепенно и следите за ошибками, задержкой запросов и блокировками. Проверка: прошёл контрольный набор операций, а показатели остаются в заданных пределах.
Сверку данных выбирайте с учётом объёма и критичности: полное сравнение каждой строки может оказаться слишком дорогим для окна переключения, а проверка только числа записей — недостаточной. Репетируйте на тех же проверках, которые будете использовать в проде.
Что делать дальше
Сначала проведите пробный перенос на копии базы и заполните таблицу фактическими результатами: время начальной копии, максимальное отставание, пик занятого диска и длительность запрета записи. Затем повторите сценарий с отказом подписчика и отменой переключения. Только после этого назначайте окно. Инвалидация кэшей и обновление расширений — отдельные задачи; здесь рассматривается только миграция данных и переключение базы.
WAL — журнал предварительной записи PostgreSQL: в нём фиксируются изменения, необходимые для восстановления и передачи репликации. Удержание WAL слотом означает, что сервер не может удалить часть журнала, пока репликация не обработает нужные записи.
Проверка рекламы на риски: Что в макете вызовет вопросы ФАС: превосходные степени, сравнения, обещания результата, маркировка.
Спросить за 40 ₽Источники: PostgreSQL 16: Logical Replication, PostgreSQL 16: pg_upgrade
Частые вопросы
Можно ли гарантировать полный ноль секунд простоя?
Подойдёт ли эта схема для перехода с PostgreSQL 15 или 14?
Что будет, если подписчик не догонит издателя?
Миграция перенесёт последовательности и изменения схемы?
Можно ли сразу вернуться на старую базу после переключения?
Какие метрики смотреть в проде после переезда?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.