MySQLでは、シングルスレッド更新のinnodb_support_xaをオフにしても安全なのはなぜですか？

まず...

http://yoshinorimatsunobu.blogspot.com/2009 / 08 / great-performance-effect-of-fixing.html

InnoDBプラグイン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プラグイン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を取得し、コミット用にさらに100fsyncを取得します。したがって、グループコミットは完全に壊れていました。

新しい実装では、トランザクションの同時実行性に応じてfsyncがグループ化され、innodbログとbinlogの間の操作の順序が保証されます。また、スレッドが1つしかない場合、パフォーマンスは向上しません。

トランザクションがbinlogに書き込まれた後、トランザクションログに書き込まれる前にクラッシュが発生した場合、私はあなたと同じページにいます。

最終ステップの前にサーバーがクラッシュした場合、innodbログとbinlogの間に不一致がある可能性がわずかにあります（どちらかが他方よりも進んでいる可能性があります）が、何をすべきかに関するすべての情報があることが保証されます調べる 準備フェーズで記録されるため、innodbログに記録されます。

ただし、コミットされていないものをどうするかはまだ決定論的ではありません。たとえば、sync_binlog = 1でない限りスレーブがデータを受信したが、マスターのbinlogをまだ完全にfsyncしていない可能性があります。失敗したトランザクションはすでにスレーブの1つで実行されている可能性があるため、単にやり直すことはできません。

これは、binlogがinnodbログよりも短く、「バイナリログ[file_name]が予想サイズよりも短い」ことを返す可能性があることも意味します。公式ドキュメントで説明されているように、スレーブを最初から再構築する必要があります。あまり人間に優しいわけではありません。

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に設定されている場合の動作。

実用的な考え方の1つは、スレーブへのフェイルオーバーは安全であるということです。結局のところ、失敗したトランザクションは実行したいものでしたが、データに不一致がある可能性があるため、マスターにフェイルバックすることはありません。マスターを新しいスレーブにする前に、スレーブからデータを完全にコピーする必要があります。つまり、マスターがクラッシュしたときは、それ以降はスレーブを信頼します。そうすれば、クラッシュリカバリのためにinnodbログをいじる必要はありません。

また、MySQL 5.5は、「スレーブを信頼する」と同じように、準同期レプリケーションをサポートしていることに注意してください。興味があるかもしれません。

http://dev.mysql.com/doc/refman /5.5/en/replication-semisync.html