MariaDB Foundation 17 сентября объявила ветку MariaDB Server 13.0 стабильной, а версия 13.0.2 стала её первым релизом со статусом Stable (GA). За переход от RC к Stable разработчики внесли 604 дополнительных коммита, затронули 1 701 файл и закрыли 335 задач MDEV — за сменой статуса стоит заметный объём тестирования и исправлений.
MariaDB 13.0.2 стала первой Stable-версией ветки 13.0
Серия MariaDB 13.0 прошла три этапа за полгода. Preview 13.0.0 появился 23 марта 2026 года, Release Candidate 13.0.1 — 29 мая, а MariaDB 13.0.2 была опубликована 15 сентября. Через два дня, 17 сентября, MariaDB Foundation официально объявила ветку 13.0 стабильной и пригодной для общего использования.
Смена статуса здесь важнее номера патча. Между RC и Stable в ветку 13.0 добавили 604 коммита и изменили 1 701 файл. По данным MariaDB Foundation, разработчики добавили 23 748 строк тестового кода, из них 4 222 строки пришлись непосредственно на тестовые сценарии mysql-test, и обработали 335 задач MDEV.
Такая статистика показывает, чем этап Stable отличается от ранних сборок. Preview приносит основную функциональность, RC переводит внимание на совместимость и регрессии, а Stable фиксирует уровень зрелости, при котором MariaDB считает релиз пригодным для обычных сред эксплуатации.
Есть и важная деталь в схеме версий. MariaDB 13.0 относится к rolling release: ветка получает новые возможности быстрее, но имеет более короткий жизненный цикл, чем LTS-линейки. Статус Stable описывает зрелость конкретной ветки, а LTS — длительность сопровождения.
UPDATE RETURNING сокращает обмен между приложением и сервером
Одна из самых заметных SQL-возможностей MariaDB 13.0.2 — UPDATE ... RETURNING для обновлений одной таблицы. После изменения записи сервер может сразу вернуть значения изменённых столбцов в том же запросе.
В сочетании с функцией OLD_VALUE() приложение способно получить прежнее и новое значение поля за один сетевой обмен. Раньше типичный сценарий требовал отдельного SELECT до или после UPDATE, если приложению нужно было узнать состояние строки.
Практический эффект особенно заметен в API, очередях и сервисах, где одно изменение записи запускает дальнейшую бизнес-логику. Меньшее число SQL-запросов означает меньше сетевых переходов между приложением и базой и упрощает обработку результата операции.
У функции пока есть чёткая граница: RETURNING поддерживается для UPDATE одной таблицы. Multi-table UPDATE в MariaDB 13.0.2 эту возможность не получил. Ограничение прямо указано в официальных release notes.
InnoDB получил непрерывное архивирование журнала
В MariaDB 13.0 появилась системная переменная innodb_log_archive. При её включении InnoDB сохраняет write-ahead log в непрерывной последовательности файлов. Обычная схема использует кольцевой журнал, где старые участки со временем перезаписываются.
Непрерывный архив открывает основу для восстановления базы на выбранный момент времени и для будущих сценариев инкрементного резервного копирования. Для администратора это меняет сам набор данных, доступных после сбоя: журнал можно хранить дольше, чем позволяет стандартный циклический набор redo-файлов.
Функция уже входит в Stable-релиз, но вокруг неё сохраняется существенное ограничение. mariadb-backup пока не умеет работать с форматом журнала при innodb_log_archive=ON и завершает работу с ошибкой на таком сервере. В документации MariaDB для текущей версии описана ручная процедура восстановления Point-in-Time Recovery.
История changelog показывает, что перед Stable разработчики отдельно исправляли несколько проблем этого механизма: повреждение архива, ошибки восстановления и сбои при переключении innodb_log_archive. Именно эта доработка между RC и 13.0.2 объясняет, почему статус зрелости релиза имеет практический вес.
REF CURSOR и RECORD расширяют совместимость процедурного SQL
MariaDB 13.0.2 добавляет поддержку TYPE ... IS REF CURSOR внутри пакетных процедур и разрешает использовать RECORD в параметрах процедур и в возвращаемом типе функций пакета.
Эти конструкции знакомы разработчикам, работающим с Oracle-подобным процедурным SQL. REF CURSOR позволяет передавать ссылку на результирующий набор, а RECORD описывает составную структуру из нескольких полей. Для миграции сложной серверной логики это снижает количество мест, где код приходится переписывать под синтаксис MariaDB.
Поддержка пока ограничена пакетами. REF CURSOR и RECORD можно использовать в package routines и PACKAGE BODY, включая параметры и возвращаемые значения функций пакета. Для глобальных процедур вне пакета такие параметры и return-типы в 13.0.2 ещё не поддерживаются.
Метаданные MariaDB стали полезнее для автоматической диагностики
Несколько изменений в MariaDB 13.0.2 ориентированы на инструменты администрирования и автоматический анализ конфигурации.
Таблица INFORMATION_SCHEMA.SYSTEM_VARIABLES получила поля IS_DEPRECATED и DEPRECATED_REPLACEMENT. Теперь программа мониторинга или миграционный скрипт может определить устаревшую системную переменную напрямую из сервера и узнать её замену, без разбора текста release notes.
INFORMATION_SCHEMA.STATISTICS и INFORMATION_SCHEMA.COLUMNS теперь показывают engine-specific create options. Для блоков запросов добавлен hint QB_NAME(): он позволяет точнее адресовать подсказки оптимизатору внутри CTE, представлений и derived tables.
Изменился и механизм digest в PERFORMANCE_SCHEMA: MariaDB перешла на XXH3_128. Формат остаётся похожим на привычный хеш, а вычисление выполняется быстрее и не создаёт проблем в FIPS-режиме, связанных с использованием MD5.
Репликация и аудит получили небольшие, но конкретные изменения
В MariaDB 13.0.2 значение роли репликации, заданное параметром запуска --init-rpl-role, стало доступно через SHOW VARIABLES и SELECT @@init_rpl_role. Раньше эту настройку приходилось искать в конфигурации сервера.
Для binlog_row_event_max_size значение по умолчанию увеличено до 64 КБ. Переменную default_master_connection теперь можно задавать на глобальном уровне. Команда CHANGE MASTER сбрасывает Master_Server_Id в выводе SHOW SLAVES STATUS, что делает состояние репликации более предсказуемым после перенастройки.
Audit Plugin получил настраиваемый формат временных меток. Для систем, где журналы MariaDB объединяются с логами приложений, прокси и инфраструктуры, единый формат времени упрощает сопоставление событий.
DuckDB появился рядом с InnoDB в виде экспериментального движка
В свежем объявлении MariaDB Foundation отдельно выделяет интеграцию DuckDB. MariaDB может подключать DuckDB как storage engine и использовать его колоночную модель хранения и векторизованное выполнение аналитических запросов рядом с транзакционными таблицами InnoDB.
Идея даёт интересный сценарий: операционные и аналитические таблицы могут находиться в одной среде MariaDB и участвовать в одном SQL-запросе. Такой подход ориентирован на отчёты, лёгкую аналитику, HTAP-эксперименты и работу с форматами вроде Parquet.
Здесь статус отличается от основного сервера. MariaDB 13.0.2 получила Stable (GA), а DuckDB storage engine в объявлении Foundation обозначен как gamma. Пакет MariaDB-duckdb-engine для версии 13.0.2 уже присутствует в репозитории MariaDB, но зрелость самого движка остаётся отдельной от зрелости MariaDB Server.
Stable-релиз включает исправления безопасности без полного раскрытия деталей
MariaDB Foundation сообщает, что ветка 13.0 включает исправления нескольких уязвимостей, часть которых была передана независимыми исследователями через HackerOne.
Подробности по некоторым проблемам пока не опубликованы. Foundation объясняет это стандартным процессом ответственного раскрытия: технические детали и CVE появляются после того, как исправленные версии становятся доступными и проходит время для обновления инфраструктуры.
Поэтому перечень новых функций показывает только часть работы, попавшей в 13.0.2. Параллельно команда проверяла отчёты по безопасности, воспроизводила ошибки, оценивала влияние исправлений и тестировала возможные регрессии.
MariaDB 13.0.2 закрепила новую Stable rolling-ветку
После объявления 17 сентября MariaDB 13.0.2 занимает понятное место в линейке: это Stable (GA) релиз ветки 13.0, опубликованный 15 сентября 2026 года. Следующая линия 13.1 уже существует, но версия 13.1.1 на ту же дату имеет статус RC.
В 13.0.2 сошлись несколько направлений разработки: SQL получил UPDATE ... RETURNING и расширения для процедурных типов, InnoDB — архивирование журнала, системные таблицы — больше диагностических данных, а репликация и аудит — дополнительные параметры управления. Рядом развивается DuckDB storage engine, который пока остаётся на стадии gamma.
Два вопроса сохраняют практическую неопределённость вокруг этой ветки. Первый связан с тем, когда mariadb-backup получит поддержку нового формата innodb_log_archive. Второй — когда DuckDB engine выйдет из gamma и получит более высокий уровень зрелости. В опубликованном 17 сентября объявлении MariaDB Foundation сроки для этих этапов не названы.
