Логическая репликация

Логическая репликация — это сценарий для миграции с минимальным downtime. Но в SPG99 его стоит рассматривать как расширенный путь, который нужно заранее подтвердить и протестировать в вашем контуре.

Почему нужен отдельный пилот

Для логической репликации важны предпосылки на стороне PostgreSQL и runtime‑конфигурации. Поэтому перед проектированием cutover убедитесь, что для вашего сценария согласованы:

• поддержка нужного режима на источнике и приёмнике;
• требования к публикациям, подпискам и replication‑worker;
• допустимое поведение по слотам, лагу и окну переключения.

Когда этот путь имеет смысл

Используйте его, если:

• окно простоя очень ограничено;
• объём данных велик и полный pg_restore неудобен;
• у вас есть время на тестовый прогон и проверку поведения до production.

Общая схема работы

1. Настройте публикацию на исходной БД.
2. Подготовьте целевую БД в SPG99.
3. Создайте подписку на стороне приёмника, если это подтверждено для вашего контура.
4. Дождитесь устойчивой синхронизации.
5. На cutover заморозьте запись на источнике, дождитесь минимального или нулевого лага и переключите приложения на новый DSN.

Что важно пользователю

• отдельный ручной start для базы в managed‑контуре не нужен;
• во время репликации полезно следить за фактическим lag, логами и состоянием БД;
• перед production‑переключением обязателен тест на отдельном tenant или в тестовом окружении.

Практическая рекомендация

Если вам не нужен минимальный downtime любой ценой, почти всегда надёжнее и проще выбрать pg_dump / pg_restore. Логическая репликация оправдана там, где её сложность действительно окупается требованиями бизнеса.