Monastery: как автоматизировать тесты изоляции транзакций

Ключевые факты

• Монастырь (Monastery) это open-source инструмент для запуска конкурентных сценариев транзакций и проверки аномалий (Dirty Writes, Lost Updates и т.д.) на разных уровнях изоляции
• Hermitage не обновлялся для MySQL и PostgreSQL ~10 лет; MariaDB с 2024 года полностью изменил реализацию изоляции (с Two-Phase Locking на Snapshot Isolation, как в PostgreSQL)
• Результаты: MySQL остался в тех же нарушениях (Lost Updates на Repeatable Read), MariaDB теперь обрабатывает аномалии корректнее, чем исходный MySQL
• Уровни изоляции в стандарте SQL неоднозначны и допускают странное поведение даже в версии 2023; ни одна основная БД не разрешает Dirty Writes, но разные подходы к остальным аномалиям

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

Почему это важно

В SQL-стандарте уровни изоляции определены через аномалии транзакций (Dirty Reads, Lost Updates, Phantom Reads и т.д.), но сам стандарт допускает неоднозначности. Базы данных по-разному интерпретируют одни и те же термины. Hermitage помогал инженерам понять, какие аномалии реально возникают на практике в каждой БД. Decade спустя реальное поведение MySQL и особенно MariaDB сильно изменилось, но карта Hermitage этого не отражала. Monastery автоматизирует эти проверки и делает результаты воспроизводимыми и понятными.

Ред. Если вы думаете, что знаете, как ваша БД изолирует транзакции, вероятно, вы ошибаетесь уже лет пять.

Кому это важно

Разработчикам, которые выбирают между MySQL и MariaDB или как-то рассчитывают на конкретное поведение изоляции в многопроцессных сценариях. Также архитекторам, которые проектируют системы с высокой конкурентностью и нужны гарантии по синхронизации данных. Инженерам БД, ответственным за тюнинг и миграции (например, с MySQL на MariaDB; вы получите другой набор аномалий). И, косвенно, всем, кто полагается на ORM или даже на текстовое описание "мы используем Repeatable Read" и верит, что это что-то гарантирует.

Ред. Если в коде есть комментарий "полагаемся на Repeatable Read", найдите того, кто его написал, и вежливо попросите обновить резюме.

Как это применить

Если вы обслуживаете базу MySQL или рассматриваете миграцию на MariaDB, запустите Monastery на свои реальные или критичные сценарии транзакций. Специалист по БД может взять конкурентные операции из логов, пересоздать их в Monastery и проверить, какие аномалии возникают при текущих версиях (а не полагаться на устаревшие справочники). Для новых проектов: если нужна строгая изоляция, явно проверьте поведение на той БД и версии, которую вы выбрали. Не доверяйте уровню "Serializable" слепо; повторьте тест через Monastery.

Ред. Посмотреть один раз в Monastery лучше, чем слушать совет DBA на конференции 2015 года.

Можно ли доверять

Работа базируется на академических исследованиях (A Critique of ANSI SQL Isolation Levels, статьи Jepsen про многомастер-системы) и повторяет подход классического Hermitage. Автор (eatonphil) имеет репутацию в сообществе, публикует открытый код и ссылается на источники. Однако сам инструмент не гарантирует, что БД "безопасна". Он только категоризирует аномалии на простых сценариях. Jepsen-тесты намного более враждебны и полнее. Результаты Monastery отражают реальность для версий MySQL 9.7 и MariaDB на дату теста, но при следующем릴리�е все может измениться.

Ред. Monastery подтвердит, что ваша БД не ломается на простых тестах. Но есть ещё Jepsen, хаос-инженеры и production.

Риски и подводные камни

Первое: Monastery проверяет изоляцию, но не конкурентность на высоконагруженных объемах. Второе: результаты зависят от версии БД, версии ОС, конфигурации (например, fsync). Третье: MariaDB за счет перехода на Snapshot Isolation может иметь другие характеристики скорости на конкретных нагрузках. Четвёртое: если вы мигрируете с MySQL на MariaDB и полагаетесь на конкретные аномалии для логики приложения (например, рассчитываете, что Lost Update именно произойдет), новое поведение сломает ваши предположения. Пятое: фокус на "какие аномалии протекают" игнорирует deadlock'и, lock timeout'ы и абортированные транзакции.

Ред. Риск № 4: самый забавный, когда БД исправляется, приложение может сломаться ещё быстрее, чем раньше.

«Hermitage hasn't really been updated for MySQL or PostgreSQL in the last decade, and MariaDB has diverged significantly from MySQL since then.»

— eatonphil, The Consensus