28 сентября 2026 года в 12:50 UTC на mariadb.org вышел пост Джонатана Миллера: Performance Test Automation Framework, TAF 4.0. Тот же текст висит на теге v4.0 в репозитории MariaDB/TAF, коммит e83adb2. Страница GitHub показывает 27 сентября 2026, 21:23. Часовой пояс у этой подписи не указан, поэтому опираться стоит на время поста фонда.
Это стенд, которым фонд гоняет нагрузки на MariaDB, MySQL и теперь PostgreSQL. Не выпуск MariaDB Server. Версия базы, которая уже отвечает сайту, от этого тега сама не сдвигается.
Фонд называет 4.0 самыми большими изменениями каркаса с момента, как его собрали. В заметке к тегу новость укладывается в три вещи: прогон можно повторить, конфиг базы не теряется по дороге, тест-кейс уезжает одним файлом. PostgreSQL добавлен отдельно и помечен как beta.
PostgreSQL в TAF 4.0 пока beta
Плагин базы для PostgreSQL вошёл с PR #7. Его сделал Лукас Олива из Virtuozzo. Virtuozzo в тексте назван спонсором фонда. Вместе с плагином обновили сборку sysbench-lua под PostgreSQL и библиотеку RUN SQL. Смысл, как его пишет фонд: один и тот же пайплайн TAF ведёт себя одинаково на MariaDB, MySQL и PostgreSQL.
Амрендра Кумар отдельно прогнал ранние тесты PostgreSQL и упёрся в установку из .deb. У него два патча. Один про подготовку TPROC-C, второй про сборку sysbench-lua под PostgreSQL. Значит, путь через deb-пакеты PostgreSQL в этом каркасе уже чинили. Это не то же самое, что «поставил postgres из Ubuntu и цифры сопоставимы».
Beta в заметке сказано прямо: ждут отзывы и pull request. Снимать прогон на PostgreSQL уже можно. Читать график как повод переносить WordPress с MariaDB на Postgres нельзя. Поддержка сквозная у стенда, не у вашего сайта.
Гоняли это на двух машинах Hetzner, обе AlmaLinux, не Ubuntu и не Debian.
- hz-bench: Intel Core i5-13500, 14 ядер и 20 потоков, один сокет, 62,33 ГБ памяти, AlmaLinux 9.7, ядро 5.14.0-811.35.1.el9_7.
- hz-bench2: AMD EPYC 9454, 48 ядер и 96 потоков, один сокет, 124,98 ГБ, AlmaLinux 9.8, ядро 5.14.0-687.29.1.el9_8.
Это не профиль VPS, на котором сидит сайт. mpstat с такой коробки и mpstat с пары гигабайт рядом с php-fpm отвечают на разные вопросы. Цифру со стенда фонда на свой тариф не переносят.
Конфиг, который остаётся с результатом
Старая боль бенчмарка: цифра есть, а my.cnf, которым её сняли, уже другой. В 4.0 конфиг базы можно вложить прямо в user properties, между маркерами [db_config_start] и [db_config_end].
Порядок жёсткий. Сначала побеждает командная строка. Потом блок внутри properties. Потом ссылка db_config_file. Выигравший вариант пишут во временный файл, этим файлом поднимают базу, его же кладут в архив результата и отдают репортёрам и бэкенду. Рядом появляется отдельный properties тест-кейса: исходные свойства без db_config_file, то, что пришло из CLI, и выигравший конфиг. Кейс можно прогнать ещё раз, не ища исходник по чатам.
README.txt прогона теперь включает и конфиг, и этот properties. Поля, которые зависят от конкретного теста, перенесли из WriteReadmeStart в WriteReadmeEnd. На серии из нескольких тестов README больше не штампуется конфигом, который ещё не выбран. Для мульти-прогона это как раз и чинили: метаданные README писались слишком рано.
Репортёры и бэкенд читают метаданные прогона, а не внешний файл, который к утру уже поправили руками. Фонд называет это закрытием старой дыры в происхождении конфига. Не дыры безопасности. Дыры в том смысле, что отчёт и cnf разъезжались.
Часть запросов к каркасу пришла от Монти, автора MySQL и MariaDB. Задача MDEV-39497 отдельно толкнула ключ –test-case-tag. В properties это taf.test_case_tag. Пост пишет, что результаты, приложенные к этой задаче, сняты бетой TAF 4.0, не финальным тегом. Что именно лежит в тикете, пост не пересказывает.
Рядом новые ключи –dump-run-state (taf.dump_run_state) и пара –exec-script-file-before-tests / –exec-script-file-after-tests. Имена есть. Готового скрипта под WordPress в релизе нет, и выдумывать его не из чего. Скрипт до и после прогона имеет смысл только на машине, где TAF поднимает свою базу, не на VPS, который в эту минуту отдаёт сайт.
Утилита RenameResultsTestCaseTag.sh после прогона переименовывает каталог результата и связанные raw, text, CSV и JSON. Берёт test_case_tag из основного отчёта. Иначе архив живёт под именем, которое с меткой не совпадает, и сравнение двух прогонов начинается с путаницы в путях.
Режим восстановления, PR #9, Виктор Ганелес из той же Virtuozzo, заново прогоняет первую итерацию восстановленного хранилища. В заметке цель короткая: убрать перекос и синхронизировать состояние, а не продолжать со сдвинутой первой точки. Если сравниваете старый recovery-прогон с новым, первая итерация теперь другая по построению. Разница может быть из этой пересъёмки, не из движка.
Новые файлы конфигурации: comparable, minimal, default, analytics и OLTP. Отдельно для MariaDB, MySQL и PostgreSQL. Содержимое каждого cnf в посте не разобрано. Подставлять их в конфиг боевого сервера незачем. Это профили стенда.
Установщик и SSL тестового демона
DatabaseSoftwareInstall стал злее. Это место, где чужой datadir легко подсунуть не туда.
Разбор списка пакетов починили: скаляр снова становится массивом ссылок. Предупреждения подняли до ошибок. Если целевой каталог уже есть, установка отказывается. Если после распаковки нет нормального install_root, это жёсткий отказ. Пустая или кривая проверка пакета тоже отказ. Если из имени пакета нельзя вывести каталог установки, отказ. Логику выбора ACTIVE поправили и печатают её заново.
Отказ на существующем каталоге здесь защита. Каталог, где уже лежат данные WordPress, как раз существует. TAF ставит свой экземпляр сервера для прогона, а не «мерит прод». Обходить отказ и указывать боевой каталог не нужно. Даже отдельный стенд на том же VPS, где крутятся nginx и php-fpm, снимет не базу, а всю коробку целиком. У фонда под это были отдельные машины на 62 и 125 ГБ.
Отдельная починка про SSL, и она не про сертификат сайта. Обёртка, которая поднимала MariaDB и MySQL в фоне, была пережата: setsid(), закрытие дескрипторов, дублирование STDERR. Из-за этого инициализация WolfSSL и OpenSSL иногда ломалась, тестовый демон не стартовал с SSL. Обёртку переписали на короткий fork/exec. Речь про процесс, который TAF сам порождает на стенде. certbot, acme.sh и то, чем nginx терминирует HTTPS, этот патч не трогает. Перевыпускать сертификат из-за TAF 4.0 не из чего.
У HammerDB в наборе TPROC-C настройки SSL уезжали не в тот словарь и не с теми ключами. Для MariaDB и MySQL шифрование соединения в тесте просто игнорировалось. Для других движков собиралось криво. Настройки перенесли в словарь соединения и выставили параметры HammerDB по типу базы. Старый прогон TPROC-C «без SSL» и новый «с SSL» сравнивать в лоб нельзя: разница может быть из обвязки.
На VPS после этой новости проверяется не nginx. Прокси, FastCGI-кэш и пул php-fpm пост не меняет. Смотрят версию той базы, которая уже обслуживает сайт. Она не должна сдвинуться из-за тега v4.0. Если сдвинулась, пакет приехал из другого источника.
mariadb --version mysql --version
На Debian и Ubuntu часто жива одна из этих команд, не обе. Какая ответила, та и есть сервер. mysql_upgrade из релиза TAF не следует: системные таблицы он не просит трогать. Бэкап нужен, только если вы сами копируете данные на отдельный стенд. Боевой конфиг MariaDB ради этого тега не правят. Копию снимают, когда правят свой стендовый cnf, не /etc на проде «на всякий случай».
TidesDB, сборщики и сырой отчёт
Алекс Падула, автор TidesDB, отдал конфиги сравнения с InnoDB в PR #8. В дереве тега это такие пути:
- database_config_files/mariadb/innodb_compare_local.cnf
- database_config_files/mariadb/tides_compare_local.cnf
- database_config_files/mariadb/tides_compare_v10.cnf
- properties/mariadb/sysbench_local_tidesdb_innodb.properties
- properties/mariadb/sysbench_tidesdb10_innodb_rocks_compare.properties
TidesDB от этого поста не становится движком таблиц WordPress. Файлы нужны, чтобы гонять sysbench на стенде рядом с InnoDB. На сайте с обычным InnoDB они ничего не включают. В properties есть и сравнение с Rocks. Это опять стенд, не строка в my.cnf прода.
Сборщики насыщения машины: taf_collect_mpstat.sh, taf_collect_perf_sched.sh, taf_collect_pidstat.sh, taf_collect_sarq.sh. Старт и стоп вынесены в taf_start_collectors.sh и taf_stop_collectors.sh. Они смотрят CPU, планировщик, процессы и очередь. На VPS, где в ту же секунду отвечает php-fpm, в цифры попадёт сайт, не «чистая» база. Для такого прогона нужна отдельная машина. Хотя бы по смыслу тех двух AlmaLinux, не окно в обед на проде.
Во все наборы добавили client_cpu_affinity. У hammerdb_tprocc и hammerdb_tproch появилась уборка каталога состояния и пропали тайминги, которые к HammerDB не относятся. В sysbench_lua добавили NormalizeDBType, чтобы тип базы в обвязке назывался одинаково. Мелочь, из-за которой два отчёта раньше нельзя было положить рядом.
ResultsCompareRaw.pl собирает HTML заново из сырого результата. В первичный показатель можно вынести не тот, что у набора по умолчанию. Ключ один: –metric-name=. Имени метрик в анонсе нет. Подставлять своё бессмысленно: скрипт ждёт то, что реально лежит в raw этого прогона.
В конце поста фонд зовёт MySQL, PostgreSQL и остальных вендоров забирать TAF себе. Для одного VPS с nginx, php-fpm и WordPress развилка проще. Тег v4.0 имеет смысл, если вы сами сравниваете движки до смены мажора MariaDB и хотите, чтобы конфиг не потерялся вместе с цифрой. Версию базы на сайте этот релиз не обновляет. Каталог с данными сайта в установщик не передают. PostgreSQL внутри TAF пока beta, а машины, на которых снимали поведение, были AlmaLinux на десятках ядер.
