ARIES (8/8)

Заключение.

ARIES — эффективный и достаточно простой алгоритм записи и восстановления. Он работает за счёт полного повтора истории. Как было показано на примере, он продолжает работать даже при множественных рестартах подряд. ARIES может работать в steal + no-force режиме buffer manager. Другими словами, он не требует чтобы коммиты записывали грязные страницы на диск, а также позволяет записывать страницы даже во время транзакций.

ARIES проводит восстановление в три шага.

Сначала происходит анализ записей в WAL. При анализе восстанавливается состояние таблицы грязных страниц DPT, а также таблицы незавершённных транзакций TT.

В следующей фазе — Redo, состояние буферов страниц в памяти приводится в полное соответствие с WAL. После исполнения Redo, внутреннее состояние страниц идентично тому, каким оно было до начала процесса восстановления.

Наконец, в фазе Undo откатываются транзакции, которые не успели сделать коммит до начала рестарта. Во время Undo каждой update записи WAL, относящейся к незавершённой транзакции, в обратном хронологическом порядке записывается CLR запись. Точно такая же запись обычно записывается в WAL при роллбеках в нормальном режиме работы. Такой подход позволяет с одной стороны, упростить алгоритм восстановления при повторных рестартах, а с другой, ограничить максимальное количество новых записей в WAL, которые будут созданы во время восстановления. При создании CLR использует протокол write-ahead, как и при обычной записи в нормальном режиме.

Я уже вышел за все мыслимые и немыслимые рамки размера поста, поэтому, пожалуй, закончу. Есть ещё пара вещей, о которых не рассказал.

Первое — это чекпоинты. База данных периодически может снимать текущее состояние таблицы грязных страниц DPT и незавершённых транзакций TT и записывать в какое-нибудь надежное место. Такой подход позволяет во время фазы анализа ARIES не просматривать вообще весь журнал, а сначала восстановить чекпоинт, и накатывать обновление уже с него.

Второе — каждая фаза ARIES может не только без проблем пережить рестарт, но также может запускаться параллельно и безопасно в несколько потоков. Это достигается за счёт локов на уровне страницы. Более того, во время каждой фазы БД может делать чекпоинты. Так к примеру чекпоинт после фазы анализа позволит не делать анализ повторно, если второй рестарт произойдёт сразу.

Третье — я сказал, что ARIES позволяет делать гранулярные локи, т.е. лочить и на уровне страницы, и на уровне отдельной строчки, но не сказал как. С локами в базах вообще всё сложно, когда-нибудь про лок-менеджеры напишу отдельный пост.

Четвёртое — есть распределёный ARIES! D-ARIES: A Distributed Version of the ARIES Recovery Algorithm (ссылка). А ещё ARIES (вернее WAL) оптимизирован под жёсткие диски. SSD последовательная запись нужна в меньшей степени, т.е. на них можно сделать более эффективный алгоритм. Пример такого алгоритма есть в работе From ARIES to MARS: transaction support for next-generation, solid-state drives (ссылка). Это всё добро тоже в беклоге.

Источники:

[1] ARIES whitepaper https://dl.acm.org/doi/10.1145/128765.128770
[2] Прекрасное youtube видео про ARIES от Dr. Jens Dittrich https://www.youtube.com/watch?v=S9nctHdkggk . Там целый университетский курс видео-лекций про базы данных.
[3] Ramakrishnan, Gehrke — Database Management System Third Edition (ссылка)
[4] Peter Bailis Joseph M. Hellerstein Michael Stonebraker — Readings in Database Systems Fifth Edition. Она же Red Book. (ссылка)

Ссылка на первый пост из 8.