MySQL 8.4 LTS: что изменилось по сравнению с 8.0 и что ломается

MySQL 8.4 - первый релиз с долгосрочной поддержкой в новой модели выпусков Oracle, и поскольку срок жизни MySQL 8.0 закончился в апреле 2026 года, переходить стоит именно на эту версию. Для большинства приложений обновление с 8.0 проходит без происшествий: SQL тот же, драйверы те же, файлы данных обновляются на месте. Ломается всё на краях. Учётные записи с mysql_native_password не могут войти, пока плагин не включат обратно, потому что 8.4 отключает его по умолчанию. Скрипты с CHANGE MASTER TO, SHOW SLAVE STATUS, FLUSH HOSTS, mysqlpump или expire_logs_days падают, потому что всё это удалили. И горстка значений InnoDB по умолчанию изменилась - в основном к лучшему на быстром хранилище, но одно из них на маленьких серверах стоит переопределить.

Это руководство сначала разбирает модель выпусков, потому что она меняет то, как вы планируете обновления, затем каждое изменение, которое может затронуть приложение или администратора, и, наконец, как проверить базу данных перед переносом.

Релизы LTS и Innovation#

До 8.0 MySQL годами выпускал одну серию и добавлял возможности в патч-релизах: 8.0.x получила EXPLAIN ANALYZE в 8.0.18, hash join в 8.0.18, innodb_redo_log_capacity в 8.0.30. Из-за этого «8.0» была движущейся целью - два сервера, оба называющиеся MySQL 8.0, могли вести себя по-разному.

Начиная с 8.1 Oracle разделил релизы на две ветки:

Серия LTS задумана скучной. 8.4.1, 8.4.2 и так далее содержат исправления, а не новые возможности или изменённые значения по умолчанию, так что патч-обновление не должно менять поведение вашего приложения. Oracle указывает, что 8.4 поддерживается до 2032 года, причём первые пять лет из них - с поддержкой уровня premier. Релизы Innovation - для тех, кто хочет новые возможности пораньше и готов обновляться каждые несколько месяцев; для базы данных продакшен-приложения разумный выбор по умолчанию - LTS.

Практическое следствие в том, что возможности, появившиеся в 8.1-8.3, приходят в 8.4 все разом, и так же разом приходят удаления, сделанные по ходу в релизах Innovation. Поэтому при переходе с 8.0 на 8.4 ломающих изменений больше, чем можно подумать по разнице в номере версии 0.4.

Аутентификация: mysql_native_password выключен#

Это изменение, из-за которого приложения перестают подключаться.

mysql_native_password, плагин на основе SHA-1, который был плагином по умолчанию до 8.0, объявили устаревшим в 8.0. В 8.4 он всё ещё есть, но отключён по умолчанию. Учётная запись, созданная с ним, существует, но вход не удаётся, пока сервер не запустят с:

[mysqld]mysql_native_password=ON

Тот же переключатель доступен в командной строке как --mysql-native-password=ON. Это опция запуска, а не то, что может поменять пользователь приложения, а в MySQL 9.0 плагин удалён полностью, так что его повторное включение даёт отсрочку, а не решает проблему. Настоящее решение - перевести учётные записи на caching_sha2_password, плагин по умолчанию начиная с 8.0:

-- Find accounts still on the old pluginSELECT user, host, plugin FROM mysql.userWHERE plugin = 'mysql_native_password';-- Move one; the password must be set again because the hash format differsALTER USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY 'the-password';

Перед этим убедитесь, что драйвер приложения поддерживает caching_sha2_password. Всё, что выпущено за последние несколько лет, поддерживает: mysqlnd в PHP, mysql2 в Node, PyMySQL, mysqlclient, Connector/J 8 и новее, MySqlConnector для .NET. Исходный пакет Node mysql не поддерживает, как и клиенты командной строки эпохи MySQL 5.7. Клиент, который этого не умеет, падает с Authentication plugin 'caching_sha2_password' cannot be loaded; тому, который умеет, но подключается без TLS, при первом входе нужен публичный RSA-ключ сервера или TLS-соединение - это поведение объясняет статья удалённые подключения к MySQL.

Два изменения аутентификации поменьше: переменную default_authentication_plugin удалили (её работу выполняет authentication_policy, которая также управляет многофакторной аутентификацией), а плагины authentication_fido удалили в пользу authentication_webauthn.

Удалённые операторы, опции и инструменты#

Всё, что указано здесь и встречается в скрипте, файле конфигурации или административных инструментах ORM, на 8.4 падает. Большинство из этого было объявлено устаревшим ещё в 8.0, с предупреждениями.

