Обновление MySQL между мажорными версиями — полный гайд

• RANK
• GROUPS
• VALUE
• SYSTEM

MySQL 8.0 → 8.4:

• mysql_native_password плагин отключён по умолчанию.
• Ряд системных переменных удалены или переименованы.

Почему важна проверка совместимости?

Перед обновлением обязательно выполняем mysqlcheck и MySQL Shell Upgrade Checker — инструмент, рекомендованный Oracle для выявления проблем до миграции. Как отмечается в документации MySQL: «Перед обновлением обязательно выполните MySQL Shell Upgrade Checker».

mysqlcheck --all-databases --user=root --password --check-upgrade
mysqlsh root@localhost -e "util.checkForServerUpgrade('root@localhost:3306', {targetVersion: '8.0'})"

Shell Upgrade Checker находит:

• Таблицы с несовместимыми типами данных
• Использование удалённых/изменённых функций SQL
• Конфигурационные параметры, которые изменились
• Проблемные имена (зарезервированные слова)
• Таблицы в устаревшем ROW_FORMAT

Типичный вывод для базы с проблемами:

1) Usage of old temporal type - table mydb.events: column event_time is using old temporal type
2) Usage of reserved keywords - table mydb.rank: 'rank' is a reserved keyword in MySQL 8.0
3) Tables with non-native partitioning - table mydb.logs uses MySQL 5.1 style partitioning (upgrade required)

Каждый пункт нужно исправить до обновления, иначе mysql_upgrade или сервер сам откажется стартовать.

Обновление MySQL между мажорными версиями: какую стратегию выбрать?

In-place upgrade — подходит для некритичных сред, небольших баз. Остановить MySQL 5.7, установить MySQL 8.0 поверх, запустить. Это быстрее в 5 раз, чем dump/restore, но рискованнее — нет отката.

Логическая миграция через dump — надёжно, но требует даунтайма, пропорционального объёму базы. Для больших БД (500+ ГБ) даунтайм может достигать суток, поэтому лучше использовать репликацию.

Репликация для zero-downtime — поднять MySQL 8.0 как replica к существующему MySQL 5.7. MySQL 8.0 может быть репликой к 5.7 (обратное — нет). Синхронизировать данные через репликацию, переключить приложение на новый сервер, потом удалить старый. Этот метод снижает даунтайм до секунд — в 100 раз лучше, чем in-place.

# Пример: настройка репликации на MySQL 8.0
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='10.0.0.1',
  SOURCE_USER='repl',
  SOURCE_PASSWORD='password',
  SOURCE_AUTO_POSITION=1;
START REPLICA;

Эта стратегия требует, чтобы MySQL 5.7 имел GTID включён. Если нет — используем SOURCE_LOG_FILE/POS.

Что проверить после обновления?

Убедитесь, что все таблицы конвертированы: выполните SELECT table_schema, table_name, row_format FROM information_schema.tables WHERE engine='InnoDB' AND row_format NOT IN ('Dynamic', 'Compressed') AND table_schema NOT IN ('mysql','information_schema','performance_schema','sys');

Проверьте аутентификационные плагины: SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';

Обновите пользователей на caching_sha2_password (если клиенты поддерживают): ALTER USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY 'password'; Или оставьте legacy-клиентам mysql_native_password.

Какие параметры конфигурации нужно обновить?

Некоторые параметры, работавшие в 5.7, в 8.0 вызывают ошибку или игнорируются. Удалите из my.cnf:

• innodb_log_checksums (всегда включено)
• innodb_locks_unsafe_for_binlog (удалён)
• query_cache_size, query_cache_type (query cache удалён в 8.0)
• expire_logs_days → заменён на binlog_expire_logs_seconds

MySQL 8.0 не запустится если в my.cnf есть неизвестные переменные. Shell Upgrade Checker находит их заранее.

Как мы выполняем миграцию

Наш процесс основан на многолетнем опыте — более 50 проектов по миграции MySQL. Вот типичные этапы:

1. Аудит совместимости: запускаем Upgrade Checker, проверяем схему, конфигурацию, клиентские библиотеки.
2. Выбор стратегии: определяем, подходит ли in-place, dump/restore или репликация, с учётом ваших SLA.
3. Создание тестовой среды: разворачиваем копию базы, выполняем тестовую миграцию, проверяем ошибки.
4. Подготовка отката: настраиваем бекап, сохраняем конфигурацию.
5. Миграция в продакшн: выполняем по плану, мониторим метрики.
6. Пост-миграционное тестирование: проверяем производительность, функциональность, ошибки.
7. Документирование: фиксируем изменения, обновляем runbook, обучаем вашу команду.

Что входит в услугу — обновление mysql между

• Аудит совместимости и отчёт
• Выбор стратегии обновления
• Создание тестовой среды и тестовая миграция
• Разработка плана отката
• Выполнение миграции в продакшн
• Пост-миграционное тестирование и оптимизация
• Документирование изменений и обновление runbook
• Поддержка в течение недели после обновления

Сроки и стоимость

Стоимость рассчитывается индивидуально после аудита текущей версии, объёма базы и требований к даунтайму. Экономия на лицензиях при переходе с MySQL 5.7 на 8.0 может достигать 30%. Стоимость часа простоя для среднего бизнеса — около $450–650. Инвестиции в обновление окупаются за счёт снижения рисков и лицензионных затрат. Для предварительной оценки оставьте заявку.

Экстренный откат

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

Свяжитесь с нами для консультации — оценим ваш проект в течение дня. Получите коммерческое предложение с детальным планом.