MySQL LTS и Innovation: какую версию запускать

Для боевой базы данных в конце 2026 года ответ один: LTS-релиз, то есть MySQL 8.4 или MySQL 9.7. Обе ветки получают исправления ошибок и уязвимостей в течение многих лет, ни одна не меняет поведение внутри своей серии, и любая подходит для приложения, которое вы хотите оставить в покое. MySQL 8.0 закончилась: её последний релиз, 8.0.46, вышел в апреле 2026 года, и Oracle больше не выпускает для неё исправления. Релизы Innovation (с 8.1 по 8.3, с 9.0 по 9.6 и теперь 26.7 с календарной нумерацией) имеют качество для production, но поддерживаются только до выхода следующего, то есть примерно три месяца. Запуская такой релиз, вы обновляетесь четыре раза в год через версии, в которых разрешено что-то удалять.

Дальше в руководстве разобраны две ветки, важные даты окончания поддержки, новая календарная нумерация, которая появилась в июле 2026 года, допустимые и недопустимые пути обновления, а также то, как получаемая вами версия зависит от источника: дистрибутива Linux, репозиториев Oracle или тега Docker, который может измениться у вас под ногами.

Две ветки релизов#

До версии 8.0 у MySQL была одна долгоживущая серия на каждую мажорную версию, а новые возможности попадали в патч-релизы. В 8.0.18 появились hash join и EXPLAIN ANALYZE, в 8.0.30 - innodb_redo_log_capacity. Два сервера с одинаковым названием "8.0" могли вести себя совершенно по-разному. Начиная с 8.1 в июле 2023 года Oracle разделила релизы на две ветки.

В руководстве Oracle обе ветки названы "production-grade quality". Разница не в качестве, а в изменчивости. Поведение серии LTS заморожено: версии с 8.4.1 по 8.4.11 содержат исправления, но не новые возможности и не другие значения по умолчанию. Эта заморозка объясняет и то, почему внутри серии LTS работает откат на месте: формат данных не меняется, поэтому с 8.4.11 можно вернуться на 8.4.10, если патч работает плохо.

Релиз Innovation устроен наоборот. В каждом может быть объявлено устаревшим или удалено что-то из возможностей, могут измениться зарезервированные слова, поведение оптимизатора и значения по умолчанию. Руководство предупреждает, что такие изменения "могут сильно повлиять", особенно на синтаксис SQL и производительность запросов. Возможности, удалённые за цикл Innovation, окончательно исчезают в закрывающем его LTS. Поэтому переход с 8.0 на 8.4 сломал больше, чем можно было ожидать по номеру версии: все удаления из 8.1, 8.2 и 8.3 пришли одновременно. Их список есть в статье MySQL 8.4 LTS: что изменилось.

Пока схема такая: серия релизов Innovation, затем LTS, который замораживает результат.

Даты окончания поддержки, которые важны#

Эти даты стоит занести в календарь. Политика пожизненной поддержки Oracle (Lifetime Support Policy) даёт серии LTS пять лет premier-поддержки и три года extended, считая от первого GA-релиза. Для пользователей Community Edition практический смысл простой: патч-релизы выходят до конца этого срока.

Даты для 9.7 получены применением правила "пять плюс три" к GA в апреле 2026 года; точный месяц стоит уточнить в документе Oracle о сроках поддержки. В любом случае 8.4 поддерживается ещё годы: спешить с уходом с неё не нужно, и приложению, которое перешло на 8.4 в 2025 году, не придётся переезжать снова до конца десятилетия.

Про 8.0: "конец жизни" означает, что Oracle больше не выпускает исправления, в том числе для уязвимостей, найденных после апреля 2026 года. Некоторые дистрибутивы и облачные провайдеры ещё какое-то время поддерживают собственные пакеты: Ubuntu 22.04 и 24.04 получили 8.0.46 в июне 2026 года, а Oracle продлила 8.0 в собственном сервисе HeatWave до апреля 2027 года. Но это последние патчи ветки, которую никто не развивает. Сервер, всё ещё работающий на 8.0, нужно планировать к обновлению первым.

Календарная нумерация с 26.7#

В июле 2026 года MySQL сменила схему нумерации. 9.7 - последняя линия релизов с последовательными номерами, а всё дальнейшее использует календарные версии вида YY.M.P: две цифры года, месяц релиза, номер патча. Июльский релиз Innovation 2026 года - это 26.7.0, а следующие релизы Innovation Oracle назвала 26.10, 27.1, 27.4 и 27.7.

Здесь есть две вещи, на которых спотыкаются.

