Du er helt sikkert på rette vej her.
Når InnoDB foretager en transaktion, der skal forpligtes, sker det som en to-faset forpligtelse. Transaktionen skrives først i disse logfiler. Så er de forpligtet derfra.
Dette hjælper en hel del i tilfælde af MySQL-nedbrud eller servernedbrud.
Når du genstarter mysql, afspilles alle uforpligtede poster i ib_logfile0 og ib_logfile1 som en del af crash recovery af InnoDB for at bringe InnoDB til en harmonisk tilstand (Dette er konsistente og holdbare dele af ACID-overholdelse )
Hvis du sletter ib_logfile0 og ib_logfile1 og starter mysql, går enhver uforpligtet transaktion, som disse filer indeholdt, tabt. Hvis logfilerne mangler under nedbrudsgendannelsescyklussen, bliver de regenereret baseret på innodb_log_file_size indstilling.
Se venligst MySQL-dokumentationen for en detaljeret forklaring af InnoDB .
@karatedog MVCC-delen af InnoDB sker i systemets tablespace, bedre kendt som ibdata1. De data, der ser ud til at være før starten af en transaktion, registreres for at give andre, der har adgang til de nødvendige rækker, mulighed for at se dataene, før der blev pålagt opdateringer. Dette giver mulighed for, hvad der kaldes en REPEATABLE-READ. Dette falder ind under I for ACID-overholdelse, jeg betyder isolation. Jeg skrev indlæg om dette i DBA StackExchange med hensyn til forskellige scenarier, hvor transaktionsisolering er god, dårlig eller grim.
- læs før skriv transaktion
- Vil disse to forespørgsler resultere i en dødvande, hvis de udføres i rækkefølge?
- Er raid 5 egnet til mysql-installation?
Hvad angår MyISAM, er nedbrudsgendannelse ikke automatisk. Det går ret nemt ned
. Det er derfor SQL-kommandoen REPAIR TABLE eksisterer. Det er også derfor, MySQL-værktøjet myisamchk har -r mulighed for at udføre REPAIR TABLE for MyISAM-tabeller, der ikke er online.
MariaDB og Aria har været forsøg på at lave en crash-sikker lagermotor som erstatning for MyISAM.