Като начало...
http://yoshinorimatsunobu.blogspot.com/2009 /08/great-performance-effect-of-fixing.html
Преди InnoDB Plugin 1.0.4 беше така:
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
На и след InnoDB Plugin 1.0.4 (и MySQL 5.5), сега е:
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
Както можете да видите, в новата версия нищо (освен в случай sync_binlog> 0) е fsync в критичната секция. По този начин груповото ангажиране вече работи и осигурява много по-добра едновременна пропускателна способност.
Например, с предишната "счупена" версия, ако сте имали 100 нишки едновременни комитации, всички fsync бяха сериализирани и ще получите 100 fsync за подготовка и още 100 fsync за комит. Следователно груповият ангажимент беше напълно нарушен.
Сега с по-новата реализация, fsync се групират в зависимост от паралелността на транзакциите, като същевременно се гарантира подреждането на операциите между innodb log и binlog. Това също означава, че ако има само една нишка, няма повишаване на производителността.
Що се отнася до въпроса ви, че когато възникне срив, след като транзакция е записана в binlog, но преди да бъде записана в регистъра на транзакциите - аз съм на същата страница като вас.
Ако сървърът се срине преди последната стъпка, има малък шанс да имате несъответствие между innodb log и binlog (или единият може да е по-напред от другия), но е гарантирано, чеимете цялата информация какво да прегледи в дневника innodb, тъй като е записан в подготвителната фаза.
Въпреки това, какво да правим с необвързаните все още е недетерминистично. Например, освен ако sync_binlog = 1 има вероятност подчинен да е получил данните, но все още не е синхронизирал напълно binlog на главния. Не можете просто да повторите неуспешната транзакция, тъй като тя може вече да се е изпълнявала на един от подчинените.
Което също така означава, че binlog може да бъде по-кратък от дневника innodb, връщайки „Двоичният дневник [име_на_файл] е по-къс от очаквания размер“. както е описано в официалния документ, и трябва да възстановите роба от нулата. Не е много приятелски настроен към хората.
http://dev.mysql.com/doc/refman /5.1/bg/binary-log.html
Тъй като последователността по отношение на подреждането на операциите е гарантирана независимо от innodb_support_xa настройка (която противоречи на казаното в официалния документ на innodb_support_xa , може би защото беше писано за стандартния innodb 5.0.3 далеч преди корекцията на паралелността), а съгласуваността между innodb log на главния и релейния дневник на подчинения не е строго гарантирана дори с innodb_support_xa , не виждам смисъл от използването на innodb_support_xa . Страшно е обаче да не следвате официалната препоръка, но тя изглежда остаряла и погрешна в много точки.
Чудя се дали има някаква връзка между innodb_flush_log_at_trx_commit настройка и innodb_support_xa поведение, когато първото е настроено на 2 или 0.
Един практичен начин на мислене е, че прехвърлянето към подчинения е безопасно – в края на краищата неуспешната транзакция е нещо, което сте искали да свършите – но никога не се връщайте към главен, тъй като може да има известно несъответствие в данните. Трябва да копирате напълно данните от подчинения, преди да направите главния нов подчинен. С други думи, когато главният се срине, от тогава нататък се доверявайте на подчинения – по този начин няма нужда да се забърквате с innodb log за възстановяване при срив.
Също така имайте предвид, че MySQL 5.5 поддържа полусинхронна репликация, по същата линия като „доверете се на роба“ – смятам, че може да се интересувате.
http://dev.mysql.com/doc/refman /5.5/bg/replication-semisync.html
