MySQL 26.7 получил постквантовую защиту TLS и перешёл на календарные версии

Oracle выпустила MySQL 26.7.0 с поддержкой постквантовых алгоритмов в TLS 1.3 и новым форматом нумерации по году и месяцу. Сервер умеет предпочитать гибридный обмен ключами с сохранением совместимости, а администраторы получили настройки для поэтапного ужесточения защиты и проверки реально согласованных алгоритмов.

Шифрованный трафик можно сохранять годами в расчёте расшифровать его будущими квантовыми системами. Такой сценарий получил название «собрать сейчас, расшифровать позже», и именно против него Oracle начала перестраивать защиту сетевых соединений MySQL.

28 июля 2026 года компания опубликовала MySQL 26.7.0 и отдельное техническое объяснение поддержки постквантовой криптографии. Релиз затрагивает соединения приложений с сервером, административные каналы и репликацию. Одновременно MySQL сменил привычную последовательную нумерацию версий и открыл плагин Thread Pool для Community Edition.

MySQL 26.7 впервые поддерживает постквантовый обмен ключами в TLS 1.3

MySQL 26.7 может использовать алгоритмы Post-Quantum Cryptography, или PQC, предоставляемые OpenSSL 3.5 и более новыми версиями библиотеки. На первом этапе Oracle сосредоточилась на TLS 1.3: сервер и клиент могут согласовать постквантовую группу обмена ключами, объявить поддерживаемые алгоритмы подписи и показать администратору результат рукопожатия.

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

Функция относится к TLS-соединениям между компонентами MySQL. Шифрование дисков, таблиц, журналов и резервных копий настраивается отдельными средствами.

Сценарий	До MySQL 26.7	MySQL 26.7
Обмен ключами в TLS	Классические группы OpenSSL	Гибридные и чистые PQC-группы при OpenSSL 3.5+
Совместимость со старыми клиентами	Обычные классические алгоритмы	Классический резервный вариант включён по умолчанию
Принудительное требование PQC	Специальной серверной настройки не было	Переменные семейства `force_pqc`
Контроль согласованного алгоритма	Общий статус шифра TLS	Отдельные статусы обмена ключами и подписи

Защита охватывает подключения приложений, администрирование и репликацию

Постквантовые параметры разделены по каналам. Это позволяет испытать новый обмен ключами на административном подключении или отдельном канале репликации, не меняя сразу всю инфраструктуру.

Поддержка заявлена для следующих соединений:

основной канал клиент — сервер;
административные подключения;
асинхронная репликация;
восстановление Group Replication;
межгрупповые каналы Group Replication при использовании стека MySQL;
подключения X Plugin.

Стек XCom внутри Group Replication в текущую область поддержки не входит. Для кластеров это существенная деталь: в MySQL 26.7 значение group_replication_communication_stack по умолчанию изменено с XCOM на MYSQL, а сама переменная помечена как устаревающая.

Раздельные параметры снижают риск массового отказа соединений. Администратор может включить строгую политику только там, где версии серверов, коннекторов и TLS-библиотек уже проверены.

Гибридные алгоритмы сохраняют совместимость во время перехода

По умолчанию MySQL предпочитает гибридные группы, объединяющие классический алгоритм и ML-KEM. После них идут чистые варианты ML-KEM, затем классические группы. Такая последовательность даёт постквантовую составляющую современным клиентам и оставляет рабочий путь для систем без нужной поддержки OpenSSL.

В список входят гибридные X25519MLKEM768, secp384r1MLKEM1024 и secp256r1MLKEM768, чистые MLKEM512 и MLKEM768, а также классические X25519, secp384r1, secp256r1 и secp521r1. Названия чувствительны к регистру.

Для основного канала порядок можно задать в конфигурации:

[mysqld]
tls_kex=X25519MLKEM768:secp384r1MLKEM1024:X25519

Строгий режим включается отдельно:

[mysqld]
tls_version=TLSv1.3
force_pqc=ON

Переменная force_pqc по умолчанию выключена. При её активации сервер отклоняет новые TLS-сеансы, если клиент не согласовал PQC-совместимую группу обмена ключами. Аналогичные настройки предусмотрены для администрирования, репликации, Group Replication и X Plugin.

У старого драйвера, клиента с TLS 1.2 или системы с библиотекой без нужных групп такое соединение завершится ошибкой. Поэтому Oracle предлагает начинать с режима совместимости, наблюдать за результатами рукопожатий и включать жёсткое требование для каждого канала отдельно.

Подписи ML-DSA включаются после проверки сертификатов и провайдеров

MySQL 26.7 умеет объявлять во время TLS-рукопожатия постквантовые алгоритмы подписи ML-DSA-44, ML-DSA-65 и ML-DSA-87. За это отвечает семейство параметров use_pqc_sign, которое изначально выключено.

