MySQL がデュアルマスターで構成されている場合にデータループの競合を回避する方法

あなたはこの質問について考えたことがあるでしょうか?デュアルアクティブが構成されている場合、データループの競合を回避するにはどうすればよいでしょうか。これは、アクティブ/アクティブ データ設計の中心的な設計思想の 1 つです。

メイン データベースが SQL ステートメントをトリガーする場合:

test_data(name) に値 ('aa') を挿入します。

次に、Master1 はバイナリ ログを生成し、データの変更を Master2 にプッシュし、Master2 でリレー ログを生成し、変更の再生のために SQL スレッドに渡します。逆のプロセスも同様です。全体のプロセスは次のように説明できます。

Master2 がリレーからデータを消費すると、binlog が生成されます (log_slave_updates はデフォルトで有効になっています)。この時点で生成された binlog は、消費のために Master1 にプッシュされ続け、その後プッシュされ続けます。挿入ステートメントのセットは無限になります。明らかに、この設計は不合理であり、MySQL はこれを絶対に行いません。

したがって、質問の重要な部分は次のとおりです。Master2 は以前のバイナリログを Master1 にプッシュしましたか?

a) プッシュされた場合、Master1 は無限ループを回避するためにどのようにフィルタリングしますか?

b) プッシュがない場合、マスター2はどのようにフィルタリングするのか

このプロセスを理解するには、テストをシミュレートし、データフロー中のバイナリログのステータスを確認する必要があります。このプロセスを参照できます。

1) Master1のバイナリログ

2) マスター2のリレーログ

3) マスターのバイナリログ

マスタースレーブ環境を素早く展開し、その後マスターを変更することで、テスト用のデュアルマスター環境を素早く構築しました。

可能な限り完全なbinlogイベント情報を表示するには、パラメータbinlog_rows_query_log_eventsをオンにします。

Master1 のトリガー ステートメント:

test_data(name) に値 ('gg') を挿入します。

取得されたバイナリログイベントは以下のとおりで、関連する SQL ステートメントが明確に確認できます。

Master2 側で、binlog ステータスを確認します。binlog_rows_query_log_events が有効になっている場合、イベント Rows_query が明らかに少なくなっていることがわかります。

この時点で考慮する必要があるのは、このプロセスでオフセットが変更されたかどうかです。Master1 によって生成された binlog から Master のリレー ログまで、mysqlbinlog を介して解析すると、取得されたオフセットはまったく同じです。Master2 が消費した後、関連する binlog 情報が生成されます。

問題の鍵はここにあります。Maser2 では、データのソースは Server_id でマークされるため、ここではデータ フロー全体のエンドポイントと呼ばれます。つまり、データがコピーされるときに server_id に従ってフィルタリングされ、各マスター エンドは独自の関連する binlog 情報のみを送信します。

この観点から見ると、MySQL がレプリケーションにおいて server_id を非常に重要視する理由の 1 つはこれに基づいています。

オフセットベースの非同期レプリケーションを別の観点から見ると、実際に同様の情報を得ることができます。

これは、Master1 が挿入ステートメントをトリガーした後のバイナリログの詳細です。

これは、Master2 がリアルタイム データを受信した後のバイナリ ログの詳細です。

実際、ここでもまだ問題があります。つまり、オフセット モードでは、Master2 でデータ変更操作が失われた場合、後戻りする方法がありません。

GTID モードでは、グローバルトランザクションを一意に識別できるため、操作が繰り返し適用されても、DDL 文であっても、操作によって影響を受ける行数は 0 になります。

すでに実行された操作を再適用して、MySQL がそのような操作を自動的に破棄するかどうかを確認します。

mysql> @@SESSION.GTID_NEXT= '6fb744dd-05dd-11ea-ada7-52540043a8b5:6' を設定します。

クエリは正常、影響を受けた行は 0 行 (0.00 秒)

mysql> `test` を使用します。テーブル test_data (id int primary key auto_increment,name varchar(30)) を作成します。

データベースが変更されました

クエリは正常、影響を受けた行は 0 行 (0.00 秒)

show binlog eventsこのプロセスでは追加の binlog が生成されないことがわかります。

そこで、これに基づいて、データ ループ ソリューションの設計アイデアを基本的に明確にしました。つまり、適用されたトランザクション データを MySQL が識別できるようにする方法です。GTID がその答えであり、分散 ID は必要ないと考えています。これは MySQL の内部処理の仕組みであり、MySQL が認識できる方法です。

上記は、MySQL がデュアルマスターで構成されている場合にデータループの競合を回避する方法の詳細です。MySQL でデータループの競合を回避する方法の詳細については、123WORDPRESS.COM の他の関連記事に注目してください。