Навіщо оновлюватися з 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 одним швидким проходом у вікно мінімального навантаження.