К основному содержимому

Как перенести базу данных MySQL на новый сервер

Миграция · 15.01.2025 · 6 мин чтения
Иллюстрация к статье «Как перенести базу данных MySQL на новый сервер»

Порядок действий, который не роняет сайт

Перенос базы данных — не «выгрузил-загрузил», а последовательность с точками проверки. Если менять порядок, сайт либо ляжет на время переноса, либо начнёт писать данные в базу, которая скоро исчезнет.

  1. Переведите сайт в режим только для чтения или предупредите пользователей о техработах — новые записи, сделанные во время экспорта, в дамп не попадут.
  2. Снимите дамп на старом сервере командой mysqldump с флагом согласованности.
  3. Передайте файл на новый сервер и импортируйте его в пустую базу.
  4. Проверьте базу на новом сервере через файл hosts, не трогая DNS домена.
  5. Только после успешной проверки переключайте домен и обновляйте конфиг сайта.

Экспорт: mysqldump с нужными флагами

База меньше 1 ГБ

mysqldump -u user -p --single-transaction --routines --triggers database_name > dump.sql

--single-transaction делает снимок без блокировки таблиц (важно для InnoDB), --routines и --triggers добавляют хранимые процедуры и триггеры, которые обычный дамп пропускает.

База больше 5 ГБ

mysqldump -u user -p --single-transaction --quick --compress database_name | gzip > dump.sql.gz

--quick читает строки по одной, а не грузит всю таблицу в память, --compress сжимает трафик между клиентом и сервером MySQL, а внешний gzip уменьшает сам файл в 5–10 раз.

Только нужные таблицы

mysqldump -u user -p database_name table1 table2 > partial.sql

Передача дампа на новый сервер

Через scp

scp dump.sql.gz root@new-server-ip:/root/

Напрямую по SSH, без файла на диске

mysqldump -u user -p --single-transaction database_name | gzip | ssh root@new-server-ip "gunzip | mysql -u user -p database_name"

Такой конвейер экономит место на обоих серверах и время: не нужно ждать, пока файл полностью запишется, прежде чем начать передачу.

Импорт на новом сервере

gunzip < dump.sql.gz | mysql -u user -p database_name

Сравнение способов переноса

СпособПрактический лимитПростой сайтаКогда использовать
phpMyAdmin (экспорт/импорт файла)до 50–100 МБминутымаленькие сайты, нет доступа к SSH
mysqldump в файл + scpдо нескольких ГБминуты — часыесть SSH, база умеренного размера
Прямой pipe по SSHограничен только скоростью каналаминуты — часыбольшие базы, мало места на диске

Проверка на новом сервере до переключения DNS

Перед сменой DNS проверьте сайт на новом IP, подменив адрес домена только на своём компьютере.

echo "203.0.113.10 example.com www.example.com" | sudo tee -a /etc/hosts

После этого откройте сайт в браузере как обычно — он обратится по домену, но получит ответ с нового сервера. Так же можно проверить без правки hosts, передав заголовок Host напрямую:

curl -H "Host: example.com" http://203.0.113.10/

Не забудьте удалить строку из /etc/hosts после проверки, иначе продолжите видеть старую версию даже после реального переключения DNS.

Типичные ошибки при импорте

СообщениеПричина и решение
ERROR 1044 (42000): Access denied for userПользователь MySQL не имеет прав на целевую базу — выдайте GRANT ALL на неё под нужным пользователем
ERROR 2006 (HY000): MySQL server has gone awayДамп содержит строку больше max_allowed_packet — увеличьте параметр в my.cnf на новом сервере
ERROR 1046 (3D000): No database selectedВ дампе нет USE database_name — создайте базу заранее и импортируйте с явным указанием её имени
Unknown collation: 'utf8mb4_0900_ai_ci'Версия MySQL на новом сервере старше — либо обновите сервер, либо замените имя collation в дампе на поддерживаемое

Откат, если что-то пошло не так

  1. Не удаляйте старую базу и старый сервер, пока новый не отработал минимум сутки под реальной нагрузкой.
  2. Если после переключения DNS сайт ведёт себя нестабильно, верните старые A-записи — они начнут действовать по мере истечения TTL.
  3. Разберитесь с проблемой на новом сервере в спокойном режиме, затем повторите миграцию.

Когда этот способ не подходит

Для баз крупнее 20–30 ГБ обычный mysqldump занимает часы и держит сайт в простое всё это время. В таком случае используйте репликацию master-slave для первичной синхронизации без остановки сайта, а mysqldump — только для финальной сверки небольшого числа изменившихся строк.

Проверка результата

  • Сравните количество таблиц: SHOW TABLES; на старом и новом сервере должно дать одинаковый список.
  • Сравните число строк в ключевых таблицах: SELECT COUNT(*) FROM orders; и аналогично для других важных таблиц.
  • Запустите mysqlcheck -u user -p --all-databases на новом сервере — команда проверяет целостность таблиц.
  • Откройте сайт через подмену hosts и проверьте ключевые страницы: логин, оформление заказа, админку.

Подробный чек-лист общей проверки сайта после переноса — в статье проверка после миграции, а порядок безопасного отката — в статье план отката миграции.

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

Обязательно ли полностью останавливать сайт на время переноса базы, или достаточно режима только для чтения?

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

Что делать, если снятие дампа занимает слишком долго и мешает боевой базе работать нормально?

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

Можно ли перенести только часть таблиц базы, а не всю базу целиком?

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

Что делать, если после переноса число строк в таблицах на новом сервере не совпадает со старым?

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

Статья помогла?
← Назад в базу знаний Задать вопрос поддержке