Til at begynde med...
http://yoshinorimatsunobu.blogspot.com/2009 /08/great-performance-effect-of-fixing.html
Før InnoDB Plugin 1.0.4 var det sådan:
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
På og efter InnoDB Plugin 1.0.4 (og MySQL 5.5) er det nu:
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
Som du kan se, er der intet i den nye version (undtagen i tilfælde af sync_binlog> 0) er fsync'd i den kritiske sektion. På den måde fungerer group commit nu og sikrer en langt bedre samtidig gennemstrømning.
For eksempel, med den tidligere "brudte" version, hvis du havde 100 tråde samtidige commits, blev alle fsyncs serialiseret, og du ville få 100 fsyncs til forberedelse og yderligere 100 fsyncs til commit. Derfor blev gruppeforpligtelsen fuldstændig brudt.
Nu med den nyere implementering er fsyncs grupperet afhængigt af samtidigheden af transaktioner, samtidig med at det sikres operationsbestilling mellem innodb-log og binlog. Det betyder også, at hvis der kun er én tråd, er der ingen præstationsforøgelse.
Med hensyn til dit spørgsmål om, at når der opstår et nedbrud, efter at en transaktion er skrevet til binlogen, men før den er skrevet til transaktionsloggen - er jeg på samme side som dig.
Hvis serveren gik ned før det sidste trin, er der en lille chance for, at du har en uoverensstemmelse mellem innodb-log og binlog (enten kan den ene være foran den anden), men det er garanteret, at du har alle oplysninger om, hvad du skal undersøge i innodb-loggen, som den er registreret i forberedelsesfasen.
Men hvad man skal gøre med de uengagerede er stadig ikke-deterministisk. For eksempel, medmindre sync_binlog = 1 der er en chance for, at en slave har modtaget dataene, men endnu ikke har synkroniseret binloggen på masteren fuldt ud. Du kan ikke bare gentage den mislykkede transaktion, da den måske allerede er kørt på en af slaverne.
Hvilket også betyder, at binlog kan være kortere end innodb-loggen, hvilket returnerer "Den binære log [filnavn] er kortere end dens forventede størrelse." som beskrevet i det officielle dokument, og du skal genopbygge slaven fra bunden. Ikke særlig menneskevenlig.
http://dev.mysql.com/doc/refman /5.1/da/binary-log.html
Da konsistens med hensyn til operationsrækkefølge er garanteret uafhængig af innodb_support_xa indstilling (som modsiger det, der er sagt i det officielle dokument på innodb_support_xa , måske fordi det blev skrevet om aktien innodb 5.0.3 langt før concurrency fixet), og konsistens mellem innodb log på masteren og relæ log på slaven er ikke strengt garanteret selv med innodb_support_xa , jeg kan ikke se nogen mening i at bruge innodb_support_xa . Det er dog skræmmende ikke at følge den officielle anbefaling, men det virker forældet og forkert på mange punkter.
Jeg spekulerer på, om der er nogen sammenhæng mellem innodb_flush_log_at_trx_commit indstillingen og innodb_support_xa adfærd, når førstnævnte er sat til 2 eller 0.
En praktisk måde at tænke på er, at failover til slaven er sikkert - trods alt var den mislykkede transaktion noget, du ønskede at få udført - men aldrig fail-back til master, da der kan være en vis uoverensstemmelse i dataene. Du skal helt kopiere dataene fra slaven, før du gør masteren til en ny slave. Med andre ord, når masteren styrtede ned, så stol på slaven fra da af - på den måde behøver du ikke rode med innodb-log for at genoprette nedbrud.
Bemærk også, at MySQL 5.5 understøtter semi-synkron replikering, på samme måde som "trust the slave" - tænkte, at du kunne være interesseret.
http://dev.mysql.com/doc/refman /5.5/da/replication-semisync.html