Сообщить об ошибкеКороткий ответ
Сначала проверяю версии, расширения, объём и ограничения managed-сервиса, затем синхронизирую данные репликацией. В окно миграции останавливаю запись, довожу lag до нуля, переключаю приложение, проверяю данные и метрики, сохраняя старую базу для отката.
Как это работает подробнее
Логическая репликация переносит изменения, пока источник продолжает обслуживать запросы, поэтому простой ограничивается финальной синхронизацией и сменой подключения. План должен отдельно учитывать последовательности, DDL, пользователей и расширения.
- Подготовка. Проверить поддерживаемые версии, extensions, encoding, объём, пропускную способность и права.
- Синхронизация. Сделать первичную загрузку и отслеживать replication lag, ошибки и расхождения.
- Cutover. Заморозить запись, дождаться нулевого lag, переключить connection string и провести smoke tests.
Пример кода
replication-check.sql
SELECT application_name, state, sync_state,
write_lag, flush_lag, replay_lag
FROM pg_stat_replication
ORDER BY application_name;Что использовать на практике
- Репетиция. Полностью пройти миграцию на staging и измерить длительность каждого шага.
- Критерии. Заранее определить допустимый lag, контрольные агрегаты, smoke tests и время наблюдения после cutover.
- Откат. Зафиксировать точку принятия решения и безопасный способ вернуть трафик на источник без потери новых записей.
Подводные камни
- Совместимость. Не все расширения и параметры self-managed PostgreSQL доступны в managed-сервисе.
- Ложный откат. Простая смена connection string назад опасна, если после cutover новая база уже приняла записи; нужен план обратной синхронизации или запрет записи.