*Cube-Host– облачный хостинг!!

Миграция базы данных MySQL: пошаговый и безопасный метод

MySQL database migration: a step-by-step and secure method

Миграция базы данных MySQL — это операция, имеющая серьезные последствия: она влияет на целостность данных, время безотказной работы приложений и безопасность отката. В этом руководстве представлен проверенный на практике алгоритм миграции с использованием mysqldump (наиболее универсального инструмента) и объясняется, как сократить время простоя с помощью «финальной синхронизации» или репликации.

Чаще всего MySQL размещается на VPS под управлением Linux, но миграция может затрагивать и приложения на VPS под управлением Windows. В любом случае стабильная производительность сети и дисков, обеспечиваемая вашим провайдером VPS-хостинга, делает миграцию быстрее и безопаснее.

Когда необходима миграция

  • Переход на новый сервер/провайдера.
  • Обновление версии MySQL/MariaDB (или смена дистрибутива).
  • Разделение базы данных и сервера приложений для повышения производительности.
  • Подготовка к репликации, отработке отказа или масштабированию чтения.
  • Миграция хранилища (HDD → SSD/NVMe, изменение размера томов).

Риски и способы их минимизации

  • Различия между версиями: изменения sql_mode, плагин аутентификации по умолчанию и настройки сортировки по умолчанию могут привести к сбоям приложений после миграции.
  • Несоответствие кодировки/сортировки: сортировки utf8mb4 различаются между версиями (особенно между MySQL 5.7 и 8.0).
  • Неперенесенные привилегии/пользователи: пользователи не входят в дамп одной базы данных, если вы не переносите их специально.
  • Несогласованность дампа: дамп, созданный во время интенсивной записи, может стать логически несогласованным, если не использовать правильные параметры.
  • Время простоя: если вы переходите без окончательного плана синхронизации, вы рискуете потерей данных или длительными окнами технического обслуживания.

Контрольный список перед миграцией (сделайте это в первую очередь)

  • Уточните версии источника и назначения: MySQL против MariaDB, основные/второстепенные версии.
  • Запишите настройки сервера: sql_mode, lower_case_table_names, часовой пояс и настройки InnoDB.
  • Убедитесь в использовании механизма хранения (InnoDB или MyISAM).
  • Оцените объем данных и ожидаемое время дампа (важен дисковый ввод-вывод).
  • Определите стратегию простоя: короткий простой (окончательная синхронизация) или практически нулевой простой (репликация).
  • Подготовьте откат: сохраните старый сервер в рабочем состоянии до полной проверки работоспособности производственной среды.

Команды для быстрой инвентаризации (запускаются на исходном сервере):

# MySQL version
mysql -V

# Server variables that often matter during migration
mysql -u root -p -e "SHOW VARIABLES LIKE 'version%'; SHOW VARIABLES LIKE 'sql_mode'; SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'collation_server'; SHOW VARIABLES LIKE 'default_authentication_plugin';"

# Database sizes
mysql -u root -p -e "SELECT table_schema AS db, ROUND(SUM(data_length index_length)/1024/1024,2) AS size_mb FROM information_schema.tables GROUP BY table_schema ORDER BY size_mb DESC;"

Выберите метод миграции

Метод A: Логический экспорт/импорт (mysqldump) — наиболее универсальный

Лучше всего подходит для баз данных небольшого и среднего размера и является самым безопасным вариантом при переходе между версиями. Вы экспортируете SQL (схему и данные) и импортируете их на новый сервер. Для очень больших наборов данных этот метод работает медленнее, чем физические методы, но он предсказуем и позволяет легко выполнить откат.

Метод B: переключение с помощью репликации — минимальное время простоя

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

Метод C: Физическое резервное копирование/восстановление (для опытных пользователей)

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

Пошаговая миграция с использованием mysqldump (безопасная базовая линия)

Шаг 1 — Создание согласованного дампа (исходный сервер)

Для InnoDB используйте --single-transaction , чтобы избежать блокировки таблиц. Также включите процедуры, триггеры и события, чтобы не потерять логику приложения.

# Example: dump ONE database with compression
# Use -p to enter password interactively (safer than putting it in the command line)
mysqldump -u root -p 
  --single-transaction --quick 
  --routines --triggers --events 
  --hex-blob 
  --default-character-set=utf8mb4 
  olddb | gzip > olddb-$(date  %F).sql.gz

Если у вас есть таблицы MyISAM: --single-transaction не обеспечивает полную защиту согласованности для MyISAM. Рассмотрите возможность запланировать время простоя или использовать стратегию блокировки на чтение во время дампа (поскольку MyISAM не является транзакционным).

Необязательно: выполните дамп нескольких баз данных (явное указание):

mysqldump -u root -p 
  --single-transaction --quick 
  --routines --triggers --events 
  --databases db1 db2 db3 | gzip > dbs-$(date  %F).sql.gz