Смена синтаксиса репликации бьёт по скриптам мониторинга сильнее, чем по самим настройкам репликации. Проверка здоровья, которая каждую минуту выполняет SHOW SLAVE STATUS и ищет grep-ом Seconds_Behind_Master, теперь получает синтаксическую ошибку, а в SHOW REPLICA STATUS столбец называется Seconds_Behind_Source. Вместе с ними удалили и переменные состояния вроде Com_show_slave_status.

FLUSH HOSTS важен для всех, кто встречался с Host is blocked because of many connection errors. Замене через TRUNCATE нужна привилегия DROP на эту таблицу, которая есть у root; mysqladmin flush-hosts по-прежнему работает и внутри использует её.

Также удалены: опции --old и --new, --language, avoid_temporal_upgrade и show_old_temporals, LOW_PRIORITY с LOCK TABLES ... WRITE, плагины keyring_file и keyring_encrypted_file (заменены компонентами), INFORMATION_SCHEMA.TABLESPACES и поддержка слабых шифров TLS - 8.4 принимает только шифры с прямой секретностью и аутентифицированным шифрованием на TLS 1.2 и 1.3.

Новые значения по умолчанию InnoDB и сервера#

В 8.4 набор значений InnoDB по умолчанию изменили под современное железо - NVMe и множество ядер, - а не под вращающиеся диски, для которых писались старые. Если вы не задавали их явно, после обновления сервер ведёт себя иначе.

Большинство из них - улучшения, которые вы получаете бесплатно. O_DIRECT избавляет InnoDB от двойного кэширования страниц в кэше операционной системы. Более высокая ёмкость I/O позволяет фоновому сбросу успевать за быстрым хранилищем. Отключение adaptive hash index и change buffering убирает две возможности, которые часто вызывали конкуренцию и редко окупались на современных нагрузках; если конкретной нагрузке с преобладанием чтения они помогали, их можно включить обратно.

На маленьком сервере стоит присмотреться к temptable_max_ram. Его значение по умолчанию в 8.4 никогда не бывает меньше 1 ГБ, а на сервере с 1 или 2 ГБ это позволяет временным таблицам в памяти забрать половину машины или её целиком. Ограничьте его - в статье настройка InnoDB для небольших серверов есть цифры по размеру тарифа. innodb_dedicated_server, если вы его используете, больше не задаёт innodb_flush_method и подбирает размер redo log по числу CPU, а не по памяти.

Изменения схемы и привилегий#

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

Подстановочные знаки в правах на базы данных объявлены устаревшими. GRANT ... ON на имя базы данных, содержащее % или _, по-прежнему работает как шаблон, но ожидается, что в будущем релизе эти символы станут буквальными. Выдавайте права по каждой базе данных.

Новые привилегии. FLUSH_PRIVILEGES (только для FLUSH PRIVILEGES; владельцы RELOAD получают её при обновлении), OPTIMIZE_LOCAL_TABLE, TRANSACTION_GTID_TAG, а также SET_ANY_DEFINER с ALLOW_NONEXISTENT_DEFINER, которые заменяют SET_USER_ID для создания объектов, где definer - кто-то другой. Последнее изменение влияет на восстановление: дампу, представления и процедуры которого называют definer, отличного от вас, нужна SET_ANY_DEFINER, чтобы загрузиться в исходном виде. Подробнее о definer - в статье пользователи и привилегии MySQL.

Идентификаторы с несколькими `$`. Идентификатор без кавычек, содержащий два знака доллара или больше, с 8.1 считается синтаксической ошибкой. Встречается редко, но, если встретится, ломается громко.

С положительной стороны, 8.4 приносит с собой возможности эпохи Innovation: гистограммы, которые можно настроить на автоматическое обновление через ANALYZE TABLE, теги GTID для группировки транзакций и клиент mysql, который может отключить свой выход в шелл system через --system-command=OFF.

Проверка базы данных перед обновлением#

Проверка обновления в MySQL Shell изучает работающий сервер 8.0 и сообщает обо всём, что станет проблемой на целевой версии: используемые удалённые опции, учётные записи на устаревших плагинах, внешние ключи на неуникальных ключах, зарезервированные слова в роли идентификаторов и многое другое.

$ mysqlsh root@old-server:3306 -- util check-for-server-upgrade --target-version=8.4.6

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

«На месте» означает остановить старый сервер и запустить новые бинарные файлы на том же каталоге данных; при первом запуске сервер сам обновляет свой словарь данных и системные таблицы. На хостинговой базе данных, где сервером управляет провайдер, эквивалент - логический дамп ваших баз данных, загруженный в сервер 8.4, - и точно так же переезжают между хостами, о чём статья перенос MySQL на новый хост. Логический дамп к тому же позволяет пропустить шаг с 5.7 на 8.0, поскольку MySQL 8.4 в большинстве случаев загружает дамп 5.7 напрямую; исключения - в основном зарезервированные слова и нулевые даты в строгом режиме.

Обновление шаг за шагом#

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

