Переход к не анонимным изменениям схемы СУРБД Firebird. Часть 2: журнал фактов

В сфере искусственного интеллекта произошло заметное событие. deliciousNesquik 5 минут назад Переход к не анонимным изменениям схемы СУРБД Firebird. Часть 2: журнал фактов Простой 8 мин 52 SQL * Firebird/Interbase * Кейс Что осталось за кадром первой частиВ первой части был инструмент, который снимает схему Firebird и раскладывает её деревом файлов: один объект — один файл. Он отлично отвечает на вопрос «как эта процедура выглядит сейчас» и совершенно беспомощен в вопросе «кто её поменял в среду вечером».

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

Технические детали

Сколько правды хранитьИдеальный журнал изменений хранит всё: кто, когда, какой объект и полный текст того, что выполнили. Тогда историю можно восстановить, не выходя из базы. От полного текста мы отказались.

Причина скучная и убедительная: одну и ту же процедуру за сутки правят по десять раз, тело у неё бывает на сотню килобайт, и журнал начинает жить своей жизнью, обгоняя по размеру данные, ради которых база вообще существует. Команда проголосовала за то, чтобы текст не хранить. Демократия в инженерных спорах вещь спорная, но объём BLOB-полей она оценивает трезво.

Плата за это честная, и её надо назвать вслух: внутридневные версии по журналу не восстанавливаются. Если процедуру за день правили пять раз, в git приедет только последнее состояние, а журнал скажет, что правок было пять и кто их автор. Промежуточные тексты не сохранятся нигде.

Отраслевые последствия

Впрочем, «нигде» — это некоторое преувеличение. Рядом с базой работает трассировка: fbtrace пишет в лог сами операторы, включая DDL, вместе со временем, пользователем и номером транзакции. То есть текст, которого нет в журнале, чаще всего достать можно — и, что важнее, связать с записью журнала по TX_ID: номер транзакции в обоих местах один и тот же.

Для разбора трейс-логов я в своё время написал себе отдельное приложение (если будет время и про него напишу, было бы интересно получить feedback от тех кому оно хотя бы как-то бы помогло, интересно развивать данный проект даже внутри своей команды), в котором это удобно отфильтровать — по транзакции, времени, пользователю или объекту — и посмотреть, что именно выполнялось. Полагаться на трассировку как на архив всё же нельзя, и в схеме журнала она намеренно не учитывается: это отдельный механизм со своей ротацией и сроком хранения, его можно выключить, и он не обязан пережить перезапуск сервиса. Разделение обязанностей получается такое: журнал отвечает на «кто и когда» всегда, трейс — на «а что именно там было», пока лог не уехал по ротации.

Зато разделение получилось чистое: журнал отвечает на «кто, когда, что за объект», дамп — на «как это теперь выглядит». Ни один из них поодиночке историю не даёт, вместе — дают. Таблица журналаУ нас все типы заведены доменами, но чтобы скрипт можно было выполнить у себя, привожу его на базовых типах.

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