Миграция базы данных между серверами

MAATRIX

База — самое ценное и самое хрупкое, что есть на сервере. Потерять пару файлов сайта не страшно, а вот повреждённый при переносе дамп или пропавшие за время миграции заказы обходятся дорого. Хорошая новость: миграция базы данных между серверами — задача с отработанной процедурой, где риск сводится почти к нулю, если действовать по шагам. Ниже практическое решение проблемы переноса для MySQL, MariaDB и PostgreSQL: как снять дамп, доставить его и импортировать, ничего не потеряв.

Быстрое решение: дамп, перенос, импорт

В основе любой миграции — три шага: выгрузить базу в файл-дамп, передать его на новый сервер, загрузить обратно. Для MySQL и MariaDB это выглядит так:

# на старом сервере: логический дамп с согласованным снимком
mysqldump -u root -p --single-transaction --routines --triggers mydb > mydb.sql
# передаём на новый сервер
scp mydb.sql root@НОВЫЙ_IP:/root/
# на новом сервере: создаём базу и импортируем
mysql -u root -p -e "CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci"
mysql -u root -p mydb < mydb.sql

Для PostgreSQL логика та же, но инструменты свои — pg_dump и pg_restore или psql:

# дамп в кастомном формате (сжатый, гибкий при восстановлении)
pg_dump -U postgres -Fc mydb > mydb.dump
# на новом сервере
createdb -U postgres mydb
pg_restore -U postgres -d mydb mydb.dump

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

Логический дамп против физического

Есть два способа переноса, и выбор зависит от размера. Логический дамп (mysqldump, pg_dump) выгружает базу в набор SQL-команд. Он универсален, переносит данные между разными версиями и даже разными ОС, легко читается и правится. Минус — на больших базах он медленный и при импорте нагружает сервер: каждая строка вставляется заново с перестроением индексов.

Физический перенос копирует сами файлы базы данных. Он в разы быстрее на объёмах в десятки и сотни гигабайт, но требует совпадения версий СУБД и остановки базы или снятия консистентного снимка. Для MySQL это, например, Percona XtraBackup, для PostgreSQL — копирование каталога данных с pg_basebackup. Практическое правило: до нескольких гигабайт берите логический дамп ради простоты, на десятках гигабайт и выше смотрите в сторону физического переноса ради скорости.

Переносим без блокировки боевой базы

Главный страх при миграции живого проекта — что на время дампа база «встанет» и пользователи получат ошибки. Этого не происходит, если снимать согласованный снимок без блокировки таблиц. В MySQL за это отвечает флаг --single-transaction (работает для движка InnoDB): дамп берётся из одной транзакции, отражающей состояние базы на момент старта, а запись продолжается параллельно.

mysqldump -u root -p --single-transaction --quick --routines --triggers mydb > mydb.sql

Флаг --quick заставляет выгружать строки по одной, не собирая всю таблицу в память, — это спасает на больших таблицах. В PostgreSQL pg_dump по умолчанию работает в согласованном снапшоте и не мешает записи. Так что снять дамп с работающей боевой базы безопасно — при условии, что вы не забыли про процедуры, триггеры и функции, которые в базовый дамп по умолчанию могут не попасть.

Не теряем данные, накопленные за время переезда

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

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

Проверяем целостность после импорта

Импорт прошёл без ошибок — это ещё не гарантия, что данные доехали полностью. Обязательно сверьте. Самая базовая проверка — количество строк в ключевых таблицах на старом и новом сервере должно совпадать:

# на обоих серверах
mysql -u root -p -e "SELECT COUNT(*) FROM mydb.orders"
mysql -u root -p -e "SELECT COUNT(*) FROM mydb.users"

Проверьте кодировку — сбитая кодировка проявляется «кракозябрами» в тексте и часто всплывает уже на глазах у пользователей. Убедитесь, что перенеслись не только таблицы, но и индексы, внешние ключи, триггеры и права доступа. Полезно прогнать приложение на тестовом контуре против новой базы до переключения: реальные запросы вскроют то, что глазами не увидеть. Только после этой проверки можно считать миграцию завершённой.

Частые причины проблем и как их избежать

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

Ещё одна тихая причина — забытые объекты: хранимые процедуры, триггеры, представления, пользователи и их права. Базовый дамп таблиц их не всегда включает, поэтому используйте флаги вроде --routines --triggers и отдельно переносите учётные записи. Проверив этот список до начала, вы избавите себя от разбирательств «база есть, а приложение падает».

Профилактика и удобная площадка

Чтобы миграции всегда проходили гладко, держите под рукой свежие бэкапы и регулярно проверяйте, что они восстанавливаются, — бэкап, который ни разу не разворачивали, это лотерея. Документируйте версии СУБД и параметры конфигурации, тогда воспроизвести окружение на новом сервере будет тривиально. Автоматизируйте дамп по расписанию с выгрузкой на отдельное хранилище.

Отдельно стоит подумать о ресурсах целевого сервера: базе нужны быстрый диск (лучше NVMe) и достаточно оперативной памяти под кэш, иначе после переезда вы получите просевшую производительность. У MAATRIX можно подобрать VPS под базу в нужной локации — RU для минимального пинга до российской аудитории, US или UK под зарубежные проекты — с оплатой из России картой или криптой. Это снимает вопрос подготовки площадки и позволяет сосредоточиться на самой миграции.

Частые вопросы