このページは機械翻訳したものです。

17.5.1.35 レプリケーションとトランザクション

同じトランザクション内にトランザクションおよび非トランザクションステートメントを混在させる.  一般的に、レプリケーション環境でトランザクションおよび非トランザクションテーブルの両方を更新するトランザクションは避けるべきです。 トランザクション (または一時) および非トランザクションテーブルの両方にアクセスしてそれらに書き込むステートメントを使用することも避けるべきです。

サーバーは、バイナリロギングに次の規則を使用します:

• トランザクション内の最初のステートメントが非トランザクションである場合、それらはすぐにバイナリログに書き込まれます。 トランザクション内の残りのステートメントはキャッシュされ、トランザクションがコミットされるまでバイナリログに書き込まれません。 (トランザクションがロールバックされた場合、キャッシュされたステートメントは、ロールバックできない非トランザクション変更を行う場合にのみバイナリログに書き込まれます。 それ以外の場合は、それらは破棄されます。)

• ステートメントベースロギングの場合、非トランザクションステートメントのロギングは binlog_direct_non_transactional_updates システム変数によって影響されます。 この変数が OFFの場合 (デフォルト)、ロギングは上記のとおりになります。 この変数が ON の場合、非トランザクションステートメントがトランザクション内のどこで発生しても (最初の非トランザクションステートメントだけではありません)、ただちにロギングが発生します。 ほかのステートメントはトランザクションキャッシュに保持され、トランザクションがコミットしたときにログが記録されます。binlog_direct_non_transactional_updates は行形式または混合形式バイナリロギングに影響しません。

トランザクション、非トランザクション、および混合ステートメント.  これらのルールを適用する場合、サーバーは、非トランザクションテーブルだけを変更する場合にはステートメントを非トランザクションと見なし、トランザクションテーブルだけを変更する場合にはトランザクションと見なします。 非トランザクションテーブルとトランザクションテーブルの両方を参照し、関係するテーブルを更新するステートメントは、「mixed」 ステートメントとみなされます。 混合ステートメントは、トランザクションステートメントと同様に、キャッシュされ、トランザクションがコミットするときにログが記録されます。

トランザクションテーブルを更新する混合ステートメントは、次のアクションのいずれかを実行する場合も、安全ではないと見なされます。

• 一時テーブルの更新または読取り

• 非トランザクションテーブルを読み取り、トランザクション分離レベルが REPEATABLE_READ 未満

トランザクション内でトランザクションテーブル更新に続く混合ステートメントは、次のアクションのいずれかを実行する場合、安全ではないと見なされます。

• テーブルを更新し、一時テーブルから読み取る

• 非トランザクションテーブルを更新し、binlog_direct_non_transactional_updates が OFF の場合

詳細については、セクション17.2.1.3「バイナリロギングでの安全および安全でないステートメントの判断」を参照してください。

注記

混合ステートメントは混合バイナリロギング形式とは関係ありません。

トランザクション内でトランザクションおよび非トランザクションテーブルへの更新が混在している状況で、バイナリログ内のステートメントの順序は正しく、必要なすべてのステートメントがバイナリログに書き込まれます (ROLLBACK の場合でも)。 ただし、最初の接続トランザクションが完了する前に 2 番目の接続が非トランザクションテーブルを更新するときは、ステートメントログが記録される順序が乱れる場合があります。最初の接続によって実行されているトランザクションの状態にかかわらず、2 番目の接続更新が実行された直後に書き込まれるためです。

ソースとレプリカで異なるストレージエンジンを使用.  レプリカの非トランザクションテーブルを使用して、ソースでトランザクションテーブルをレプリケートできます。 たとえば、InnoDB ソーステーブルを MyISAM レプリカテーブルとしてレプリケートできます。 ただし、これを行うと、レプリカが BEGIN ... COMMIT ブロックの先頭から再開されるため、レプリカが BEGIN ... COMMIT ブロックの途中で停止した場合に問題が発生します。

また、ソース上の MyISAM テーブルからレプリカ上のトランザクションテーブル (InnoDB ストレージエンジンを使用するテーブルなど) にトランザクションをレプリケートすることも安全です。 このような場合、ソースで発行された AUTOCOMMIT=1 ステートメントがレプリケートされるため、レプリカで AUTOCOMMIT モードが強制されます。

レプリカのストレージエンジンタイプが非トランザクションの場合、トランザクションテーブルと非トランザクションテーブルの更新が混在するソース上のトランザクションは、ソーストランザクションテーブルとレプリカ非トランザクションテーブルの間でデータの不整合を引き起こす可能性があるため、回避するようにしてください。 つまり、このようなトランザクションは、ソースストレージエンジン固有の動作につながり、レプリケーションが同期しなくなる可能性があります。 MySQL では、これに関する警告は発行されないため、レプリカ上でソーステーブルから非トランザクションテーブルにトランザクションテーブルをレプリケートする場合は、特に注意する必要があります。

トランザクション内でバイナリロギング形式を変更する.  binlog_format および binlog_checksum システム変数は、トランザクションが進行中であれば読取り専用です。

各トランザクション (autocommit トランザクションを含む) は、BEGIN ステートメントで始まり、COMMIT または ROLLBACK ステートメントで終わるかのように、バイナリログに記録されます。 これは、非トランザクションストレージエンジン (MyISAM など) を使用するテーブルに影響を与えるステートメントにも当てはまります。

注記

XA トランザクションに特に適用される制限については、セクション13.3.8.3「XA トランザクションの制約」 を参照してください。