Для начала ...
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'd,Таким образом, групповая фиксация теперь работает и обеспечивает гораздо лучшую параллельную пропускную способность.
Например, в предыдущей «сломанной» версии, если у вас было 100 потоковых одновременных коммитов, все fsyncs были сериализованы, и вы получили бы 100 fsyncs дляподготовить и еще 100 fsyncs для коммита.Поэтому групповая фиксация была полностью нарушена.
Теперь с более новой реализацией fsyncs сгруппированы в зависимости от параллелизма транзакций, обеспечивая при этом порядок операций между журналом innodb и binlog.Это также означает, что если есть только один поток, то прирост производительности отсутствует.
Что касается вашего вопроса, то, когда происходит сбой после записи транзакции в binlog, но до ее записи в журнале транзакций - I 'm на той же странице, что и вы.
Если сервер завершил работу до последнего шага, есть небольшая вероятность того, что у вас есть расхождение между журналом innodb и binlog (один из них может быть впереди другого), но этогарантируется, что у вас есть вся информация о том, что проверять в журнале innodb, как это записано на этапе подготовки.
Однако, что делать с незафиксированным, все еще не определено,Например, если только sync_binlog = 1 есть вероятность, что ведомый получил данные, но еще не полностью выполнил бинлог на главном сервере.Вы не можете просто повторить неудачную транзакцию, поскольку она уже может быть запущена на одном из ведомых устройств.
Это также означает, что binlog может быть короче, чем журнал innodb, возвращая «Двоичный журнал [file_name] isкороче его ожидаемого размера. "как описано в официальном документе, и вы должны восстановить раб с нуля.Не очень дружелюбный к людям.
http://dev.mysql.com/doc/refman/5.1/en/binary-log.html
Поскольку согласованность с точки зрения порядка работы гарантируется независимо от настройки innodb_support_xa (что противоречит тому, что сказано в официальном документе по innodb_support_xa,возможно, потому что это было написано о стандартной innodb 5.0.3 задолго до исправления параллелизма), и согласованность между журналом innodb на главном сервере и журналом ретрансляции на ведомом устройстве не гарантируется строго даже с innodb_support_xa, я не вижу никакого смыслав использовании innodb_support_xa.Страшно не следовать официальной рекомендации, хотя во многих отношениях она кажется устаревшей и неправильной.
Мне интересно, есть ли какая-либо корреляция между настройкой innodb_flush_log_at_trx_commit и поведением innodb_support_xa, когда перваяустановлен на 2 или 0.
Один практический способ мышления заключается в том, что отработка отказа подчиненному безопасна - в конце концов, неудачная транзакция была тем, что вы хотели выполнить, но никогда не возвращались к мастеру., поскольку могут быть некоторые расхождения в данных.Вам необходимо полностью скопировать данные с ведомого устройства, прежде чем вы сделаете мастер новым подчиненным устройством.Другими словами, когда мастер вышел из строя, доверяйте ведомому с этого момента - таким образом, вам не нужно связываться с журналом innodb для восстановления после сбоя.
Также обратите внимание, что MySQL 5.5 поддерживает полусинхронную репликацию,по тому же принципу, что и «доверяй рабу» - подумал, что тебя это может заинтересовать.
http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html