Tady jste rozhodně na správné cestě.
Kdykoli InnoDB provede transakci, která musí být potvrzena, je provedena jako dvoufázové potvrzení. Transakce se nejprve zapíše do těchto protokolů. Poté jsou odtud zavázáni.
To velmi pomáhá v případě selhání MySQL nebo selhání serveru.
Když restartujete mysql, všechny nepotvrzené záznamy v ib_logfile0 a ib_logfile1 se přehrají jako součást obnovy InnoDB po havárii, aby se InnoDB dostal do harmonického stavu (Toto je konzistentní a trvanlivé části Soulad s kyselinou )
Pokud vymažete ib_logfile0 a ib_logfile1 a spustíte mysql, všechny nepotvrzené transakce, které tyto soubory obsahovaly, budou ztraceny. Pokud během cyklu obnovy po havárii chybí soubory protokolu, jsou znovu vygenerovány na základě innodb_log_file_size nastavení.
Podrobnou dokumentaci k MySQL naleznete v dokumentaci vysvětlení InnoDB .
@karatedog část MVCC InnoDB se odehrává v systémovém tabulkovém prostoru, lépe známém jako ibdata1. Jakákoli data, která se zdají být před zahájením transakce, se zaznamenají, aby ostatní, kteří mají přístup k potřebným řádkům, měli k dispozici pohled na data před zavedením jakýchkoli aktualizací. To umožňuje to, čemu se říká OPAKOVATELNÉ ČTENÍ. To spadá pod I v souladu s ACID, myslím tím izolaci. Napsal jsem o tom příspěvky na DBA StackExchange s ohledem na různé scénáře, kdy je izolace transakcí dobrá, špatná nebo ošklivá.
- přečíst před zápisem transakce
- Povedou tyto dva dotazy k uváznutí, pokud budou provedeny postupně?
- Je raid 5 vhodný pro instalaci mysql?
Pokud jde o MyISAM, obnova po havárii není automatická. Docela snadno havaruje
. Proto SQL příkaz REPAIR TABLE existuje. To je také důvod, proč MySQL utilita myisamchk má -r možnost provést REPAIR TABLE pro tabulky MyISAM, které nejsou online.
MariaDB a Aria byly pokusy vytvořit úložný modul bezpečný při havárii jako náhradu za MyISAM.