1. Сначала поднимитесь до свежего патча 8.0. Обновление с 8.0.40 с чем-то проверено лучше, чем с 8.0.20, а поздние патчи 8.0 предупреждают о большей части того, что 8.4 удаляет. После этого перезапуска прочитайте журнал ошибок на предмет предупреждений об устаревании: каждое из них - будущий сбой.
2. Запустите проверку обновления на работающем сервере и исправьте всё, что она отмечает как ошибку. Предупреждения тоже заслуживают внимания; среди них есть учётные записи на mysql_native_password.
3. Почистите конфигурацию. Удалите опции, перечисленные выше, и осознанно решите, что делать с изменёнными значениями InnoDB по умолчанию: если вы настраивали innodb_io_capacity под своё хранилище, ваше значение останется; если никогда его не задавали, оно подскочит с 200 до 10000.
4. Сделайте полный бэкап, который вы хотя бы раз восстанавливали. Логический дамп - тот, что позволит вернуться на 8.0 в случае необходимости, потому что обновление на месте нельзя откатить запуском старых бинарных файлов - словарь данных уже обновлён.
5. Остановите сервер корректно. С innodb_fast_shutdown в значении по умолчанию 1 корректной остановки достаточно; если сначала задать 0, InnoDB перед остановкой завершит работу purge и слияния, что некоторые предпочитают перед крупным обновлением.
6. Установите 8.4 и запустите его на том же каталоге данных. Следите за журналом ошибок: сервер обновляет словарь данных, затем системную схему и сообщает, когда готов принимать соединения. На большом экземпляре с множеством таблиц это занимает время; не прерывайте процесс.
7. Проверьте приложение, включая вход для каждой учётной записи, задания по расписанию и любой мониторинг, выполняющий административные операторы. Сбои при этом обновлении почти все на краях, а не в запросах.

На хостинговой базе данных шаги 5 и 6 вы сами не делаете, а путь - дамп со старого сервера, загруженный в новый сервер 8.4. Шаги 1-4 и 7 по-прежнему применимы, а проверку обновления можно направить на старый сервер с любой машины, где есть MySQL Shell. Когда приложение работает с репетиционной копией, загруженной из дампа, переключение сводится к изменению конфигурации.

Что не меняется#

Для приложения - почти ничего. Синтаксис SQL для запросов и DML тот же. utf8mb4 с utf8mb4_0900_ai_ci остаются значениями по умолчанию. Оконные функции, общие табличные выражения, функции JSON, EXPLAIN ANALYZE, невидимые и функциональные индексы ведут себя так же, как в поздних 8.0. ORM, которые поддерживали 8.0, поддерживают и 8.4; проверять стоит те, что выполняют операторы репликации или администрирования, и те, что привязаны к старому драйверу.

Чек-лист по порядку: обновите драйверы, переведите учётные записи с mysql_native_password, уберите удалённые опции из конфигурации, замените удалённые операторы в скриптах и мониторинге, запустите проверку обновления, затем отрепетируйте переезд на копии и прогоните на ней тесты приложения.

FAQ#

Поддерживается ли ещё MySQL 8.0?

Нет. Срок жизни MySQL 8.0 закончился в апреле 2026 года, и она больше не получает от Oracle исправлений, в том числе исправлений безопасности. Некоторые облачные провайдеры продают для неё платную расширенную поддержку, но поддерживаемый бесплатный путь - 8.4 LTS.

Что использовать: MySQL 8.4 или релиз Innovation 9.x?

Для продакшен-приложения - 8.4 LTS. Релизы Innovation поддерживаются только до следующего, примерно квартал, поэтому оставаться на них значит обновляться несколько раз в год через релизы, которые могут что-то удалять. Используйте 9.x, чтобы тестировать то, что грядёт, и переходите на следующий LTS, когда он выйдет.

Можно ли ещё использовать mysql_native_password на 8.4?

Только если сервер запущен с mysql_native_password=ON, а для этого нужен контроль над конфигурацией сервера. Даже тогда это временная мера: в MySQL 9.0 плагин удалили. Переведите учётную запись на caching_sha2_password и обновите любой драйвер, который с ним не справляется.

Загрузится ли мой дамп 8.0 в MySQL 8.4?

Почти всегда да. Логический дамп из 8.0 в подавляющем большинстве случаев загружается в 8.4 без изменений. Обратите внимание на предложения definer с учётными записями, которых нет на новом сервере, и на строки SET @@GLOBAL, которым нужны привилегии, которых нет у обычного пользователя; оба случая разобраны в статье бэкап и восстановление через mysqldump.

Нужно ли запускать mysql_upgrade после обновления?

Нет - а на 8.4 и нельзя, потому что его удалили. Начиная с 8.0.16 сервер сам обновляет свои системные таблицы и словарь данных при запуске; этим управляет опция --upgrade, которая по умолчанию делает всё необходимое.