Комментарии 5
Я прошу прощения, но про rollback так ни чего и не сказали. Вы рассказали про recovery - штуку, работающую во время подъёма базы после катастрофического отключения (кабель выдернули / kernel-panic / segfault в коде базы / kill -9 ). Да и то в двух словах.
Например, в PostgreSQL нет UNDO в WAL логе, и он спокойно живёт, восстанавливается, делает ROLLBACK незавершённым транзакциям при восстановлении и делает пользовательские ROLLBACK.
И вот как-раз про пользовательские ROLLBACK вы ни слова и не сказали. И они случаются не только когда пришла команда ROLLBACK, но и, например, когда клиент "умер" или соединение от клиента порвалось или произошёл таймаут на соединении (для сервера БД все эти три случая эквивалентны в плане работы ROLLBACK).
И при таком пользовательском ROLLBACK ни как не используется UNDO в WAL логе (обычно. Я не знаю, кто использует). В некоторых базах транзакция просто помечается как Aborted (в PostgreSQL, например). В других, используется совершенно отдельный UNDO лог, предназначенный только для пользовательских ROLLBACK (емнип, InnoDB, а может и в Oracle). В третьих вообще используются оптимистичные транзакции, и транзакция просто не достигает стораджа до команды COMMIT.
(btw, PostgreSQL точно так же откатывает транзакции при восстановлении: все незавершившиеся на конец WAL лога получают пометку Aborted).
Хэй, спасибо за развёрнутый комментарий. Только ради этого и стоит писать статьи на хабр.
Как происходит откат транзакции в pg? Помечаем её как откатанную и игнорируем все изменения, которые она сделала в базе. Подробнее в статье.
Я бы еще добавил, что в InnoDB используется отдельный Undo log, так как до коммита транзакции остальные запросы должны видеть старые версии записей для обеспечения MVCC.
Увы, получился 100501-ый ликбез на тему, что такое транзакция и ACID.
Как работает rollback в базах данных