Сначала узнайте версии MySQL, размер базы, движки таблиц, кодировку, пользователей, процедуры, триггеры и размер бинарных логов. Файлы приложения и содержимое базы - отдельные части переноса. Если хостинг управляет MySQL, уточните внешние соединения, права и доступный способ импорта. Начните с копии.

Выберите метод по допустимому перерыву

СитуацияВозможный путьЧто проверить
Небольшая база и согласованное окноЛогический dump и восстановлениеВерсии клиента/сервера, размер архива, пользователи
Большая база и продолжающиеся записиПервичное копирование плюс репликацияБинарные логи, версия, привилегии, задержка реплики
Управляемая базаИнструмент провайдера или услуга миграцииЧто входит, кто переключает запись, как откатывать

MySQL 8.4 описывает mysqldump как инструмент логического резервирования: он формирует SQL для воссоздания объектов и данных. Для больших объемов восстановление SQL может занять заметное время. В документации отдельно оговорено, что пример online backup зависит от InnoDB и включает краткую глобальную блокировку в начале процесса.

Проверьте восстановление на копии

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

Запишите длительность выгрузки и загрузки, ошибки и версию обеих сторон. Проверьте, куда попали пользователи и права, если они не включены в выбранный dump. Исходную базу сохраняйте до сверки результатов и рабочего возврата. Отдельная копия не должна оставаться только на том же сервере.

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

Когда используют репликацию

По обзору MySQL Replication, проверенному 8 октября 2026 года, репликация по умолчанию асинхронна: сервер-источник не ждет применения каждой записи на реплике. Поэтому для переключения надо проверить отставание, согласовать остановку записи или другой механизм синхронизации и лишь затем менять endpoint приложения.

Документация MySQL по смене источника объясняет, что реплика начинает читать журнал с заданных координат. Сервер сам не сверяет совместимость баз. Нужны корректные GTID либо позиции бинарного лога, версии и права. Схема зависит от используемой конфигурации.

Такой план может сократить перерыв, но не доказывает нулевой простой. Финальная проверка должна подтвердить, что все нужные транзакции применены и приложение пишет уже в целевой экземпляр. Обратное переключение после появления новых записей тоже требует плана, а не простого возврата DNS. Не у всех схем есть быстрый откат.

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