Распределенные транзакции — зачем сохраняются транзакционные логи на диск?

Question

[Snowindy]

Все транзакционные менеджеры (Atomikos, Bitronix, IBM WebSphere TM и т.д.) сохраняют некие "транзакционные логи" в папки наподобие "tranlogs".

Когда случается что-то плохое и сервер падает эти транлоги порой непросто привести в рабочее состояние.
К примеру, необходимо как-то провести ручную процедуру recovery, или просто удалить транлоги с угрозой получения неконсистентного состояния (так пишут в доках) ресурсов, участвовавших в транзакциях.

Я тупой программист и хочу думать о менеджере двухфазных транзакций как об обычном менеджере транзакций:
1. Если что-то пошло не так на любой стороне (сеть, программная ошибка, таймаут) - откат всей транзакции со всеми ресурсами.
2. Падает транзакционные менеджер - откат всех транзакций, которые стартовал этот TM (видимо, по таймауту на уровне БД).
3. Файловое хранение транлогов не нужно, если я не собираюсь как-то проводить автоматическую recovery транзакций (что бы этот термин не значил).

Вопрос.
Почему я не могу так думать? Растолкуйте пожалуйста русским языком.
Могу ли я чистить транлоги при рестарте сервера? Что я теряю?

Answer 1

[Юрий Ярош]

Есть такая весёлая модель как MVCC.
Все весельё начинается когда транзакции начинают писаться на нескольких узлах одновременно - точно сказать что устарело и какие конфликты возникли бывает сложно. По этому безопасно что-то удалить, без синхронизации состояний с последующей проверкой консистентности на всех узлах невозможно... вот всякие WebLogic'ы не знают что у вас один узел, и даже с одним узлом у них проблемы.

Если у нас просто сбой по питанию то тут влияет дисковый кэш - есть RAIDы с батарейками которые сами дописывают при сбоях питания последние транзакции, правда файлики нужно писать со специальным флагом без кэширования в ОС и с ограничением по размеру... в общем это единственный случай при котором можно спокойно востановить актуальное состояние после сбоя питания. Если писать на "простовинт" без буфера и батареек - можно потерять весь лог.

"Просто удалить" нельзя из-за специфики проверок консистентности лога транзакций - весь лог должен быть применён от начала до конца. Часто используют специфические коды Рида-Соломона для дополнительной отказоустойчивости при порче информации на диске, они вносят свои ограничения.

Рассмотрите модель работы Riak, там для обозначения транзакций используются метки Лампорта... вот просто "взять и удалить" без последствий в сложной транзакционной системе не получится.

Comments

[Snowindy]

Спасибо за развернутый ответ!

Тогда вопрос, что за последствия мне грозят после "взять и удалить"?

[Masterme]

@Snowindy минимум - потерю последних записей, максимум - неработоспособность/неконсистентность базы.

[Юрий Ярош]

Есть цепочка транзаций - для того что бы проверить консистентность нужно прогнать всю цепочку. Каждый следующий элемент в цепочке зависит от предыдущего. Вот в случае с безопасным удалением, нужно вручную инициализировать новую историю - новый "первый эллемент".