Включение параметра меняет перечень алгоритмов, предлагаемых участнику соединения. Сервер при этом не создаёт постквантовые сертификаты автоматически. Итоговый выбор зависит от второй стороны, конфигурации OpenSSL, подключённого криптографического провайдера и доступных сертификатов.

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

Новые статусы показывают алгоритм каждого TLS-сеанса

До включения строгой политики администратору нужно увидеть, какие алгоритмы действительно выбирают приложения. MySQL 26.7 добавляет два статуса текущего сеанса:

SHOW SESSION STATUS LIKE 'Tls_key_exchange_algorithm';
SHOW SESSION STATUS LIKE 'Tls_sign_algorithm';

Первый запрос показывает согласованную группу обмена ключами, второй — алгоритм подписи рукопожатия. Текущий шифр по-прежнему доступен через Ssl_cipher.

Для основного и административного каналов таблица performance_schema.tls_channel_status получила параметры Force_pqc, Use_pqc_sign и Tls_kex. У X Plugin предусмотрены глобальные статусы Mysqlx_force_pqc, Mysqlx_tls_kex и Mysqlx_use_pqc_sign.

На практике безопасный переход выглядит последовательно:

проверить, что сборка MySQL связана с OpenSSL 3.5 или новее;
убедиться, что нужные каналы используют TLS 1.3;
оставить force_pqc выключенным и собрать данные о согласованных алгоритмах;
обновить несовместимые коннекторы и промежуточные компоненты;
включать use_pqc_sign и force_pqc только на проверенных каналах.

Эти шаги помогают обнаружить устаревший драйвер до того, как он перестанет подключаться к рабочей базе.

Версия 26.7 указывает на июль 2026 года

MySQL 9.7 стал последним выпуском с последовательной нумерацией. Начиная с MySQL 26.7 Oracle использует формат YY.M.P: год, запланированный месяц релиза и номер исправления. Версия 26.7.0 расшифровывается как июльский выпуск 2026 года с нулевым номером патча.

Модель релизов MySQL по-прежнему разделена на LTS и Innovation. LTS-линейки рассчитаны на стабильный набор возможностей и длительную поддержку. Innovation-выпуски быстрее получают функции, изменения поведения и удаления устаревших механизмов; их поддержка длится до следующего Innovation-релиза.

Для администраторов новый номер упрощает определение возраста сборки. Одновременно он требует внимательнее смотреть на ветку выпуска: календарное обозначение само по себе не сообщает, относится версия к LTS или к Innovation.

Thread Pool пришёл в Community Edition, репликация получила новый CSA

Постквантовый TLS стал самым заметным изменением MySQL 26.7, хотя релиз содержит ещё две крупные серверные новинки.

Плагин MySQL Thread Pool, ранее доступный только в Enterprise Edition, появился в Community Edition 26.7.0. Он управляет рабочими потоками сервера и помогает ограничивать издержки при большом числе одновременных подключений. Значение thread_pool_max_unused_threads по умолчанию выросло с 2 до 32.

Для многопоточной репликации Oracle представила Change Stream Applier, сокращённо CSA. Новый обработчик включается отдельно для каждого канала и работает как альтернатива Multi-Threaded Applier. Число рабочих потоков можно задать в диапазоне от 1 до 1024 для каждого канала независимо.

CSA разделяет применение транзакций и порядок фиксации. Рабочий поток, ожидающий возможности выполнить COMMIT, может заняться другой готовой транзакцией. Состояние обработчиков и конфигурация доступны через Performance Schema.

Технология пока включается вручную через APPLIER_VERSION = 2. Она рассчитана на репликацию с GTID и построчным бинарным журналом; задержанная репликация, файловые позиции и ряд старых режимов не поддерживаются. Для действующих топологий это повод начать с тестового канала и сравнить задержку, потребление памяти и поведение при остановке реплики.

Переход на MySQL 26.7 требует тщательной проверки приложений и топологии сети

MySQL 26.7 содержит новые функции, изменения значений по умолчанию и удалённые параметры. В частности, из сервера убраны group_replication_allow_local_lower_version_join и replica_parallel_type, а коммуникационный стек Group Replication движется в сторону реализации MySQL.

Командам на MySQL 8.4 LTS или 9.7 LTS стоит рассматривать переход как отдельное обновление ветки. Тестовый прогон должен охватывать драйверы приложений, прокси, MySQL Router, резервное копирование, репликацию и сценарии аварийного восстановления.

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

MySQL начал готовить сетевой слой к угрозе, сроки которой пока нельзя точно назвать. Практический эффект релиза виден уже сегодня: администратор получает управляемый путь перехода, наблюдаемость TLS и возможность усиливать защиту без одномоментной замены всей инфраструктуры.