Во-первых, по номеру больше нельзя определить ветку. 26.7 - это Innovation, потому что так решила Oracle, а не из-за цифр, и будущий LTS тоже получит календарный номер. Всегда смотрите в заметки к релизу или в репозиторий, из которого вы устанавливали, а не угадывайте по строке версии. На работающем сервере:

SELECT @@version, @@version_comment;

@@version_comment показывает сборку, например MySQL Community Server - GPL; сборки дистрибутивов добавляют свой текст.

Во-вторых, номера патчей внутри серии LTS теперь следуют квартальному циклу обновлений безопасности. Каждое квартальное обновление Critical Patch Update (CPU) увеличивает третье число: 8.4.11, затем 8.4.12. Если серьёзная уязвимость требует исправления между кварталами, Oracle выпускает точечный патч (CSPU) с четвёртым числом - 8.4.11.1, 8.4.11.2 - а следующий квартальный релиз возвращается к трём числам. В релизах Innovation третье число остаётся равным 0, потому что исправлением за квартал служит просто следующий релиз Innovation. Пакеты Windows MSI кодируют четырёхчастные версии иначе (8.4.11.1 в метаданных установщика выглядит как 8.4.1101), но это косметика.

Скрипты, которые разбирают вывод mysql --version или SELECT VERSION() и предполагают однозначную мажорную версию, неверно прочитают 26.7.0. Сравнивайте версии численно по компонентам, а не как строки, и проверьте дашборды мониторинга и факты Ansible или Puppet, ветвящиеся по условию "мажорная версия 8 или 9".

Пути обновления и отката#

Модель веток приносит строгие правила о том, какие переходы сервер поддерживает на месте. Коротко: от LTS к следующему LTS, не пропуская ни одного.

Правила в том виде, как их формулирует справочное руководство:

• Внутри серии LTS поддерживаются и обновление, и откат на месте. Переход с 8.4.3 на 8.4.11 и обратно допустим.
• От одного LTS к следующему поддерживается обновление на месте: с 8.4.x на 9.7.x. Пропускать LTS нельзя - с 8.4 нельзя сразу перейти на тот LTS, который последует за 9.7.
• Релиз Innovation обновляется на месте до более позднего релиза Innovation того же цикла или до закрывающего его LTS: с 9.1 на 9.2 или с 9.5 на 9.7.
• Релиз Innovation не может напрямую перейти в следующий цикл. С 8.3 на 9.0 идут через 8.4.
• Только 9.7 LTS может обновиться на месте до первого цикла с календарными версиями, который начинает 26.7.
• Откат релиза Innovation всегда требует логического дампа и загрузки.

8.0 стоит до введения модели, но тот же принцип применим: обновление с 8.0 на 8.4 на месте поддерживается с недавнего патча 8.0, а с 8.0 на 9.7 идут через 8.4. С 5.7 сначала нужно дойти до 8.0.

Логический дамп и загрузка обходят большинство этих ограничений. Дамп из mysqldump или MySQL Shell с 8.0 или 8.4 загружается в 9.7 почти всегда, потому что это просто SQL; ошибки возможны в содержимом - учётные записи на удалённых плагинах аутентификации, зарезервированные слова в роли идентификаторов, definer-ы, которых не существует. Это же единственный путь для любой размещённой у провайдера базы, где вы не можете подменить бинарные файлы на его сервере. Ключи и параметры описаны в статье резервное копирование и восстановление через mysqldump, а переключение - в статье перенос MySQL на новый хост.

Перед любым переходом запустите проверку обновления из MySQL Shell на старом сервере, указав целевую версию:

$ mysqlsh root@db.example.com:3306 -- util check-for-server-upgrade \    --target-version=9.7.2

Берите MySQL Shell не старше целевой версии, поскольку проверка знает только о версиях, вышедших до неё.

Какую версию запускать в production#

Большинству людей выбирать приходится между двумя поддерживаемыми сериями LTS.

Оставайтесь на 8.4 или переходите на неё, если ваше приложение уже на ней работает, если ваш хостинг-провайдер её предлагает или если ваша ORM, драйвер или инструменты не дотянулись до 9.x. У 8.4 premier-поддержка до 2029 года, и до этого ничто не заставляет переезжать. Это и консервативная цель при уходе с 8.0: путь с 8.0 на 8.4 хорошо проторён, а в 8.4 mysql_native_password ещё можно включить обратно как временную меру.

