Na początek...
http://yoshinorimatsunobu.blogspot.com/2009 /08/great-performance-effect-of-fixing.html
Przed InnoDB Plugin 1.0.4 wyglądało to tak:
obtain mutex
write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
write binlog (fsync as appropriate if sync_binlog > 0)
write innodb log and fsync, for commit-phase
release mutex
W i po InnoDB Plugin 1.0.4 (i MySQL 5.5), teraz jest:
write innodb log and fsync, for prepare-phase (skip if innodb_support_xa=0)
obtain mutex
write binlog (fsync as appropriate if sync_binlog > 0)
write innodb log, for commit-phase
release mutex
fsync innodb log, for commit-phase
Jak widać, w nowej wersji nic (z wyjątkiem przypadku sync_binlog> 0) jest fsynced w sekcji krytycznej. W ten sposób zatwierdzanie grupowe działa teraz i zapewnia znacznie lepszą jednoczesną przepustowość.
Na przykład w poprzedniej "uszkodzonej" wersji, jeśli masz 100 jednoczesnych zatwierdzeń wątków, wszystkie fsyncs zostały zserializowane i otrzymasz 100 fsync za przygotowanie i kolejne 100 fsync za zatwierdzenie. Dlatego zatwierdzenie grupowe zostało całkowicie złamane.
Teraz, dzięki nowszej implementacji, fsyncs są pogrupowane w zależności od współbieżności transakcji, zapewniając jednocześnie porządek operacji między logiem innodb i binlog. Oznacza to również, że jeśli jest tylko jeden wątek, nie ma wzrostu wydajności.
Jeśli chodzi o twoje pytanie, jeśli awaria nastąpi po zapisaniu transakcji w dzienniku, ale przed zapisaniem w dzienniku transakcji - jestem na tej samej stronie co ty.
Jeśli serwer uległ awarii przed ostatnim krokiem, istnieje niewielka szansa, że masz rozbieżność między logiem innodb a binlogiem (każdy z nich może być przed drugim), ale gwarantujemy, że masz wszystkie informacje o tym, co zbadać w dzienniku innodb, tak jak jest to zapisane w fazie przygotowawczej.
Jednak to, co zrobić z niezaangażowanymi, jest nadal niedeterministyczne. Na przykład, chyba że sync_binlog = 1 istnieje szansa, że slave otrzymał dane, ale jeszcze nie w pełni zsynchronizował binlog na masterze. Nie możesz po prostu powtórzyć nieudanej transakcji, ponieważ mogła ona już działać na jednym z urządzeń podrzędnych.
Co oznacza również, że binlog może być krótszy niż dziennik innodb, zwracając „Dziennik binarny [nazwa_pliku] jest krótszy niż oczekiwany rozmiar”. jak opisano w oficjalnym dokumencie, i musisz odbudować niewolnika od podstaw. Niezbyt przyjazny człowiekowi.
http://dev.mysql.com/doc/refman /5.1/pl/binary-log.html
Ponieważ spójność w zakresie kolejności operacji jest gwarantowana niezależnie od innodb_support_xa ustawienie (co jest sprzeczne z tym, co zostało powiedziane w oficjalnym dokumencie na innodb_support_xa , być może dlatego, że został napisany o podstawowym innodb 5.0.3 na długo przed poprawką współbieżności), a spójność między dziennikiem innodb w głównym i przekaźnikowym dzienniku na urządzeniu podrzędnym nie jest ściśle gwarantowana nawet w przypadku innodb_support_xa , nie widzę sensu używania innodb_support_xa . Nieprzestrzeganie oficjalnych zaleceń jest przerażające, jednak wydaje się to przestarzałe i błędne w wielu punktach.
Zastanawiam się, czy istnieje jakakolwiek korelacja między innodb_flush_log_at_trx_commit ustawienie i innodb_support_xa zachowanie, gdy pierwsza jest ustawiona na 2 lub 0.
Jednym z praktycznych sposobów myślenia jest to, że przełączenie awaryjne na urządzenie podrzędne jest bezpieczne – w końcu nieudana transakcja była czymś, co chciałeś zrobić – ale nigdy nie wracaj do pracy po awarii, ponieważ mogą wystąpić pewne rozbieżności w danych. Musisz w pełni skopiować dane z urządzenia podrzędnego, zanim uczynisz z urządzenia głównego nowego niewolnika. Innymi słowy, gdy master ulegnie awarii, od tego momentu ufaj slave - w ten sposób nie będziesz musiał grzebać w logu innodb w celu odzyskania po awarii.
Zwróć też uwagę, że MySQL 5.5 obsługuje replikację półsynchroniczną, podobnie jak „zaufaj niewolnikowi” — pomyślałem, że możesz być zainteresowany.
http://dev.mysql.com/doc/refman /5.5/pl/replikacja-semisync.html
