Оглавление

23 ноября 2025 года вышел первый стабильный релиз ветки MariaDB 12.1 — версия 12.1.2. Эта ветка относится к rolling-релизам: фичи сюда прилетают быстрее, чем в долгоживущие LTS-линейки, но и обновляться нужно с головой, а не вслепую ночью в пятницу.

Официальный анонс можно посмотреть на сайте MariaDB. А я ниже пробегусь по изменениям простым языком, без маркетинга, с прицелом на реальные сервера — в первую очередь на Debian (Ubuntu тоже можно, но под сервер я всё равно чаще ставлю именно Debian).

Коротко про контекст:

  • MariaDB — это форк MySQL, который давно пошёл своим путём, но сохранил совместимость по протоколу и SQL.
  • Проектом рулит MariaDB Foundation, а не один вендор.
  • Во многих дистрибутивах Linux MariaDB ставится вместо MySQL по умолчанию.

Ветка 12.1 — это:

  • свежие фичи;
  • быстрые минорные релизы;
  • не LTS, то есть не та серия, которую ставят в банки и забывают на годы.

Я бы смотрел на 12.1 так:

  • для новых проектов и тестовых стендов — отличный кандидат;
  • для продакшена — да, но после тестов и с нормальным планом отката;
  • если нужен “бетон” на годы — оставить LTS-ветку и наблюдать.

В движке хранения Aria появился сегментированный кэш ключей. Раньше все лезли в один общий кэш, как к одному холодильнику на общагу. Теперь кэш можно делить на сегменты, и параллельные запросы меньше мешают друг другу.

Настраивается это так:

SET GLOBAL aria_pagecache_segments = 8; -- от 1 до 128, по умолчанию 1

Где полезно:

  • много параллельных запросов;
  • активные Aria-таблицы (логи, временные данные);
  • сервер, который под нагрузкой постоянно “задумывается” на ровном месте.

Чем больше ядер и клиентов — тем заметнее эффект.

MDL (Metadata Lock) — это блокировки на уровне схемы: когда один клиент меняет структуру таблицы, а остальные в это время не должны уехать в параллельную вселенную.

В 12.1 разработчики подтянули масштабируемость MDL. На практике это даёт:

  • меньше подвисаний вида “Table metadata lock”;
  • более предсказуемое поведение при миграциях и тяжёлых DDL;
  • приятную жизнь на серверах с десятками и сотнями подключений.

Если вы используете Galera Cluster, есть хорошая новость: при асинхронной репликации между двумя кластерами теперь можно включить параллельную репликацию.

Типичный сценарий:

  • есть основной кластер;
  • есть резервный или отчётный кластер;
  • между ними крутится репликация.

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

Плагин server_audit наконец-то научился буферизовать записи в файл.

Появилась настройка:

SET GLOBAL server_audit_file_buffer_size = 1048576; -- например, 1 МБ

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

  • меньше I/O;
  • меньше системных вызовов;
  • аудит остаётся подробным, но перестаёт быть тормозом.

Если по требованиям безопасности логировать нужно всё и вся — обновление заметное.

Тип данных VECTOR, который нужен для работы с embedding-ами и “умным” поиском, в 12.1.2 заметно ускорили. Операции поиска по векторам стали примерно на 30–50% быстрее.

Где это может пригодиться:

  • семантический поиск по текстам;
  • подбор похожих товаров/статей/фильмов;
  • рекомендательные системы для небольших проектов, где отдельная векторная база — это уже перебор.

Если вы строите что-то с поиском “по смыслу”, MariaDB 12.1 смотрится гораздо интереснее.

Добавили плагин caching_sha2_password:

  • использует SHA-2 вместо SHA-1;
  • совместим с одноимённым механизмом в новых MySQL.

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

Для режима совместимости с Oracle завезли:

  • ассоциативные массивы (INDEX BY);
  • поддержку синтаксиса внешних объединений через (+).

Если у вас живёт старый Oracle-код, который хочется аккуратно переносить на MariaDB, теперь придётся меньше переписывать руками. Для миграционных проектов это важно.

В 12.1 стало больше опций, которыми можно управлять оптимизатором: [NO_]JOIN_INDEX, [NO_]GROUP_INDEX, [NO_]ORDER_INDEX и так далее.

Смысл простой: если оптимизатор упорно выбирает “не тот” план, вы можете аккуратно ткнуть его носом в нужный путь. Это уже история для сложных отчётных запросов и больших схем, но иметь такие рычаги полезно.

В mariadb-dump появилась поддержка масок через --wildcards. Пример:

mariadb-dump -u root -p -L --wildcards "client*_shop" > shops.sql

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

Пара приятных мелочей:

  • имена внешних ключей (FOREIGN KEY) теперь должны быть уникальны только в рамках таблицы, а не всей БД;
  • появились функциональные индексы — индексы на выражениях, например LOWER(email) или DATE(created_at).

Пример функционального индекса:

CREATE INDEX idx_lower_email ON users ((LOWER(email)));

SELECT *
FROM users
WHERE LOWER(email) = 'user@example.com'
ORDER BY LOWER(email);

Раньше такие запросы плохо использовали индекс и часто всё сортировали в лоб. Теперь оптимизатор понимает, что выражение уже проиндексировано, и работает быстрее.

Стандартные репозитории Debian/Ubuntu обычно живут на более консервативных версиях MariaDB. Если хочется поставить именно 12.1.2, есть два нормальных пути:

  1. Подключить официальный репозиторий MariaDB и поставить mariadb-server-12.1 через apt. Конфиг для APT удобно сгенерировать на сайте MariaDB (там есть генератор репозиториев).
  2. Использовать Docker-образ MariaDB 12.1.2, а данные хранить в примонтированном томе.

Лично я всё чаще выбираю второй вариант:

  • легче откатываться;
  • не мешается с системной MySQL/MariaDB;
  • удобно переносить между серверами.

Моё видение такое.

Обновляться смело:

  • dev-стенды, тестовые окружения;
  • новые проекты;
  • Galera-кластеры, где важна скорость асинхронной репликации;
  • любые истории, где нужен VECTOR, функциональные индексы и свежая Oracle/MySQL-совместимость.

Обновляться аккуратно, но имеет смысл:

  • продакшены на MariaDB 12.0 — логичный шаг пойти дальше на 12.1;
  • крупные инсталляции на 11.x, если очень нужны новые фичи.

Подождать:

  • консервативные системы, где всё и так работает и важнее LTS и предсказуемость;
  • проекты, в которых никто даже не слышал слова “VECTOR”, а база просто хранит обычные таблички.

Чтобы потом не вспоминать этот апгрейд как страшный сон:

  1. Сделать бэкап всего.
    И дамп, и файловую копию каталога данных.
  2. Развернуть тест.
    Поднять копию БД на 12.1.2 и прогнать критичные сценарии и отчёты.
  3. Проверить конфиги.
    Aria, Galera, аудит, логирование, лимиты памяти.
  4. Следить за мониторингом.
    Сравнить нагрузку и задержки “до” и “после”.

MariaDB 12.1.2 — живой, рабочий стабильный rolling-релиз:

  • быстрее Aria и VECTOR;
  • умнее работа Galera;
  • аккуратнее аудит;
  • плюс удобные мелочи вроде функциональных индексов и масок в mariadb-dump.

Если вы на Debian/Ubuntu, любите современные фичи и готовы нормально тестировать, эта ветка явно стоит внимания. Главное — не превращать апгрейд в аттракцион “жми apt upgrade прямо на проде”. Бэкапы, тест, план отката — и MariaDB 12.1 будет радовать, а не портить выходные.