Du är definitivt på rätt väg här.
Närhelst InnoDB gör en transaktion som måste begås, görs den som en tvåfasig commit. Transaktionen skrivs först i dessa loggar. Sedan är de engagerade därifrån.
Detta hjälper en hel del i händelse av en MySQL-krasch eller serverkrasch.
När du startar om mysql, spelas alla oengagerade poster i ib_logfile0 och ib_logfile1 upp som en del av kraschåterställningen av InnoDB för att få InnoDB till ett harmoniskt tillstånd (Detta är konsekventa och hållbara delar av ACID-efterlevnad )
Om du tar bort ib_logfile0 och ib_logfile1 och startar mysql, förloras alla oengagerade transaktioner som dessa filer innehöll. Under kraschåterställningscykeln, om loggfilerna saknas, genereras de på nytt baserat på innodb_log_file_size inställning.
Se MySQL-dokumentationen för en detaljerad förklaring av InnoDB .
@karatedog MVCC-delen av InnoDB sker inom systemtabellutrymmet, mer känd som ibdata1. Oavsett data som verkar vara före starten av en transaktion registreras för att andra som kommer åt de nödvändiga raderna ska kunna se data innan några uppdateringar infördes. Detta möjliggör vad som kallas REPEATABAR-LÄS. Detta faller under I för ACID-efterlevnad, jag menar isolering. Jag skrev inlägg om detta i DBA StackExchange angående olika scenarier där transaktionsisolering är bra, dålig eller ful.
- läs innan transaktionen skrivs
- Kommer dessa två frågor att resultera i ett dödläge om de körs i följd?
- Är raid 5 lämplig för mysql-installation?
När det gäller MyISAM är kraschåterställning inte automatisk. Det kraschar ganska lätt
. Det är därför SQL-kommandot REPAIR TABLE existerar. Det är också därför MySQL-verktyget myisamchk har -r alternativet för att utföra REPAIR TABLE för MyISAM-tabeller som inte är online.
MariaDB och Aria har varit försök att göra en kraschsäker lagringsmotor som ersättning för MyISAM.