Що сталося з 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 і виділеному сервері сервер баз даних — у вашому керуванні: зробіть копію та перевірте сумісність до оновлення.