Зачем обновляться с MySQL 5.7 на 8.0
Официальная поддержка MySQL 5.7 закончилась в октябре 2023 года: обновлений безопасности для этой ветки больше не выходит. Версия 8.0 получает патчи, поддерживает оконные функции, CTE (WITH ... AS), invisible-индексы и заметно быстрее выполняет операции с большими таблицами за счёт переработанного оптимизатора запросов.
Откладывать обновление опасно не только из-за уязвимостей: чем дольше сервер работает на 5.7, тем больше накапливается несовместимого кода, который потом придётся чинить за один заход.
Что ломается при переходе на 8.0
Часть проблем проявляется сразу после обновления, часть — только под нагрузкой.
- По умолчанию используется плагин аутентификации caching_sha2_password вместо mysql_native_password — старые драйверы PHP и коннекторы могут не уметь его читать.
- Режим sql_mode по умолчанию включает ONLY_FULL_GROUP_BY — запросы с GROUP BY без агрегатных функций начинают падать с ошибкой.
- Query Cache полностью удалён из сервера — конфигурация с query_cache_size вызывает ошибку старта.
- Зарезервированные слова расширились: имена столбцов вроде RANK или GROUPS требуют экранирования обратными кавычками.
Проверка совместимости перед обновлением
Утилита проверки совместимости встроена в клиент MySQL Shell и находит большинство проблем без реального апгрейда.
mysqlsh -- util check-for-server-upgrade { --user=root --password }
mysqlcheck --check-upgrade --all-databases -u root -pОтчёт разделяет находки на ошибки, которые обязательно исправить до обновления, и предупреждения, которые можно разобрать позже. Перед стартом обязательно снимите полный бэкап через mysqldump или другой инструмент горячего копирования.
Порядок версий при обновлении
| Текущая версия | Куда обновляться | Комментарий |
|---|---|---|
| 5.7.x любой минорной | сразу 8.0.x | прямой апгрейд поддерживается официально |
| 5.6 и старше | сначала 5.7, затем 8.0 | пропуск версии 5.7 не поддерживается |
| 8.0.x старой минорной | 8.0.x последней минорной | обновление внутри мажорной версии проходит проще всего |
Пошаговый процесс обновления
На Ubuntu и Debian обновление внутри одного пакетного менеджера проходит через замену репозитория.
systemctl stop mysql
mysqldump --all-databases --routines --triggers -u root -p > /root/full_backup.sql
apt update
apt install mysql-server=8.0.*
systemctl start mysql
mysql_upgrade -u root -pКоманда mysql_upgrade в версиях 8.0.16 и новее запускается автоматически при старте сервиса, но её ручной вызов не повредит и покажет явный список обновлённых системных таблиц.
Частые ловушки после обновления
Большинство обращений в поддержку после апгрейда связаны не с самим MySQL, а со связкой сервер-приложение.
- Приложение на старом драйвере PHP mysqlnd не подключается — плагин авторизации нужно временно вернуть на mysql_native_password для конкретного пользователя.
- Запросы с сортировкой по алиасу или неполным GROUP BY возвращают ошибку 1055 — их придётся переписать под ONLY_FULL_GROUP_BY.
- Кодировка по умолчанию сменилась на utf8mb4 — стоит свериться со статьёй про настройку utf8mb4, если таблицы созданы без явной кодировки.
- Права пользователей, выданные через GRANT ALL ON *.*, после обновления стоит перепроверить — механизм ролей в 8.0 изменил часть поведения из статьи про управление пользователями.
Итог: чек-лист обновления с 5.7 на 8.0
- Снять полный бэкап базы данных перед любыми действиями.
- Прогнать util check-for-server-upgrade и исправить все критические находки.
- Проверить драйверы приложения на совместимость с caching_sha2_password.
- Обновить пакет сервера и выполнить mysql_upgrade.
- Прогнать регресс-тесты приложения с учётом ONLY_FULL_GROUP_BY.
Частые вопросы
Можно ли откатиться обратно на 5.7, если после обновления на 8.0 что-то пошло не так?
Простого отката через понижение версии пакета MySQL не существует — формат системных таблиц 8.0 несовместим со старым сервером, и попытка запустить 5.7 поверх уже обновлённых данных обычно заканчивается ошибкой старта. Единственный надёжный путь назад — восстановление из полного бэкапа, снятого перед обновлением, поэтому его обязательность в чек-листе не формальность, а единственный путь отступления.
Требуется ли полностью переписывать старые запросы с ONLY_FULL_GROUP_BY, или это ограничение можно временно отключить?
Полностью переписывать все запросы сразу не обязательно — режим ONLY_FULL_GROUP_BY можно временно убрать из sql_mode на уровне сервера или сессии, чтобы старые запросы продолжили работать без изменений. Это рабочий обходной путь на переходный период, но не постоянное решение: отключённая проверка скрывает потенциально некорректные запросы, которые рано или поздно стоит привести в порядок.
Ломает ли обновление сервера существующие пароли пользователей MySQL?
Сами пароли при обновлении не теряются и не сбрасываются, но метод их проверки меняется вместе со сменой плагина аутентификации по умолчанию, из-за чего часть клиентских библиотек перестаёт понимать ответ сервера. Проблема не в содержимом пароля, а в протоколе рукопожатия — для уже существующих пользователей плагин при необходимости можно переключить вручную, не трогая сам пароль.
Нужно ли останавливать сайт на время обновления MySQL или возможно сделать это без простоя?
Короткая остановка сервиса в процессе неизбежна, потому что сам пакет сервера заменяется и служба перезапускается, а полностью непрерывное обновление без единого разрыва соединений для одиночного сервера технически не реализовать. Простой можно сократить до минимума, подготовив все шаги заранее и выполнив замену пакета и mysql_upgrade одним быстрым проходом в окно минимальной нагрузки.