Миграция баз данных
Миграция базы данных — задача, с которой сталкивается каждый проект. Переезд на новый сервер, смена СУБД, обновление версии, переход в облако. Каждая миграция — это риск: потеря данных, простой, несовместимость. Но правильно спланированная миграция проходит без потерь и без остановки бизнеса.
Существует несколько подходов: логический дамп, физическая копия, репликация для нулевого простоя. Выбор зависит от объёма данных, требований к простою и совместимости версий. В этой статье — разбор методов миграции баз данных: что выбрать, как подготовиться, как избежать ошибок. Если нужно управляемое решение для БД — поможем.
Когда нужна миграция
Миграция баз данных — не самоцель. Она нужна в конкретных ситуациях.
Смена сервера
Переезд на новый сервер: мощнее, дешевле, ближе к пользователям. Обычно без смены СУБД.
Переход в облако
Локальная БД переезжает в managed-сервис. Меньше администрирования, больше гибкости.
Обновление версии
PostgreSQL 11 → 15, MySQL 5.7 → 8.0. Новые возможности, безопасность, производительность.
Смена СУБД
MySQL → PostgreSQL, Oracle → PostgreSQL. Миграция на более подходящую СУБД.
Типы миграции
Миграции делятся на две категории: гомогенные (одна СУБД) и гетерогенные (смена СУБД). Каждая имеет свои методы.
| Тип | Что меняется | Сложность | Метод |
|---|---|---|---|
| Гомогенная | Сервер, но не СУБД | Низкая | pg_dump, pg_basebackup, репликация |
| Гомогенная (версия) | Версия СУБД | Средняя | pg_dumpall, pg_upgrade |
| Гетерогенная | СУБД (MySQL → PG) | Высокая | pgloader, ora2pg |
| Гибридная | Сервер + СУБД | Высокая | Комбинация методов |
Логическая миграция
Логическая миграция — экспорт данных в виде SQL-команд и импорт на новом сервере. Основной метод для большинства проектов.
Как работает
- Экспорт: pg_dump создаёт файл с SQL-командами (CREATE TABLE, INSERT);
- Передача: файл переносится на новый сервер;
- Импорт: pg_restore или psql применяет команды к новой БД;
- Проверка: сверка количества записей, ключевых данных.
Плюсы
- Совместимость: работает между версиями и платформами;
- Гибкость: можно выборочно переносить данные;
- Прозрачность: SQL-файл можно прочитать;
- Простота: стандартные инструменты.
Минусы
- Простой: на время экспорта и импорта БД недоступна для записи;
- Медленно: для больших БД — часы;
- Нагрузка: экспорт создаёт нагрузку на сервер.
Физическая миграция
Физическая миграция — копирование файлов данных напрямую. Быстрее, но требует одинаковой версии и платформы.
Как работает
- Остановка БД: для консистентности нужно остановить PostgreSQL;
- Копирование: rsync или cp переносит файлы PGDATA;
- Запуск: новая БД запускается с скопированными данными;
- Проверка: убедиться, что всё работает.
Плюсы
- Скорость: быстрее логической миграции;
- Полнота: переносится всё состояние;
- Простота: одна команда rsync.
Минусы
- Одинаковая версия: не работает между разными версиями;
- Одинаковая платформа: Linux → Linux, но не Linux → Windows;
- Простой: БД нужно остановить;
- Права: нужно правильно настроить владельцев файлов.
Репликация для нулевого простоя
Самый продвинутый метод — логическая репликация. Позволяет перенести БД с минимальным простоем или вообще без него.
Как работает
- Подготовка: на источнике включается wal_level = logical;
- Начальная копия: создаётся базовый снимок данных;
- Репликация: изменения с источника непрерывно передаются на цель;
- Переключение: в момент минимальной нагрузки приложение переключается на новую БД;
- Завершение: старая БД отключается.
Плюсы
- Минимальный простой: секунды или минуты;
- Актуальность: данные синхронизированы в реальном времени;
- Безопасность: можно откатиться, если что-то пошло не так.
Минусы
- Сложность: требует настройки публикаций и подписок;
- Ограничения: не все объекты реплицируются (DDL, sequences);
- Нагрузка: репликация создаёт дополнительную нагрузку на источник.
Смена СУБД
Миграция между разными СУБД — самая сложная. Требуется конвертация схемы, типов данных, запросов.
Инструменты
- pgloader: MySQL → PostgreSQL, автоматическая конвертация;
- ora2pg: Oracle → PostgreSQL, конвертация схемы и данных;
- Ручная конвертация: для сложных случаев, кастомные скрипты.
Что конвертировать
- Типы данных: TINYINT → BOOLEAN, DATETIME → TIMESTAMP;
- Автоинкремент: AUTO_INCREMENT → SERIAL;
- Синтаксис: различия в функциях, операторах, конструкциях;
- Индексы: PostgreSQL не создаёт автоматические индексы для FK;
- JSON: MySQL JSON не валидируется, PostgreSQL — валидирует.
💡 Важно
Гетерогенная миграция требует тестирования на копии данных. Нельзя мигрировать «вслепую» — возможны несовместимости типов и запросов, которые проявятся только на реальных данных.
Чек-лист миграции
Подготовка
- Инвентаризация БД
- Оценка объёма данных
- Проверка версий
- Список extensions
- План отката
Экспорт
- Полный бэкап
- Экспорт схемы
- Экспорт данных
- Экспорт ролей
- Экспорт extensions
Импорт
- Создание БД
- Установка extensions
- Импорт схемы
- Импорт данных
- Настройка прав
Проверка
- Количество записей
- Ключевые данные
- Работа приложения
- Производительность
- Мониторинг
Типичные ошибки
Нет бэкапа перед миграцией
Если миграция пойдёт не так — нечем откатиться. Всегда делайте полный бэкап перед началом.
Не проверены extensions
PostGIS, pgcrypto, uuid-ossp не мигрируют автоматически. Без них импорт упадёт.
Игнорирование версий
pg_dump между разными версиями может выдать несовместимый SQL. Проверяйте совместимость.
Тестирование на продакшене
Миграция без предварительного теста на копии — риск потери данных и простоя.
Забыли про роли
Пользователи и права не мигрируют автоматически. Их нужно создавать вручную.
Нет плана отката
Если что-то пойдёт не так — нужно вернуться. Без плана отката миграция превращается в авантюру.
Наши рекомендации
📌 Что вы получаете, заказывая миграцию БД у нас
- Аудит — оценка объёма, версий, рисков
- План миграции — пошаговый, с откатом
- Тестовую миграцию — на копии данных
- Перенос без потерь — логический или репликация
- Проверку данных — сверка записей, тесты
- Поддержку — после миграции
🔹 Оставьте заявку на миграцию БД
Хотите перенести базу без потерь? Оставьте заявку — поможем с миграцией.
📌 Итоговый вывод
Миграция баз данных — это управляемый процесс, если подойти с планом.
Что нужно знать:
- Логическая миграция — pg_dump/pg_restore, совместимость, простой
- Физическая миграция — быстро, но требует одинаковой версии
- Репликация — нулевой простой, для критичных систем
- Смена СУБД — pgloader, ora2pg, конвертация типов
- Чек-лист — подготовка, экспорт, импорт, проверка
- Ошибки — нет бэкапа, extensions, версии, роли
Хотите перенести БД? Закажите консультацию в Lead Hub.
Также рекомендуем: PostgreSQL vs MySQL, резервное копирование БД, безопасность БД, масштабирование БД, как выбрать БД, базы данных.