Выбирайте 9.7 для нового проекта без истории или если вам нужно то, что появилось в версиях с 9.0 по 9.6: тип данных VECTOR, новые доработки оптимизатора и несколько возможностей, которые Oracle перенесла из Enterprise в Community Edition вместе с 9.7, включая метрики применения репликации и статистику flow control в Group Replication. Цену нужно знать: mysql_native_password полностью удалён в 9.0, поэтому любая учётная запись или клиент, зависящие от него, перестанут работать, и включить его обратно нечем. Каждый драйвер должен поддерживать caching_sha2_password.

Используйте релиз Innovation для тестирования, для сред разработки, которые следят за тем, что готовится, или если вам прямо сейчас нужна конкретная возможность и есть команда, готовая обновляться каждый квартал. Запускать 26.x в production допустимо - Oracle его поддерживает, - но только если кто-то отвечает за квартальное обновление и набор тестов приложения прогоняется на каждом новом релизе.

Рабочее правило, которое себя оправдывает: production на LTS, одна база для staging или CI на самом новом релизе Innovation. Когда выйдет следующий LTS, удаления эпохи Innovation уже проявятся в CI, и обновление production будет запланированным, а не обнаруженным по факту.

Пакеты дистрибутивов#

Что вы получите от apt install mysql-server или dnf install mysql-server, зависит от релиза дистрибутива, а не от того, что Oracle рекомендует сейчас. Дистрибутивы выбирают версию при заморозке и держат её всё время жизни релиза.

В Ubuntu 24.04 пакет mysql-server по-прежнему равен mysql-server-8.0. Ubuntu доставила в него 8.0.46 в июне 2026 года, но 8.0.47 от Oracle не будет, поэтому сервер Ubuntu 24.04 с MySQL из дистрибутива сидит на остановившейся линии. Решения: обновить операционную систему до 26.04 или установить 8.4 из репозитория Oracle.

Debian заслуживает отдельного замечания, потому что удивляет людей: apt install default-mysql-server в Debian устанавливает MariaDB, а команда mysql - это клиент MariaDB. MariaDB отделилась от MySQL 5.5 и с тех пор разошлась с ней: это не версия MySQL, у неё свой график релизов и поддержки, и она не читает каталог данных MySQL 8.4. Если вам нужна именно MySQL в Debian, её берут из APT-репозитория Oracle или из Docker.

Чтобы узнать, что у вас стоит, в любом из них:

$ mysqld --version$ apt-cache policy mysql-server      # Debian and Ubuntu$ dnf info mysql-server              # RHEL family

Собственные репозитории Oracle#

Oracle публикует репозитории APT и Yum на repo.mysql.com, и именно в них ветка выбирается явно. Установочный пакет репозитория (mysql-apt-config в Debian и Ubuntu, mysql84-community-release и похожие в семействе RHEL) ставит конфигурацию, где вы выбираете одну серию: репозиторий 8.4 LTS, репозиторий 9.7 LTS или репозиторий Innovation.

На стороне Yum каждая ветка - отдельно названный репозиторий, и включить нужно ровно один. В примере из руководства используются mysql-innovation-community для Innovation и mysql-9.7-lts-community для 9.7 LTS:

$ dnf repolist all | grep mysql$ sudo dnf config-manager --disable mysql-innovation-community$ sudo dnf config-manager --enable mysql-9.7-lts-community

В Debian и Ubuntu выбор делается в диалоге при установке mysql-apt-config и позже его можно изменить:

$ sudo dpkg-reconfigure mysql-apt-config$ sudo apt update

Смысл выбора ветки, а не версии, виден при apt upgrade. Репозиторий LTS переведёт вас с 8.4.10 на 8.4.11 и никогда на 9.7. Репозиторий Innovation переводит с одного релиза Innovation на следующий - в этом и состоит смысл Innovation, - и задание unattended-upgrades, направленное на него, выполнит обновление вашей базы с новыми возможностями всякий раз, когда Oracle выпустит релиз. На production-сервере включайте репозиторий LTS и больше ничего. Также убедитесь, что Oracle публикует репозиторий для вашего релиза дистрибутива, прежде чем на него полагаться: новые релизы дистрибутивов иногда добавляются через месяцы после выхода.

Теги образов Docker#

Официальный образ mysql на Docker Hub сопоставляет теги с ветками, и некоторые из этих тегов перемещаются. По состоянию на октябрь 2026 года поддерживаются такие теги:

У каждого есть варианты -oracle или -oraclelinux9; все актуальные образы собраны на Oracle Linux 9. Варианты образов на основе Debian относились к 8.0 и исчезли вместе с ней, а mysql:8.0 больше не входит в список поддерживаемых: тег всё ещё скачивается, но пересобирать его никто не будет.

Большинство аварий вызывают три тега.

