準同期レプリケーションセットアップでクラッシュしたMySQLマスターサーバーを再スレーブ化する

MySQL5.7マスタースレーブセットアップでrpl_semi_sync_master_wait_pointのデフォルトの準同期レプリケーション設定を使用する場合 、マスターのクラッシュとスレーブへのフェイルオーバーは無損失と見なされます。ただし、クラッシュしたマスターが戻ってきたときに、現在のマスター（以前はスレーブでした）に存在しないトランザクションが含まれている場合があります。準同期レプリケーションはロスレスであると想定されているため、この動作は不可解かもしれませんが、これは実際にはMySQLで予想される動作です。なぜこれが正確に起こるのかは、Jean-FrançoisGagné（JF）によるブログ投稿で詳細に説明されています。

このようなシナリオを考えると、MySQLのドキュメントでは、クラッシュしたマスターを破棄し、再起動しないことを推奨しています。ただし、このようなサーバーを破棄すると、コストがかかり、非効率的です。このブログ投稿では、準同期レプリケーションセットアップでクラッシュしたMySQLマスターサーバー上のトランザクションを検出して修正する方法と、マスタースレーブセットアップに再スレーブする方法について説明します。

リカバリされたマスターで余分なトランザクションを検出することが重要なのはなぜですか？

復元されたマスターでの余分なトランザクションは、次の2つの方法で現れる可能性があります。

1。リカバリされたマスターが再スレーブされると、MySQLレプリケーションが失敗します

通常、これは自動インクリメントの主キーがある場合に発生します。新しいMySQLマスターがそのようなテーブルに行を挿入すると、キーがすでにスレーブに存在するため、レプリケーションは失敗します。

別のシナリオは、マスターのクラッシュ中に失敗したトランザクションをアプリが再試行する場合です。回復されたMySQLマスター（現在はスレーブ）では、このトランザクションが実際に存在し、再度、レプリケーションエラーが発生します。

通常、MySQLレプリケーションエラーは次のようになります：

2。新しいMySQLマスターとスレーブ（回復されたマスター）間のデータのサイレントな不整合

アプリケーションが失敗したトランザクションを再試行せず、将来的に主キーの衝突が発生しない場合、レプリケーションエラーは発生しない可能性があります。その結果、データの不整合が検出されなくなる可能性があります。

上記のどちらの場合も、MySQLセットアップの高可用性またはデータ整合性が影響を受けるため、この状態をできるだけ早く検出することが非常に重要です。

回復されたMySQLマスターで余分なトランザクションを検出する方法

MySQL GTID（グローバルトランザクション識別子）関数を使用して、リカバリされたマスターに余分なトランザクションがあるかどうかを検出できます：

GTID_SUBSET（ set1 、 set2 ）：2セットのグローバルトランザクションIDが与えられた場合 set1 およびset2 、 set1内のすべてのGTIDがtrueを返す set2にもあります 。それ以外の場合はfalseを返します。

これを理解するために例を使用しましょう。

• UUIDが‘ 54a63bc3-d01d-11e7-bf52-000d3af93e52であるリカバリされたマスターに設定されたGTID ’は：
  • '54a63bc3-d01d-11e7-bf52-000d3af93e52：1-9700,57956099-d01d-11e7-80bc-000d3af97c09：1-810'
• UUIDが‘ 57956099-d01d-11e7-80bc-000d3af97c09である新しいマスターのGTIDセット ’は：
  • '54a63bc3-d01d-11e7-bf52-000d3af93e52：1-9690,57956099-d01d-11e7-80bc-000d3af97c09：1-870'

ここで、GTID_SUBSET関数を GTID_SUBSET（復元されたマスターのGTIDセット、新しいマスターのGTIDセット）として呼び出すと 、復元されたマスターに追加のトランザクションがない場合にのみ、戻り値はtrueになります。上記の例では、復元されたマスターに9691から9700までの追加のトランザクションがあるため、上記のクエリの結果はfalseです。