Pour commencer...
http://yoshinorimatsunobu.blogspot.com/2009 /08/grand-effet-de-performance-de-la-fixation.html
Avant le plugin InnoDB 1.0.4, c'était comme :
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
Sur et après InnoDB Plugin 1.0.4 (et MySQL 5.5), c'est maintenant :
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
Comme vous pouvez le voir, dans la nouvelle version, rien (sauf au cas où sync_binlog> 0) est fsync'd dans la section critique. De cette façon, la validation de groupe fonctionne désormais et garantit un bien meilleur débit simultané.
Par exemple, avec la version précédente "cassée", si vous aviez 100 threads commits simultanés, tous les fsyncs étaient sérialisés et vous obtiendriez 100 fsyncs pour prepare et 100 autres fsyncs pour commit. Par conséquent, le commit de groupe a été complètement rompu.
Désormais, avec la nouvelle implémentation, les fsyncs sont regroupés en fonction de la simultanéité des transactions, tout en garantissant l'ordre des opérations entre innodb log et binlog. Cela signifie également que s'il n'y a qu'un seul thread, il n'y a aucun gain de performances.
Quant à votre question, lorsqu'un plantage se produit après qu'une transaction a été écrite dans le binlog, mais avant qu'elle ne soit écrite dans le journal des transactions, je suis sur la même page que vous.
Si le serveur plante avant l'étape finale, il y a une petite chance que vous ayez un écart entre innodb log et binlog (l'un peut être en avance sur l'autre), mais il est garanti que vous avez toutes les informations sur ce qu'il faut examiner dans le journal innodb, tel qu'il est enregistré dans la phase de préparation.
Cependant, ce qu'il faut faire avec le non engagé est toujours non déterministe. Par exemple, sauf si sync_binlog = 1 il y a une chance qu'un esclave reçoive les données mais n'ait pas encore entièrement fsynchronisé le binlog sur le maître. Vous ne pouvez pas simplement refaire la transaction qui a échoué car elle a peut-être déjà été exécutée sur l'un des esclaves.
Ce qui signifie également que le journal bin peut être plus court que le journal innodb, renvoyant "Le journal binaire [nom_fichier] est plus court que sa taille attendue." comme décrit dans la doc officielle, et vous devez reconstruire l'esclave à partir de zéro. Pas très humain.
http://dev.mysql.com/doc/refman /5.1/fr/binary-log.html
Comme la cohérence en termes d'ordre des opérations est garantie indépendamment du innodb_support_xa paramètre (qui contredit ce qui est dit dans la doc officielle sur innodb_support_xa , peut-être parce qu'il a été écrit sur le stock innodb 5.0.3 bien avant le correctif de concurrence), et la cohérence entre le journal innodb sur le maître et le journal relais sur l'esclave n'est pas strictement garantie même avec innodb_support_xa , je ne vois aucun intérêt à utiliser innodb_support_xa . Il est effrayant de ne pas suivre la recommandation officielle, cependant, elle semble obsolète et erronée sur de nombreux points.
Je me demande s'il existe une corrélation entre le innodb_flush_log_at_trx_commit paramètre et le innodb_support_xa comportement lorsque le premier est défini sur 2 ou 0.
Une façon pratique de penser est que le basculement vers l'esclave est sûr - après tout, la transaction échouée était quelque chose que vous vouliez faire - mais ne revenez jamais au maître, car il pourrait y avoir une certaine divergence dans les données. Vous devez copier entièrement les données de l'esclave avant de faire du maître un nouvel esclave. En d'autres termes, lorsque le maître s'est écrasé, faites confiance à l'esclave à partir de là - de cette façon, vous n'avez pas besoin de jouer avec le journal innodb pour la récupération après un crash.
Notez également que MySQL 5.5 prend en charge la réplication semi-synchrone, de la même manière que "faites confiance à l'esclave" - pensez que cela pourrait vous intéresser.
http://dev.mysql.com/doc/refman /5.5/fr/replication-semisync.html
