Zdecydowanie jesteś na dobrej drodze.
Za każdym razem, gdy InnoDB wykonuje transakcję, która musi zostać zatwierdzona, odbywa się to jako zatwierdzenie dwufazowe. Transakcja jest zapisywana w tych dziennikach jako pierwsza. Następnie zostają popełnione z tego miejsca.
To bardzo pomaga w przypadku awarii MySQL lub awarii serwera.
Po ponownym uruchomieniu mysql wszystkie niezatwierdzone wpisy w ib_logfile0 i ib_logfile1 są odtwarzane w ramach odzyskiwania po awarii InnoDB, aby przywrócić InnoDB do harmonijnego stanu (jest to spójne i trwałe części Zgodność z ACID )
Jeśli usuniesz ib_logfile0 i ib_logfile1 i uruchomisz mysql, wszelkie niezatwierdzone transakcje zawarte w tych plikach zostaną utracone. Podczas cyklu odzyskiwania po awarii, jeśli brakuje plików dziennika, są one ponownie generowane na podstawie innodb_log_file_size ustawienie.
Szczegółowe informacje można znaleźć w Dokumentacji MySQL wyjaśnienie InnoDB .
@karatedog część MVCC InnoDB znajduje się w systemowej przestrzeni tabel, lepiej znanej jako ibdata1. Wszelkie dane, które pojawiają się przed rozpoczęciem transakcji, są rejestrowane, aby umożliwić innym osobom, które uzyskują dostęp do potrzebnych wierszy, wgląd w dane przed nałożeniem jakichkolwiek aktualizacji. Pozwala to na tzw. REPEATABLE-READ. Podlega to I zgodności z ACID, mam na myśli izolację. Pisałem o tym posty w DBA StackExchange w odniesieniu do różnych scenariuszy, w których izolacja transakcji jest dobra, zła lub brzydka.
- przeczytaj przed zapisem transakcji
- Czy te dwa zapytania spowodują zakleszczenie, jeśli zostaną wykonane po kolei?
- Czy raid 5 nadaje się do instalacji mysql?
Jeśli chodzi o MyISAM, odzyskiwanie po awarii nie jest automatyczne. Awaria dość łatwo
. Dlatego polecenie SQL REPAIR TABLE istnieje. Dlatego też narzędzie MySQL myisamchk ma -r opcja wykonania REPAIR TABLE dla tabel MyISAM, które nie są online.
MariaDB i Aria podjęto próby stworzenia bezpiecznego silnika pamięci masowej jako zamiennika MyISAM.
