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

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

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

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

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

詳細については、セクション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 など) を使用するテーブルに影響を与えるステートメントにも当てはまります。