Dziennik redo
Odpowiednik write-ahead loga w MySQL/InnoDB: przechowuje zatwierdzone zmiany, by można je było „powtórzyć” po awarii. Gwarantuje trwałość (D w ACID), zapisując zmiany do dziennika, zanim trafią do plików danych.
Mechanizm: przy transakcji zmiany trafiają do dziennika redo (sekwencyjnie, szybko) i są oznaczane jako zatwierdzone; brudne strony w buffer poolu zapisuje się na dysk leniwie, później (przy checkpoincie). Jeśli serwer padnie, dziennik jest odtwarzany od ostatniego checkpointu → wszystkie zatwierdzone zmiany wracają. Dziennik jest cykliczny (stałe pliki, ib_logfile), a jego rozmiar wpływa na częstotliwość checkpointów i wydajność. Różni się od dziennika undo (który trzyma stare wartości na potrzeby wycofania i MVCC). Razem redo i undo tworzą maszynerię ACID w InnoDB. Koncepcyjnie to samo co WAL w PostgreSQL, tylko w terminologii InnoDB.