Миграция с EC2 на GCP как перенести PostgreSQL базу без даунтайма

[infern]

Нужно перенести production PostgreSQL 15 с AWS EC2 (eu-west-1) на GCP Cloud SQL (europe-west3). База ~200 ГБ, около 500 транзакций в секунду в пике. Даунтайм критичен — максимум 5 минут. Читал про pglogical и AWS DMS, но с DMS были какие-то проблемы с расширениями. Кто делал такое, поделитесь реальным опытом и подводными камнями?

[kingpaul]

Делал аналогичную миграцию полгода назад, правда база была 80 ГБ. Использовал связку pg_dump с --no-owner + pglogical для репликации после начального слива. Главный подводный камень — pglogical требует wal_level=logical на источнике, и нужно добавить REPLICA IDENTITY FULL для таблиц без primary key, иначе UPDATE/DELETE не реплицируются. Также все расширения нужно заранее установить на Cloud SQL и проверить их совместимость.

[torch22]

AWS DMS с PostgreSQL в режиме CDC реально работает, но есть нюансы: он плохо справляется с DDL-изменениями во время миграции, и если у тебя есть таблицы с JSONB и сложными типами — могут быть проблемы с конвертацией. Для твоего объёма я бы посмотрел на pgcopydb — он делает параллельный dump/restore и работает быстрее стандартного pg_dump в 3-5 раз.

[esp32ninja]

200 ГБ и 5 минут даунтайма — это реально, но требует правильной подготовки. Схема: 1) настраиваешь logical replication за несколько дней до X, 2) даёшь репликации догнать лаг (должен быть < 1 секунды в steady state), 3) в момент переключения останавливаешь запись на старой БД, ждёшь 0 лага, меняешь connection string в приложении. На GCP Cloud SQL нужно убедиться, что включён флаг cloudsql.logical_decoding и alloydbadmin может создавать слоты.

[kickmybox]

Не забудь про sequences — pg_dump их включает, но если во время репликации были вставки, sequence на новой базе может отстать. После переключения сразу проверь SELECT last_value FROM your_sequence и при необходимости выполни SELECT setval. Также проверь timezone настройки на Cloud SQL, по дефолту там UTC, а у вас на EC2 может быть другой.

[doppe]

Для верификации после переключения советую заранее написать скрипт, который считает COUNT(*) и MAX(id) по ключевым таблицам на обоих серверах и сравнивает. Запускай его сразу после переключения, пока ещё можно откатиться. Ещё важный момент — DNS TTL: поставь 60 секунд за сутки до миграции, чтобы клиенты быстро подхватили новый адрес.

[lorenzinoarq]

У GCP есть свой Database Migration Service, для миграций в Cloud SQL он бесплатный и под капотом сам поднимает pglogical. Тащил им 350 ГБ с EC2, начальный слив шел часов 9, дальше CDC спокойно догонял. Из граблей: заранее сверь pg_extension со списком поддерживаемых в Cloud SQL, у нас не было pg_cron и пришлось переезжать на Cloud Scheduler. И superuser там не дают, любые скрипты с ALTER ROLE SUPERUSER падают, проверь свои миграции на это.

[cmout098]

@esp32ninja, останавливаешь запись на старой БД звучит просто, а на деле это самое тонкое место всей схемы. Мы делали через pgbouncer PAUSE, коннекты повисели секунд 40 и поехали на новый адрес, приложение вообще не трогали. Без пулера придется катить конфиг деплоем, и вот тут 5 минут превращаются в 20.

[nikita87]

@doppe, DNS TTL это если клиенты ходят по доменному имени. Половина контор зашивает хост в конфиг и обновляет деплоем, там твой TTL никому не поможет. А вот скрипт сверки COUNT и MAX плюсую, нас такой один раз спас, поймали отставшую таблицу без PK до того, как откат стал невозможен.