Миграция баз данных в облако
База данных — самое ценное в любом проекте. И самое сложное для миграции. В отличие от файлов или статики, БД хранит состояние: транзакции, индексы, репликацию, последовательности. Ошибка при переносе может привести к потере данных, рассинхронизации и часам простоя.
Хорошая новость: миграция БД — это управляемый процесс. Существуют проверенные методы: логические дампы, физические копии, логическая репликация, CDC. Каждый решает свою задачу. В этой статье — разбор миграции баз данных в облако: методы, инструменты, этапы, типичные ошибки. Если нужно перенести БД в облако — поможем.
Почему БД сложнее всего
База данных отличается от файлов или приложений по нескольким причинам.
Состояние
БД хранит состояние в реальном времени. Данные меняются постоянно — нельзя просто «скопировать и переключить».
ACID
Транзакции должны быть атомарными. При переносе важно сохранить консистентность данных.
Связность
Таблицы связаны FK, приложение завязано на конкретные ID. Нужна согласованность по всем связям.
Время
Перенос большой БД занимает часы. Нужно минимизировать окно простоя — в идеале до нуля.
Методы миграции
Методов несколько. Выбор зависит от объёма данных, требований к простою и версий СУБД.
| Метод | Простой | Объём | Совместимость |
|---|---|---|---|
| Логические дампы | Часы | до 100 ГБ | Между версиями и платформами |
| Физические копии | Часы | любой | Только одинаковая версия |
| Логическая репликация | Минуты | любой | PostgreSQL 10+, MySQL 5.7+ |
| CDC (Debezium) | Секунды | любой | Требует настройки |
| Snapshot + WAL | Минуты | любой | Одинаковая версия |
Для большинства проектов оптимальна логическая репликация — она даёт минимальный простой и работает между разными версиями.
Логические дампы
Логический дамп — это файл с SQL-командами или бинарным представлением данных. Самый простой метод, но не самый быстрый.
Инструменты
- pg_dump / pg_restore: для PostgreSQL;
- mysqldump / mydumper: для MySQL и MariaDB;
- mongodump / mongorestore: для MongoDB.
Плюсы
- Универсальность: работает между разными версиями и платформами;
- Читаемость: можно посмотреть содержимое дампа;
- Гибкость: можно перенести отдельные таблицы или схемы;
- Проверка: легко убедиться, что данные полные.
Минусы
- Долго: для больших БД — часы;
- Блокировки: может блокировать таблицы на время дампа;
- Двойная нагрузка: экспорт и импорт — это два тяжёлых процесса;
- Простой: обязательно окно для импорта.
💡 Важно
Логический дамп подходит для БД до 100 ГБ. Для больших объёмов нужны другие методы — репликация или физические копии.
Физические копии
Физическая копия — это побайтовая копия файлов БД. Быстрее логического дампа, но требует одинаковой версии СУБД.
Инструменты
- pg_basebackup: для PostgreSQL;
- Percona XtraBackup: для MySQL без остановки;
- Snapshots: средствами облака (для managed-БД).
Плюсы
- Быстро: копирование файлов напрямую;
- Полнота: переносится всё состояние БД;
- Работает с большими БД: десятки и сотни ГБ;
- Быстрое восстановление: просто запустить на новом сервере.
Минусы
- Одинаковая версия: PostgreSQL 14 → PostgreSQL 14, но не 14 → 15;
- Одинаковая платформа: Linux → Linux, но не Linux → Windows;
- Нужен холодный бэкап: обычно БД нужно остановить;
- Нечитаемый формат: нельзя посмотреть содержимое.
Логическая репликация
Логическая репликация — оптимальный метод миграции для большинства проектов. Она позволяет перенести БД с минимальным простоем — от нескольких минут до нуля.
Как работает
- Подготовка: на источнике включается логическая репликация (wal_level = logical для PostgreSQL);
- Начальная копия: создаётся снимок данных (initial sync);
- Репликация: изменения с источника непрерывно передаются на целевую БД;
- Переключение: в момент минимальной нагрузки приложение переключается на новую БД;
- Завершение: старая БД отключается.
Плюсы
- Минимальный простой: обычно секунды или минуты;
- Актуальность: данные синхронизированы в реальном времени;
- Безопасность: можно откатиться, если что-то пошло не так;
- Работает между версиями: PostgreSQL 13 → PostgreSQL 15.
Минусы
- Сложность: требует настройки публикаций и подписок;
- Ограничения: не все объекты реплицируются (DDL, sequences);
- Нагрузка: репликация создаёт дополнительную нагрузку на источник;
- Требует версии: PostgreSQL 10+, MySQL 5.7+.
CDC (Change Data Capture)
CDC — это метод, при котором изменения данных захватываются на уровне БД и передаются в целевую систему. Обычно используется через Debezium и Apache Kafka.
Как работает
- Захват изменений: Debezium читает WAL или binlog;
- Передача: изменения отправляются в Kafka;
- Применение: целевая БД применяет изменения;
- Масштабирование: можно передавать данные в несколько систем одновременно.
Когда использовать
- Большие объёмы данных: терабайты и более;
- Сложная архитектура: несколько целевых систем (БД + аналитика + поиск);
- Нулевой простой: когда нельзя останавливать приложение даже на минуту;
- Real-time синхронизация: нужна актуальность в секундах.
💡 Важно
CDC — сложный метод. Требует настройки Kafka и Debezium, мониторинга, обработки ошибок. Оправдан только для действительно крупных проектов.
Cutover без простоя
Cutover — это момент переключения приложения с источника на целевую БД. С помощью логической репликации можно свести простой к минимуму.
Порядок действий
- Синхронизация: убедиться, что целевая БД полностью синхронизирована;
- Остановка записи: приложение переводится в read-only режим;
- Дождаться lag: лаг репликации должен стать нулевым;
- Переключение: приложение подключается к целевой БД;
- Проверка: тестирование работы приложения на новой БД;
- Мониторинг: усиленное наблюдение 24–48 часов после cutover.
Для небольших БД cutover может занять 5–15 минут. Для крупных — до 30–60 минут.
Чек-лист миграции БД
Подготовка
- Полный бэкап источника
- Проверка версий СУБД
- Список extensions и ролей
- Оценка объёма данных
- План отката
Синхронизация
- Логическая репликация настроена
- Initial sync завершён
- Лаг репликации минимальный
- Мониторинг лага работает
- Обработка ошибок репликации
Cutover
- Окно миграции согласовано
- Приложение переведено в read-only
- Лаг равен нулю
- Переключение выполнено
- Приложение работает
После миграции
- Проверка целостности данных
- Мониторинг производительности
- Оптимизация запросов
- Настройка бэкапов
- Отключение старой БД
Ошибки
Нет полного бэкапа
Начинают миграцию без резервной копии. Если что-то идёт не так — нечем откатиться.
Забыли extensions
PostGIS, pgcrypto, uuid-ossp не мигрируют автоматически. Без них импорт падает.
Не учли sequences
После переноса данных sequences не сброшены. Первый же INSERT падает с ошибкой duplicate key.
Забыли про роли
Пользователи и права не мигрируют автоматически. Нужно создавать вручную.
Не тестировали cutover
Переключение «на живую». Нет плана отката, нет тестового прогона. Риск потерять данные.
Игнорировали лаг репликации
Переключились, когда лаг был 5 минут. Часть данных не доехала. Потеря заказов.
Нет мониторинга после
После миграции не следят за производительностью. Медленные запросы обнаруживаются поздно.
Забыли про PITR
Не настроили WAL-архивирование. Нет возможности восстановить БД на конкретный момент.
Наши рекомендации
📌 Что вы получаете, заказывая миграцию БД у нас
- Аудит — оценка БД, объёмов, версий
- Стратегию — под вашу СУБД
- План миграции — с cutover и откатом
- Перенос — минимальный простой
- Проверку данных — сверка, тесты
- Мониторинг — после миграции
📌 Итоговый вывод
Миграция баз данных — это самая сложная часть любого переезда в облако.
Что нужно знать:
- Методы — логические дампы, физические копии, репликация, CDC
- Логические дампы — до 100 ГБ, но долго
- Физические копии — быстро, но только одинаковая версия
- Логическая репликация — оптимальный выбор, минимальный простой
- CDC — для больших проектов и real-time синхронизации
- Cutover — переключение за 5–15 минут при правильной подготовке
- Ошибки — нет бэкапа, забыли extensions, sequences, роли, нет теста cutover
Хотите перенести БД? Закажите консультацию в Lead Hub.
Также рекомендуем: зачем переходить в облако, стратегии миграции, миграция между облаками, оптимизация расходов, ошибки при миграции, миграция в облако.