レプリケーションは、バイナリログに書き込まれたイベントがソースから読み取られてからレプリカで処理されるため機能します。 イベントは、イベントタイプに従ってさまざまな形式でバイナリログに記録されます。 使用されるさまざまなレプリケーション形式は、イベントがソースバイナリログに記録されたときに使用されたバイナリロギング形式に対応します。 バイナリロギング形式とレプリケーションで使用される用語との関係は次のとおりです。

NDB Cluster.  MySQL NDB Cluster 8.0 のデフォルトのバイナリロギング形式は MIXED です。 NDB Cluster レプリケーションは常に行ベースレプリケーションを使用し、NDB ストレージエンジンはステートメントベースレプリケーションと互換性がないことに注意してください。 詳細については、セクション23.6.2「NDB Cluster レプリケーションの一般的な要件」を参照してください。

混合形式を使用する場合、バイナリロギング形式は、使用されているストレージエンジンと実行されているステートメントによってある程度決定されます。 混合形式のロギング、および異なるロギング形式のサポートを管理するルールの詳細は、セクション5.4.4.3「混合形式のバイナリロギング形式」を参照してください。

実行中 MySQL サーバーのロギング形式は、binlog_format サーバーシステム変数を設定することで制御されます。 この変数はセッションまたはグローバルスコープで設定できます。 新しい設定が有効になるタイミングと方法を制御するルールは、他の MySQL サーバーシステム変数の場合と同じです。 現在のセッションの変数の設定は、そのセッションが終了するまでのみ継続され、変更は他のセッションには表示されません。 変数をグローバルに設定すると、変更後に接続するクライアントに対して有効になりますが、変数設定が変更されたセッションを含む現在のクライアントセッションに対しては有効になりません。 グローバルシステム変数設定を永続的にしてサーバーの再起動後も適用されるようにするには、オプションファイルで設定する必要があります。 詳細は、セクション13.7.6.1「変数代入の SET 構文」を参照してください。

実行時にバイナリロギング形式を変更できない、つまりそのようにするとレプリケーションが失敗する状況があります。 セクション5.4.4.2「バイナリログ形式の設定」を参照してください。

グローバル binlog_format 値を変更するには、グローバルシステム変数を設定するのに十分な権限が必要です。 セッションの binlog_format 値を変更するには、制限付きセッションシステム変数を設定するのに十分な権限が必要です。 セクション5.1.9.1「システム変数権限」を参照してください。

ステートメントベースと行ベースのレプリケーション形式には、異なる問題と制限があります。 関連するメリットとデメリットの比較は、セクション17.2.1.1「ステートメントベースおよび行ベースレプリケーションのメリットとデメリット」を参照してください。

ステートメントベースのレプリケーションでは、ストアドルーチンまたはトリガーの複製で問題が発生する場合があります。 代わりに行ベースのレプリケーションを使用することで、これらの問題を回避できます。 詳細については、セクション25.7「ストアドプログラムバイナリロギング」を参照してください。