MySQL 26.10: сервер и драйвер обновляются по разным правилам

Выход MySQL 26.10 не означает, что сервер базы и все драйверы надо перевести на одинаковый номер. Oracle различает LTS/Innovation для Server и NDB Cluster и Single Release для Shell, Router, Connectors и Operator. План обновлений нужно строить по компонентам и их совместимости, а не выравнивать цифры ради порядка.

Октябрьский выпуск продолжает несколько веток

Release notes MySQL 26.10.0 указывают дату 20 октября 2026 года. Объявление GA от 21 октября перечисляет 26.10 Innovation вместе с обновлениями 9.7.4 LTS и 8.4.13 LTS. Поэтому новость о новом номере не означает прекращения всех LTS-вариантов.

Разъяснение моделей выпуска Oracle опубликовано ещё в августе и служит контекстом октябрьского события. Calendar-номера начались с 26.7. У вспомогательных продуктов общий номер не делает выпуск отдельной Innovation-веткой или новой LTS-линейкой.

Сначала инвентаризация, затем выбор обновления

В заявке на сопровождение часто пишут только «у нас MySQL». Для решения этого мало: приложение использует конкретный драйвер, доступ может проходить через Router, а административные операции — выполняться другим инструментом. Каждый участник цепочки имеет свою версию и собственную зависимость от окружения.

Это наша ведомость зависимостей. Она не является матрицей, обещающей совместимость любого коннектора с любой старой базой. Для точного сочетания обращайтесь к документации продукта и выбранного выпуска. Наличие строки в таблице не означает, что компонент обязательно установлен у читателя.

Почему драйвер может двигаться вперёд отдельно от базы

Oracle прямо предлагает использовать актуальный поддерживаемый выпуск продуктов Single Release, даже если Server остаётся на LTS. Из этого не следует совет обновлять пакет в приложении без чтения изменений. Нужно подтвердить применимую поддержку и проверить то, как ваше приложение пользуется соединением.

В учебной схеме веб-сервис остаётся на согласованной LTS-ветке сервера, а команда планирует обновить коннектор. Предмет проверки — вход в систему, чтение нужных данных, запись тестового изменения и обработка ошибки. Обновление драйвера не должно незаметно превратиться в несогласованный переход самой базы на другую модель выпусков.

Не сводить совместимость к успешному подключению

Соединение может установиться, а конкретная операция выполняться иначе или завершаться отказом. Выберите характерный путь приложения и ожидаемый результат. Отдельно проверьте, что при ошибке система не сообщает пользователю об успешном сохранении и не теряет связь операции с запросом.

Для оценки обновления запишите исходные версии, изменяемый компонент и условия проверки. Если одновременно заменить сервер, драйвер и часть приложения, найденное расхождение труднее отнести к причине. Мы советуем ограничивать каждую проверку понятным изменением, когда это позволяет архитектура проекта.

Результат выбора — несколько согласованных решений

1. Перечислите фактически используемые компоненты MySQL.
2. Определите их модели выпуска по документации Oracle.
3. Выберите поддерживаемую ветку Server под требования проекта.
4. Сверьте точные сочетания соединяющих компонентов с этой веткой.
5. Проверьте изменения по характерным операциям на отдельной среде.
6. Зафиксируйте порядок выпуска и план восстановления данных.

План восстановления не означает гарантированный downgrade между произвольными версиями. Если сценарий возврата нужен, его условия проверяют отдельно. Выбор LTS сам по себе также не выполняет резервное копирование и не подтверждает пригодность сделанной копии.

В сопровождении серверов храните ведомость компонентов вместе с планом обновлений. Для разработки веб-приложения фиксируйте драйвер как часть поставки, а при переносе системы отдельно проверяйте данные и поддерживаемые пути. Тогда одинаковые номера перестанут подменять действительную совместимость.