Оновлення MySQL між мажорними версіями — повний гайд

• RANK
• GROUPS
• VALUE
• SYSTEM

MySQL 8.0 → 8.4:

• mysql_native_password плагін вимкнено за замовчуванням.
• Ряд системних змінних видалено або перейменовано.

Чому важлива перевірка сумісності?

Перед оновленням обов'язково виконуємо mysqlcheck та MySQL Shell Upgrade Checker — інструмент, рекомендований Oracle для виявлення проблем до міграції. Як зазначається в документації MySQL: «Перед оновленням обов'язково виконайте MySQL Shell Upgrade Checker».

mysqlcheck --all-databases --user=root --password --check-upgrade
mysqlsh root@localhost -e "util.checkForServerUpgrade('root@localhost:3306', {targetVersion: '8.0'})"

Shell Upgrade Checker знаходить:

• Таблиці з несумісними типами даних
• Використання видалених/змінених функцій SQL
• Конфігураційні параметри, які змінилися
• Проблемні імена (зарезервовані слова)
• Таблиці в застарілому ROW_FORMAT

Типовий висновок для бази з проблемами:

1) Usage of old temporal type - table mydb.events: column event_time is using old temporal type
2) Usage of reserved keywords - table mydb.rank: 'rank' is a reserved keyword in MySQL 8.0
3) Tables with non-native partitioning - table mydb.logs uses MySQL 5.1 style partitioning (upgrade required)

Кожен пункт потрібно виправити до оновлення, інакше mysql_upgrade або сервер сам відмовиться стартувати.

Оновлення MySQL між мажорними версіями: яку стратегію обрати?

In-place upgrade — підходить для некритичних середовищ, невеликих баз. Зупинити MySQL 5.7, встановити MySQL 8.0 поверх, запустити. Це швидше в 5 разів, ніж dump/restore, але ризикованіше — немає відкату.

Логічна міграція через dump — надійно, але вимагає даунтайму, пропорційного обсягу бази. Для великих БД (500+ ГБ) даунтайм може сягати доби, тому краще використовувати реплікацію.

Реплікація для zero-downtime — підняти MySQL 8.0 як replica до існуючого MySQL 5.7. MySQL 8.0 може бути реплікою до 5.7 (зворотне — ні). Синхронізувати дані через реплікацію, перемкнути застосунок на новий сервер, потім видалити старий. Цей метод знижує даунтайм до секунд — в 100 разів краще, ніж in-place.

# Приклад: налаштування реплікації на MySQL 8.0
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='10.0.0.1',
  SOURCE_USER='repl',
  SOURCE_PASSWORD='password',
  SOURCE_AUTO_POSITION=1;
START REPLICA;

Ця стратегія вимагає, щоб MySQL 5.7 мав GTID включений. Якщо ні — використовуємо SOURCE_LOG_FILE/POS.

Що перевірити після оновлення?

Переконайтеся, що всі таблиці конвертовано: виконайте SELECT table_schema, table_name, row_format FROM information_schema.tables WHERE engine='InnoDB' AND row_format NOT IN ('Dynamic', 'Compressed') AND table_schema NOT IN ('mysql','information_schema','performance_schema','sys');

Перевірте плагіни автентифікації: SELECT user, host, plugin FROM mysql.user WHERE plugin = 'mysql_native_password';

Оновіть користувачів на caching_sha2_password (якщо клієнти підтримують): ALTER USER 'app'@'%' IDENTIFIED WITH caching_sha2_password BY 'password'; Або залиште legacy-клієнтам mysql_native_password.

Які параметри конфігурації потрібно оновити?

Деякі параметри, що працювали в 5.7, у 8.0 викликають помилку або ігноруються. Видаліть з my.cnf:

• innodb_log_checksums (завжди включено)
• innodb_locks_unsafe_for_binlog (видалено)
• query_cache_size, query_cache_type (query cache видалено в 8.0)
• expire_logs_days → замінено на binlog_expire_logs_seconds

MySQL 8.0 не запуститься, якщо в my.cnf є невідомі змінні. Shell Upgrade Checker знаходить їх заздалегідь.

Як ми виконуємо міграцію

Наш процес базується на багаторічному досвіді — понад 50 проєктів з міграції MySQL. Ось типові етапи:

1. Аудит сумісності: запускаємо Upgrade Checker, перевіряємо схему, конфігурацію, клієнтські бібліотеки.
2. Вибір стратегії: визначаємо, чи підходить in-place, dump/restore або реплікація, з урахуванням ваших SLA.
3. Створення тестового середовища: розгортаємо копію бази, виконуємо тестову міграцію, перевіряємо помилки.
4. Підготовка відкату: налаштовуємо бекап, зберігаємо конфігурацію.
5. Міграція в продакшн: виконуємо за планом, моніторимо метрики.
6. Пост-міграційне тестування: перевіряємо продуктивність, функціональність, помилки.
7. Документування: фіксуємо зміни, оновлюємо runbook, навчаємо вашу команду.

Що входить в послугу — оновлення mysql між версіями

• Аудит сумісності та звіт
• Вибір стратегії оновлення
• Створення тестового середовища та тестова міграція
• Розробка плану відкату
• Виконання міграції в продакшн
• Пост-міграційне тестування та оптимізація
• Документування змін та оновлення runbook
• Підтримка протягом тижня після оновлення

Терміни та вартість

Вартість розраховується індивідуально після аудиту поточної версії, обсягу бази та вимог до простою. Економія на ліцензіях при переході з MySQL 5.7 на 8.0 може сягати 30%. Вартість години простою для середнього бізнесу — близько $450–650. Інвестиції в оновлення окупаються за рахунок зниження ризиків та ліцензійних витрат. Для попередньої оцінки залиште заявку.

Екстрений відкат

Навіть при ретельній підготовці можливі несподівані проблеми. Ми завжди передбачаємо план відкату до початку робіт: відновлюємося з бекапу або перемикаємося на старий сервер через реплікацію. На тестовій копії виявляється 99% помилок, але ми готові до екстреного відкату.

Зв'яжіться з нами для консультації — оцінимо ваш проєкт протягом дня. Отримайте комерційну пропозицію з детальним планом.