17 сентября 2026 года в 06:30 UTC на mariadb.org вышел пост: ветка MariaDB Server 13.0 стала Stable. Конкретный номер – 13.0.2. Это rolling-релиз Foundation, не LTS и не пакет, который завтра сам приедет из Ubuntu или Debian.
Серия стартовала в марте 2026 Preview. Дальше Release Candidate. Теперь ярлык Stable. Автор поста, Frédéric Descamps, пишет прямо: апгрейд имеет смысл, если нужны новые фичи этой ветки. На стенд или на прод. Но это не long-term support.
13.0.2 Stable, не LTS
Stable здесь про зрелость сборки. Rolling про путь обновлений. Окно сопровождения у rolling короче, чем у LTS. Для среды, где важны годы без смены мажора, Foundation по-прежнему указывает последнюю LTS-серию. 13.0 – для тех, кто хочет идти за SQL, оптимизатором и наблюдаемостью ближе к апстриму.
Между RC и Stable в ветку вошло 604 коммита. Затронуто 1701 файл. Добавили 23748 тестовых строк, из них 4222 только в mysql-test. Закрыли 335 MDEV. Это не смена шильдика на той же сборке.
Фичи из Preview не стали другими от слова Stable. Поменялась зрелость и уровень уверенности, с которым их можно ставить. Preview показывал направление. Stable говорит: цикл разработки для этой серии пройден, сборка годится для общего использования. «Годится» не равно «ваше приложение уже прогнало свои запросы».
Preview доехал не целиком
Мартовский анонс Preview вышел 23 марта 2026. Stable-пост его не переписывает. Там SQL и stored-program, хинт QB_NAME(), богаче метаданные, архив InnoDB redo, смена дайджестов Performance Schema, правки бинлога и репликации, настраиваемый timestamp у audit plugin.
Из Preview, который Foundation сама перечисляет как основу серии:
- TYPE .. IS REF CURSOR и RECORD в параметрах процедур и в RETURN функций.
- Оптимизаторный хинт QB_NAME().
- INFORMATION_SCHEMA.SYSTEM_VARIABLES помечает deprecated. STATISTICS и COLUMNS отдают engine-specific create options.
- Audit plugin: настраиваемый формат timestamp.
- innodb_log_archive: архив WAL InnoDB вместо кольцевого затирания redo.
- Performance Schema считает дайджесты через XXH3_128.
- Дефолт binlog_row_event_max_size теперь 64 KB. default_master_connection можно ставить глобально. CHANGE MASTER сбрасывает Master_Server_Id в SHOW REPLICA STATUS.
- Быстрее unique indexes на CHAR в MEMORY-таблицах.
Часть заявленного в марте до 13.0.2 не доехала. В сентябрьском посте названы два пункта: Optimizer Trace со статистикой, которую оптимизатор реально использовал (MDEV-38701), и атомарный CREATE OR REPLACE TABLE (MDEV-25292). Не тащите их в чеклист «уже в Stable». Точной даты, когда они появятся, в тексте нет.
Отдельно: 13.0 закрывает несколько уязвимостей. Часть пришла через HackerOne. Номеров CVE в посте нет. Foundation пишет, что детали появятся в официальной security-документации, когда их раскроют, и указывает GitHub Security Advisories. Я идентификаторы не подставлю.
innodb_log_archive
Из Preview отдельно разобран innodb_log_archive. Глобальная динамическая переменная. Включает архив redo InnoDB, чтобы старые записи не исчезали, когда кольцевой лог оборачивается. Имеет смысл, когда бэкап не успевает за wrap WAL. План, который описывает Foundation: полный бэкап, запомнить LSN, позже докопировать archived redo и накатить с этого LSN. Это первый шаг, не готовый контур восстановления.
На типичном VPS с WordPress бэкап чаще живёт через дамп или плагин, не через replay redo. Переменная сама по себе wp_posts не чинит и mysqldump не ускоряет. Включать её «потому что Stable» без места на диске и без понимания, кто эти файлы заберёт, не стоит. Файлы архива в Preview выглядят как ib_*.log, размер совпадает с innodb_log_file_size. Статус Innodb_lsn_archived показывает самый ранний LSN, для которого история ещё есть.
SET GLOBAL innodb_log_archive=ON; SHOW GLOBAL VARIABLES LIKE 'innodb_log_archive'; SHOW GLOBAL STATUS LIKE 'Innodb_lsn%';
DuckDB-движок в gamma
В Stable-посте отдельно стоит DuckDB как storage engine. Колоночное хранение и векторизованный OLAP рядом с InnoDB. Операционные и аналитические таблицы в одном сервере, даже JOIN в одном SQL. Движок в gamma. Автор пишет прямо: в прод в пятницу это не катит.
В примере пакета – RPM: MariaDB-duckdb-engine 13.0.2-1.el9, репозиторий mariadb, около 15 МБ. Это el9, не пакет из Ubuntu apt. Имени deb-пакета в посте нет, и я его не выдумаю. Для WordPress на одном VPS DuckDB не замена InnoDB под wp_posts. HTAP, отчёты, Parquet – отдельный стенд, не пятничный apt upgrade на сайте.
Ubuntu, Debian и WordPress рядом
Типичный VPS с сайтом держит MariaDB из репозитория дистрибутива. 13.0.2 из этого apt сам не приедет. Это релиз апстрима: свои репозитории Foundation и страница загрузок 13.0.2. Смешивать пакеты Ubuntu или Debian с MariaDB.org в одном sources.list «чтобы попробовать 13» – обычный способ получить поломанные зависимости и два mysqld, которые не договариваются про сокет.
Не путать с MySQL 8.x. Протокол похож, ветки и пакеты разные. WordPress ходит в MariaDB как в MySQL-совместимый сервер. RECORD, REF CURSOR и QB_NAME() плагинам WP обычно не нужны. Им нужен тот же протокол, те же типы и чтобы дамп потом открылся.
Обновлять прод-WordPress на 13.0 в день анонса не требуется. Stable значит «можно ставить и тестировать», не «уже на всех продах». Сначала стенд, бэкап, прогон админки и тех плагинов, которые сами пишут SQL или читают INFORMATION_SCHEMA. Копию datadir и /etc/mysql (или /etc/mysql/mariadb.conf.d) делать до смены репозитория, не после первого отказа.
Если цель – закрыть дыры текущей ветки, ждать security-апдейт своего дистрибутива, а не прыгать на rolling 13.0. Номера CVE Foundation в этом посте не назвала. nginx -t и reload PHP-FPM «за компанию» эта новость не просит. База обновляется отдельно от веба.
mariadb --version mysql --version apt-cache policy mariadb-server
13.0.2 – milestone rolling-серии. Для стенда и тех, кому нужны QB_NAME, архив redo и наблюдаемость. Для бетона на годы – LTS. DuckDB пока gamma. Пакет дистрибутива сам на 13 не переедет.
