Cloud Transfer · Репликация баз

Как перенести PostgreSQL или MySQL из одного облака в другое

Перенос базы между облаками делают снимком или репликацией. Снимок — выгрузить базу и загрузить её в новое облако. Репликация — сначала скопировать данные, затем передавать изменения до переключения приложения. Главный вопрос не в названии утилиты, а в том, сколько простоя можно позволить.

• База небольшая и запись можно остановить — pg_dump или mysqldump.
• База большая или простой должен занять минуты, а не часы — репликация изменений.

Как выбрать способ

Между двумя managed PostgreSQL или managed MySQL чаще нужен второй путь: загрузить то, что уже есть, догнать изменения и переключить приложение.

Перенос снимком

Источник выгружают и загружают в новую базу. Для PostgreSQL это pg_dump и pg_restore, для MySQL — mysqldump и загрузка в mysql. Выгрузка фиксирует состояние на момент старта. Если приложение после этого продолжает писать в старую базу, новые изменения нужно перенести отдельно или остановить запись перед финальным снимком.

Снимок подходит, когда база сравнительно небольшая, окно простоя допустимо, миграция разовая и две базы не нужно держать синхронными. Если перенос занимает минуты, иногда проще остановить запись на это время. Если он занимает часы, снимок уже неудобен.

Перенос почти без простоя

Для большой базы схема другая: начальная копия, затем репликация, затем догон и переключение. Сначала существующие данные попадают в новую базу. Дальше изменения продолжают идти со старой. У PostgreSQL это logical replication и WAL, у MySQL — binlog.

Пока идёт перенос, приложение работает со старой базой, новая постепенно догоняет. Когда отставание близко к нулю, запись ненадолго останавливают, дожидаются последних изменений, проверяют новую базу, меняют строку подключения и включают запись уже там. Простой большой базы оказывается окном переключения, а не часами выгрузки.

Что репликация не забирает сама

Передача строк — не полная миграция базы. У logical replication PostgreSQL изменения строк могут идти сами, а отдельно остаются структура таблиц, новые DDL, роли и пользователи, GRANT, расширения, sequences, настройки, типы, функции и процедуры. Целевую базу готовят до потока: схема, пользователи, расширения и права, затем начальная загрузка, и только потом непрерывная репликация.

Чем отличается pg_basebackup

pg_basebackup делает физическую копию кластера PostgreSQL, а не построчный перенос таблиц. Так строят реплику и резервирование. Между managed-провайдерами это часто недоступно: нет доступа к файлам PostgreSQL, не хватает прав на репликацию, нельзя настроить восстановление наружу. Физическая репликация ещё и жёстче зависит от версии. Для переноса managed PostgreSQL из облака в облако обычно удобнее логическая.

Как это выглядит между облаками

PostgreSQL из Yandex Cloud в Cloud.ru: сначала начальная загрузка, затем WAL через logical replication. MySQL из VK Cloud в Selectel: начальная загрузка и дальше binlog. Источник и приёмник могут быть у разных поставщиков. Механизм PostgreSQL или MySQL от этого не меняется. Меняется сеть вокруг него.

Нужен доступ приёмника к источнику: публичный адрес, VPN, приватная сеть, NAT или SSH-туннель. У managed-баз к этому добавляются allowlist, security groups и TLS. До старта сверяют версии, расширения, collation, кодировку, типы и ограничения конкретного сервиса. Нет нужного расширения у нового провайдера — репликация строк это не исправит.

Репликация хорошо везёт новые изменения. Сотни гигабайт или терабайты всё равно надо сначала доставить на приёмник. Перед переключением сравнивают число строк, размеры таблиц, отставание, выборочные данные, sequences, права и версию схемы. Момент, когда меняют адрес базы, и есть реальный простой.

Почему инструкции облака не хватает

Облака хорошо описывают вход к себе: внешняя база становится их базой. Задача клиента чаще другая — из облака A в облако B. Тогда сами связывают API двух площадок, сеть, ключи, начальную загрузку, репликацию, повторы и переключение. Если баз много или перенос повторяется, эта сборка становится основной работой.

Где здесь Cloud Transfer

Сервис делает cloud-to-cloud перенос PostgreSQL и MySQL: существующие данные и дальнейшие изменения до момента переключения. Площадки — Yandex Cloud, VK Cloud, Selectel, MWS, Cloud.ru, Timeweb Cloud, EdgeCenter, K2 Cloud и Ростелеком. Вокруг штатных механизмов базы он забирает доступ к источнику, проверку совместимости, начальную копию, репликацию, контроль отставания и готовность к переключению. Сам момент переключения приложения остаётся у владельца базы.

Рядом тем же маршрутом идёт перенос S3-бакета. Копии дисков виртуальных машин обсуждаются отдельно: способ ещё не зафиксирован.

Репликация — не резервное копирование

Репликация нужна, чтобы вторая база была актуальной. Backup нужен, чтобы вернуться в прошлое. Если приложение удалит таблицу, ошибка может уехать и на вторую базу. Для миграции между облаками нужна репликация. Для восстановления после ошибки — резервная копия.

Что выбрать

Запись можно остановить на время полного переноса — pg_dump или mysqldump, затем загрузка и переключение. Останавливать приложение на несколько часов нельзя — начальная загрузка, репликация, догон и короткое переключение: logical replication PostgreSQL или binlog MySQL.

Сеть между облаками, начальную загрузку, репликацию, повторы, отставание и порядок переноса можно отдать Cloud Transfer.

Короткие ответы

Можно ли перенести PostgreSQL без простоя?

Полностью исключить переключение обычно нельзя, но основную часть данных можно перенести заранее. Затем новая база догоняет изменения через logical replication, а приложение переключается после того, как replication lag станет минимальным.

Чем pg_dump отличается от logical replication?

pg_dump создаёт снимок базы. Изменения после начала снимка автоматически на новую базу не передаются. Logical replication продолжает передавать изменения после первоначальной загрузки.

Можно ли перенести PostgreSQL между разными облаками?

Да, если источник позволяет использовать необходимые механизмы репликации и между базами можно организовать сетевое соединение.

Можно ли перенести MySQL между облаками без длительного простоя?

Да. Обычно сначала выполняется первоначальная загрузка данных, после чего новые изменения передаются через MySQL binlog до момента переключения.

Можно ли так перенести PostgreSQL в MySQL?

Нет. Это уже миграция между разными СУБД. Потребуется преобразование схемы, типов данных, SQL и часто логики приложения.

Переедут ли пользователи и расширения PostgreSQL?

Не обязательно. Роли, права, extensions, DDL и другие объекты необходимо отдельно учитывать при подготовке целевой базы.

Это резервное копирование?

Нет. Репликация нужна для поддержания второй актуальной базы. Backup нужен для восстановления предыдущего состояния.