Шаг 2 — Безопасная передача дампа

Используйте SCP или rsync через SSH. Проверьте целостность с помощью контрольной суммы.

# Create checksum on source
sha256sum olddb-2025-08-01.sql.gz > olddb-2025-08-01.sql.gz.sha256

# Transfer to destination
scp olddb-2025-08-01.sql.gz olddb-2025-08-01.sql.gz.sha256 user@NEW_SERVER_IP:/tmp/

В месте назначения проверьте:

cd /tmp
sha256sum -c olddb-2025-08-01.sql.gz.sha256

Шаг 3 — Создание базы данных с правильным набором символов/сортировкой

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

# Check source defaults
mysql -u root -p -e "SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME FROM information_schema.SCHEMATA WHERE SCHEMA_NAME='olddb';"

Создайте на месте назначения:

mysql -u root -p -e "CREATE DATABASE olddb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"

Шаг 4 — Импорт дампа (сервер назначения)

# Import compressed dump
gunzip -c /tmp/olddb-2025-08-01.sql.gz | mysql -u root -p olddb

Совет для импорта больших объемов данных: запустите процесс в сеансе screen/tmux и убедитесь, что на месте назначения достаточно места на диске для журналов и временных файлов.

Шаг 5 — Перенос пользователей и прав доступа (НЕ пропускайте)

Объектов базы данных (таблиц) недостаточно — необходимо заново создать учетные записи пользователей приложения и права доступа.

На исходном сервере перечислите несистемных пользователей:

mysql -u root -p -e "SELECT user, host FROM mysql.user WHERE user NOT IN ('mysql.sys','mysql.session','mysql.infoschema') ORDER BY user, host;"

Для каждого пользователя приложения (пример: appuser), экспортируйте определения:

mysql -u root -p -e "SHOW CREATE USER 'appuser'@'%';"
mysql -u root -p -e "SHOW GRANTS FOR 'appuser'@'%';"

Затем воссоздайте их на целевом сервере. Пример (подстройте plugin/password под вашу среду):

# Example: create user and grant permissions
mysql -u root -p -e "CREATE USER 'appuser'@'%' IDENTIFIED BY 'STRONG_PASSWORD_HERE';"
mysql -u root -p -e "GRANT ALL PRIVILEGES ON olddb.* TO 'appuser'@'%'; FLUSH PRIVILEGES;"

Примечание по совместимости: по умолчанию MySQL 8 использует caching_sha2_password. Некоторые старые клиенты требуют mysql_native_password. Если ваше приложение устарело, запланируйте это перед переходом (но по возможности используйте современную аутентификацию).

Шаг 6 — Проверьте целостность перед переходом в производственную среду

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

# Compare table counts by schema
mysql -u root -p -e "SELECT table_name, table_rows FROM information_schema.tables WHERE table_schema='olddb' ORDER BY table_rows DESC LIMIT 20;"

Для более тщательной проверки (рекомендуется для критически важных систем):

  • Проведите экспресс-тестирование приложения на новой БД (вход в систему, создание объекта, чтение/запись).
  • Проверьте медленные запросы и журналы ошибок после импорта.
  • Если вы используете Percona Toolkit, для больших наборов данных идеально подходят сравнения контрольных сумм.

Как минимизировать время простоя (практический план перехода)

Если вы не используете репликацию, наиболее распространенным «безопасным» подходом является короткое окно обслуживания:

  1. Объявите о периоде технического обслуживания и остановите запись данных в приложении (режим обслуживания).
  2. Сделайте финальный дамп (меньшего размера, если большая часть данных уже была перенесена ранее).
  3. Импортируйте финальный дамп в место назначения.
  4. Переключите конфигурацию приложения / DNS на новый конечный узел БД.
  5. Отслеживайте ошибки и производительность; сохраните старую БД в неизменном виде для отката.

Правила безопасности (не открывайте MySQL)

  • Не открывайте MySQL для общего доступа в Интернете, если это не является абсолютно необходимым.
  • Ограничьте доступ к порту 3306 по IP (только для сервера приложения) или используйте SSH-туннель/VPN.
  • Используйте учетные записи с минимальными привилегиями (без прав root для приложений).
  • Шифруйте резервные копии и контролируйте доступ к файлам дампа.
  • Храните резервные копии на отдельном хранилище и тестируйте восстановление.

Заключение

Безопасная миграция базы данных MySQL сводится к согласованности (правильные параметры дампа), безопасности (безопасная передача, ограниченный доступ) и проверке (проверки перед переключением). Большинство команд запускают MySQL на VPS под Linux, но миграции часто затрагивают приложения на VPS под Windows. При наличии стабильных ресурсов VPS-хостинга и четкого плана миграции становятся предсказуемыми и повторяемыми.

Prev
Menu