Что случилось с MySQL 8.0
Весной 2026 года Oracle перевела MySQL 8.0 в режим Sustaining Support: обычного обслуживания ветка больше не получает. Сервер от этого не остановится и данные не пропадут, но рассчитывать на привычный поток исправлений нельзя. Oracle советует переходить на 8.4 LTS или 9.7 LTS, и разумнее сделать это по плану, а не после первой уязвимости.
Точную дату источники называют по-разному: в одних встречается 21 апреля 2026 года, в других — 30 апреля. Страницу уведомлений Oracle нам не удалось открыть напрямую, поэтому в статье стоит только «весной 2026 года». Сверьте дату сами на странице уведомлений Oracle. Последний выпуск ветки 8.0 на странице загрузок — 8.0.46 (на начало ноября 2026 года).
Куда переходить: 8.4 LTS, 9.7 LTS или MariaDB
Для рабочих серверов подходит ближайшая LTS-серия — 8.4. По мануалу MySQL выпуски делятся на две дорожки, LTS и Innovation; у LTS пять лет основной поддержки и ещё три года расширенной, а внутри серии выходят только необходимые исправления.
- MySQL 8.4 (LTS): выпуск 8.4.13 от 20 октября 2026 года; с 8.0 переход напрямую
- MySQL 9.7 (LTS): вторая LTS-серия; с 8.0 только через 8.4
- MariaDB 12.3 (LTS): GA 28 мая 2026 года, поддержка сообществом до 12 июня 2029 года (по таблице политики mariadb.org)
MariaDB — не обновление MySQL, а смена сервера: совместимость неполная, и это отдельная миграция. Плюсы и подводные камни разобраны в статье про переход между MariaDB и MySQL.
Правило серий: что нельзя пропускать
LTS-серию пропускать нельзя. Поэтому 8.0 → 8.4 допустимо напрямую, 8.4 → 9.7 тоже, а 8.0 → 9.7 — только через 8.4. Версия 5.7 доходит до 8.4 лишь через 8.0; этот шаг описан в статье про обновление с 5.7 на 8.0.
Что сломается: авторизация и удалённые параметры
Главный риск обновления — не данные, а старые подключения и конфиги. В 8.4 плагин mysql_native_password по умолчанию не включён, а параметр default_authentication_plugin удалён: вместо него работает authentication_policy. Приложения со старыми аккаунтами не смогут войти, пока вы не переведёте пользователей или не включите плагин.
-- аккаунты, которые ещё на старом плагине
SELECT user, host FROM mysql.user WHERE plugin = 'mysql_native_password';
-- перевод аккаунта на плагин по умолчанию
ALTER USER 'app'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'CHANGE_ME';
# my.cnf: временная мера, пока приложения не переведены
[mysqld]
mysql_native_password=ONКроме того, в 8.4 удалены:
mysql_upgradeиmysqlpump(дамп делайте черезmysqldump, а проверку при запуске сервер выполняет сам);- параметры
--skip-host-cache,--innodbи--skip-innodb,--sslи--admin-ssl; - привилегия
SET_USER_IDи плагиныkeyring_file,keyring_encrypted_file,keyring_oci,openssl_udf,authentication_fido.
Отдельно: AUTO_INCREMENT на столбцах FLOAT и DOUBLE не даст обновиться, пока вы не перестроите такие таблицы, а внешние ключи на нестандартные ключи по умолчанию запрещены (параметр restrict_fk_on_non_standard_key). Полный перечень — в мануале MySQL 8.4, в разделе об обновлении с предыдущей серии.
Репликация: операторы переименованы
Если у вас есть репликация, готовьте скрипты заранее: старые операторы с терминами master и slave в 8.4 удалены, а это ломает мониторинг, задачи cron и инструкции для дежурных. Замена прямая, меняются только имена.
| В 8.0 (удалено) | В 8.4 |
|---|---|
START SLAVE | START REPLICA |
SHOW MASTER STATUS | SHOW BINARY LOG STATUS |
CHANGE MASTER TO | CHANGE REPLICATION SOURCE TO |
group_replication_ip_whitelist | group_replication_ip_allowlist |
Также удалены параметры master-info-repository и relay-log-info-repository, а с ними transaction_write_set_extraction и log_bin_use_v1_events. Найдите их в my.cnf заранее: неизвестный параметр не даст серверу запуститься.
Изменившиеся значения по умолчанию
Эти параметры не мешают запуску, но меняют поведение и нагрузку: при тех же настройках база может вести себя иначе. Если вы не задавали их в my.cnf сами, сервер 8.4 возьмёт новые значения. Прежнее поведение можно зафиксировать явно, но сначала стоит измерить, нужно ли оно.
| Параметр | В 8.0 | В 8.4 |
|---|---|---|
innodb_adaptive_hash_index | ON | OFF |
innodb_change_buffering | all | none |
innodb_flush_method | fsync | O_DIRECT, если поддерживается |
innodb_io_capacity | 200 | 10000 |
innodb_log_buffer_size | 16 МБ | 64 МБ |
innodb_use_fdatasync | OFF | ON |
Значения даны по мануалу MySQL 8.4. Чтобы вернуть прежнее поведение, пропишите нужное в my.cnf; подбор остальных параметров разобран в статье про оптимизацию my.cnf.
Проверка совместимости до обновления
Прежде чем что-то менять, прогоните проверку: MySQL Shell заранее находит проблемы, которые сломают обновление. Утилита util.checkForServerUpgrade() работает с серверами 5.7 и 8.x, ей нужны привилегии PROCESS и SELECT. Версию целевого релиза указывайте явно, а сам MySQL Shell берите не ниже целевой версии.
mysqlsh -- util checkForServerUpgrade user@host:3306 --target-version=8.4.13 --output-format=JSONРазбирайте отчёт сверху вниз и сопоставляйте его с разделами выше. Начинайте с ошибок: они остановят обновление, а предупреждения подождут до проверки на тестовой копии.
Порядок обновления с резервной копией и откатом
Безопасный порядок такой: проверка, полная копия, остановка записи, обновление, контроль. Откат продумывайте до начала: не рассчитывайте на обратное обновление на тех же файлах данных, надёжный путь назад — копия. Приёмы копирования разобраны в статье про mysqldump.
- Запустите
util.checkForServerUpgrade()и исправьте все ошибки. - Снимите логический дамп и копию каталога данных на остановленном сервере.
- Проверьте, что копия восстанавливается, на отдельной машине.
- Уберите удалённые параметры из
my.cnf, переведите пользователей или временно включитеmysql_native_password. - Остановите сервер, обновите пакеты до 8.4 и запустите его.
- Прочитайте журнал ошибок, подключите приложение, прогоните контрольные запросы.
- Через несколько дней уберите временные меры.
mysqldump --all-databases --single-transaction --routines --events --triggers > /backup/all-before-84.sql
systemctl stop mysql
cp -a /var/lib/mysql /backup/mysql-datadir-before-84Имя службы зависит от дистрибутива: mysql или mysqld. Откат: остановите сервер 8.4, верните копию каталога данных и пакеты 8.0, запустите. Записи, сделанные уже после обновления, придётся переносить вручную, поэтому на время проверки держите приложение в режиме чтения.
Частые вопросы
MySQL 8.0 перестанет работать сразу?
Нет. Сервер продолжает работать, но обычного обслуживания ветка больше не получает. Планируйте переход заранее, пока есть время на проверку на тестовой копии.
Можно ли перейти с 8.0 сразу на 9.7?
Нет, LTS-серию пропускать нельзя. Сначала 8.0 → 8.4, затем 8.4 → 9.7, каждый шаг со своей проверкой и копией.
Нужно ли запускать mysql_upgrade после обновления?
Нет, эта программа в 8.4 удалена. Проверку и обновление системных таблиц сервер выполняет сам при первом запуске, а результат пишет в журнал ошибок.
Что делать клиентам ZevsHost?
На общем хостинге версией MySQL управляет панель, вам делать ничего не нужно. На VPS и выделенном сервере сервер баз данных — в вашем управлении: сделайте копию и проверьте совместимость до обновления.