Миграция MySQL dump на новый сервер

Миграция через dump — прямой путь перенести данные PHP-скрипта: экспорт на старом сервере, файл на новый, импорт в пустую базу, правка конфига. Без дампа перенос файлов даёт пустой каркас. Полный переезд сайта (файлы+DNS): перенос скрипта.

Работает одинаково с локалки MicroServer на хостинг и с Beget на VDS. Меняются только способы забрать файл.

Экспорт на источнике

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

На shared без SSH — phpMyAdmin → Экспорт, или бэкап в панели. Следите, чтобы файл скачался целиком: в конце дампа обычно строки вроде завершения транзакций, не обрыв на середине CREATE TABLE.

Перед экспортом желательно короткое окно без активных заказов/публикаций, если боитесь расхождений. Для InnoDB --single-transaction уменьшает боль с блокировками.

Рабочий ритуал копий: бэкап PHP и MySQL.

Подготовка на новом сервере

1. Создайте пустую базу utf8mb4.
2. Создайте пользователя и выдайте права на эту базу (CREATE/INSERT/…).
3. Проверьте, что MySQL слушает и доступен с хоста, где PHP — обычно localhost.

Требования: PHP/MySQL. Локально базу удобно завести так: phpMyAdmin.

Импорт

mysql -u user -p newdb < dump.sql

Через phpMyAdmin — вкладка Импорт. Большой файл упрётся в upload_max_filesize / таймауты — тогда только CLI или загрузка дампа в каталог и импорт из консоли.

Ошибки импорта:

• Access denied — не те логин/права.
• Unknown collation / charset — старый сервер vs новый; чаще лечится utf8mb4 на обеих сторонах.
• Table exists — база не пустая; очистите или создайте новую.
• Packet too large — поднимите max_allowed_packet.

Конфиг скрипта

Пропишите новый хост, имя БД, пользователя, пароль. Старые значения с предыдущего сервера — главная причина «перенёс дамп, сайт 500». Симптомы: ошибка базы, 500.

URL сайта в настройках/таблицах опций обновите, если домен менялся. Иначе картинки и редиректы смотрят на старый хост.

Пользователи MySQL не переезжают «как есть»

Дамп базы данных обычно не включает серверных пользователей MySQL (кроме специальных режимов). На новом сервере учётки создаёте заново и выдаёте гранты. Пароль в конфиге скрипта = пароль новой учётки.

Версии MySQL/MariaDB

С 5.7 на 8.0 обычно ок. Обратно с 8 на очень старый 5.5 — боль. Смотрите sql_mode, если импорт ругается на нулевые даты — иногда в дампе старые умолчания. Не глушите sql_mode глобально без понимания; лучше поправить данные.

После импорта — проверка

• Число таблиц совпало с источником.
• Главная и кабинет открываются.
• Свежая запись (объявление/заказ) пишется.
• Кириллица не превратилась в «???».

Файлы загрузок переносятся архивом отдельно — дамп их не содержит. Права: chmod.

Автоматизация

На VDS можно сложить связку: ночной dump + копирование на другой узел. Не забудьте ротацию файлов и проверку размера. Firewall на приёмнике: firewall. Стек веба: Nginx + PHP-FPM.

Установка с нуля без переноса данных: установка. Если что-то встало на середине миграции — тикет с текстом ошибки импорта: поддержка.

Сжатие дампа

Большой sql удобно жать:

mysqldump ... | gzip > dump.sql.gz
gunzip -c dump.sql.gz | mysql -u user -p newdb

На Windows с MicroServer можно получить дамп через phpMyAdmin и сжать 7-Zip. Главное не повредить файл при пересылке по ASCII-ftp — только бинарный режим.

Триггеры, процедуры, VIEW

Если продукт использует routines, в mysqldump нужен --routines. Без него часть логики на новом сервере исчезнет, а ошибки всплывут не сразу. VIEW с definer пользователя, которого нет на новом сервере, тоже болеют — правите definer или создаёте пользователя с тем же именем.

Часовые пояса и sql_mode

После переноса «время заказов съехало на три часа» — разный time_zone у MySQL или PHP. Сверьте date.timezone в php.ini и часовой пояс в админке скрипта. Это не всегда битый дамп.

Строгий sql_mode на MySQL 8 может отвергнуть старые нулевые даты. Тогда импорт падает на конкретной строке. Варианты: поправить данные, временно ослабить mode на сессию импорта, понять цену решения. Не оставляйте ослабленный mode навсегда без причины.

Частичный перенос

Иногда тащат только таблицы ядра без логов. Имеет смысл на огромных access_log таблицах. Не отрежьте случайно таблицы связей. Список таблиц сверьте со свежей установкой того же продукта: установка на пустую БД покажет эталон набора.

Проверка контрольными суммами

На важных переездах сравните число строк в ключевых таблицах до и после (users, orders, ads — по продукту). Расхождение сразу после импорта = оборванный файл или импорт не в ту базу. Тихий провал хуже громкого.

Откат миграции

Пока DNS не переключён, старый сервер ещё источник правды. Новый можно перезаливать хоть трижды. После переключения DNS держите старый сервер read-only или выключенным для записи (cron off!), иначе появятся новые заказы «в никуда». Порядок переезда сайта: перенос скрипта. Бэкап до старта: бэкап.

Права файлов после выкладки: chmod. Если сайт 500 сразу после смены конфига — ошибка 500, ошибка базы. Локальная репетиция: MicroServer, phpMyAdmin.

Не импортируйте дамп в базу, где уже стоит другой проект «временно». Префиксы таблиц могут совпасть и вы затрёте чужое. Лучше создать новое имя БД и поменять только конфиг нужного сайта. На shared префиксы вроде u12345_ обязательны — не переименовывайте базу в панели так, чтобы отвалился пользователь: пересоздайте гранты. После миграции имеет смысл пройтись по админке: счётчики, последние заказы/объявления, одна картинка. Если цифры нулевые при живых таблицах — смотрите, не подключились ли к пустой БД-тёзке. Требования к кодировке: требования. Полный переезд сайта: перенос. Бэкап до эксперимента: бэкап. Выбор сервера под переезд: VDS или хостинг. Если после импорта снова Access denied — ошибка базы.