latest - это релиз Innovation. Файл Compose с image: mysql или image: mysql:latest при следующем docker compose pull обновит базу до текущего релиза Innovation, а поскольку откат Innovation требует дампа и загрузки, вернуться сменой тега не получится.

lts переместился. Пока в апреле 2026 года не вышла 9.7, mysql:lts был 8.4. Те, кто закрепился на lts, думая, что это значит "стабильно", при следующем скачивании получили обновление на месте с 8.4 до 9.7 - поддерживаемое, но удалившее mysql_native_password и необратимое сменой тега. lts снова переместится, когда выйдет следующий LTS.

8 тоже переместился. В течение жизни 8.0 он указывал на 8.0, а теперь указывает на 8.4.

Безопасный подход - закрепиться на выбранной серии и позволить патчам приходить:

services:  db:    image: mysql:8.4    environment:      MYSQL_ROOT_PASSWORD_FILE: /run/secrets/mysql_root      MYSQL_DATABASE: app    volumes:      - db-data:/var/lib/mysql

mysql:8.4 получает патчи 8.4 и никогда не перескакивает на другую серию. Если вы хотите, чтобы каждый патч тоже был вашим решением, закрепите полную версию (mysql:8.4.11) и повышайте её сами. В обоих случаях версию дальше несёт каталог данных в томе: контейнер, запущенный из более новой серии, обновляет его при первом старте, а более старая серия на нём отказывается запускаться. Тома и секреты подробнее разобраны в статье Docker Compose для небольших стеков.

Проверка и планирование версии#

Короткий аудит для любой MySQL, за которую вы отвечаете:

1. Узнайте точную версию через SELECT @@version; и откуда она взялась: пакет дистрибутива, репозиторий Oracle, тег Docker или хостинг-провайдер.
2. Сопоставьте её с веткой и датой окончания поддержки по таблицам выше. Всё, что работает на 8.0, 5.7 или на релизе Innovation, не являющемся последним, сейчас не поддерживается.
3. Проверьте, как она обновляется. Пакет дистрибутива следует за дистрибутивом; репозиторий Oracle - за включённой вами веткой; тег Docker - за тем, на что он указывает; размещённая база - за провайдером.
4. Если нужно переехать, выберите целевой LTS, запустите проверку обновления, уберите аутентификацию с mysql_native_password (см. пользователи и привилегии MySQL) и отрепетируйте на копии.
5. Занесите дату окончания поддержки серии, на которой вы окажетесь, в календарь - за год до её наступления.

FAQ#

MySQL 9.7 - это релиз LTS?

Да. MySQL 9.7.0 вышла в апреле 2026 года как вторая серия LTS после 8.4 и закрывает цикл Innovation 9.x, начатый с 9.0. Это также последняя линия релизов с последовательными номерами; последующие релизы используют календарные версии, например 26.7.

Безопасно ли запускать релиз Innovation в production?

Oracle его поддерживает и называет качеством для production, так что это не безрассудство. Подвох в сроке поддержки: каждый релиз Innovation получает патчи только до выхода следующего, поэтому оставаться на поддерживаемой версии значит обновляться с новыми возможностями примерно раз в три месяца, и в каждом обновлении может что-то исчезнуть. Если нет времени тестировать каждое из них, берите LTS.

Можно ли обновиться с MySQL 8.0 сразу до 9.7?

Не на месте. Поддерживаемый путь на месте - с 8.0 на 8.4, затем с 8.4 на 9.7. Логический дамп с 8.0, загруженный в чистый сервер 9.7, обычно срабатывает, если никакие учётные записи не зависят от mysql_native_password, а проверка обновления не сообщает ничего серьёзного.

Что даёт mysql:latest в Docker?

Текущий релиз Innovation - 26.7 по состоянию на октябрь 2026 года. Он меняется каждый квартал. Для важной базы закрепляйтесь на mysql:8.4 или mysql:9.7, а не на latest и не на lts, поскольку lts перейдёт на следующий LTS, когда тот выйдет.

Обязательно ли уходить с MySQL 8.4 на 9.7?

Нет. У 8.4 premier-поддержка до апреля 2029 года и extended до апреля 2032 года, и она продолжает получать квартальные патч-релизы. Переход на 9.7 стоит запланировать до 2029 года, но раньше никакого срока нет.

MariaDB - это версия MySQL?

Нет. MariaDB началась как ответвление MySQL 5.5 и теперь является отдельной базой данных со своими версиями и графиком поддержки. Debian устанавливает её, когда вы просите default-mysql-server. Для большинства клиентов она говорит на том же протоколе, но её файлы данных и новые возможности не взаимозаменяемы с MySQL 8.4 или 9.7.