自動フェイルオーバーは、多くのアプリケーションにとってほぼ必須です。稼働時間は当然のことと考えられています。誰かがログインして状況を調査するためにページングされてからアクションを実行する必要があるため、アプリケーションが20分または30分間ダウンしていることを受け入れるのは非常に困難です。
現実の世界では、レプリケーションの設定は時間の経過とともに大きくなり、複雑になり、場合によっては面倒になる傾向があります。そして、制約があります。たとえば、セットアップ内のすべてのノードが優れたマスター候補になるわけではありません。たぶん、ハードウェアが異なり、レプリカの中には、特定のタイプのワークロードを処理するための専用であるため、それほど強力ではないハードウェアを備えているものがありますか？たぶん、あなたは新しいMySQLバージョンへの移行の最中であり、いくつかのスレーブはすでにアップグレードされていますか？古いレプリカに複製する最新バージョンのマスターは、複製を壊す可能性があるため、使用したくありません。 1つはアクティブでもう1つはディザスタリカバリ用の2つのデータセンターがある場合、マスターをアプリケーションホストの近くに保つために、アクティブなデータセンターでのみマスター候補を選択することをお勧めします。これらは単なる例の状況であり、フェイルオーバープロセス中に手動で介入する必要がある場合があります。幸いなことに、多くのフェイルオーバーツールには、ホワイトリストとブラックリストを使用してプロセスを制御するオプションがあります。このブログ投稿では、マスター候補を選択するためのClusterControlのアルゴリズムに影響を与える方法の例をいくつか紹介します。
ホワイトリストとブラックリストの構成
ClusterControlには、レプリカのホワイトリストとブラックリストの両方を定義するオプションがあります。ホワイトリストは、マスター候補になることを目的としたレプリカのリストです。それらのいずれも使用できない場合（ダウンしている、誤ったトランザクションがある、またはそれらのいずれかを昇格させるのを妨げる他の障害があるため）、フェイルオーバーは実行されません。このようにして、マスター候補になるために使用できるホストを定義できます。一方、ブラックリストは、マスター候補になるのに適していないレプリカを定義します。
これらのリストは両方とも、特定のクラスターのcmon構成ファイルで定義できます。たとえば、クラスタのIDが「1」の場合、「/ etc / cmon.d/cmon_1.cnf」を編集します。ホワイトリストの場合は「replication_failover_whitelist」変数を使用し、ブラックリストの場合は「replication_failover_blacklist」になります。どちらも「host：port」のコンマ区切りリストを受け入れます。
次のレプリケーション設定について考えてみましょう。 2つのレプリカ（10.0.0.142と10.0.0.143）を持つアクティブマスター（10.0.0.141）があり、どちらも中間マスターとして機能し、それぞれ1つのレプリカ（10.0.0.144と10.0.0.147）を持っています。また、レプリカ（10.0.0.146）を持つ別のデータセンター（10.0.0.145）にスタンバイマスターがあります。これらのホストは、災害時に使用することを目的としています。レプリカ10.0.0.146および10.0.0.147はバックアップホストとして機能します。以下のスクリーンショットを参照してください。
2番目のデータセンターはディザスタリカバリのみを目的としているため、これらのホストをマスターとして昇格させることは望ましくありません。最悪のシナリオでは、手動でアクションを実行します。 2番目のデータセンターのインフラストラクチャは本番データセンターのサイズに合わせて拡張されていないため（DRデータセンターにはレプリカが3つ少ない）、DRデータセンターでホストをプロモートする前に手動でアクションを実行する必要があります。また、バックアップレプリカ（10.0.0.147）を昇格させたくありません。チェーン内の3番目のレプリカをマスターとして取得する必要もありません（GTIDを使用して実行できたとしても）。
ホワイトリストの構成
ホワイトリストまたはブラックリストのいずれかを構成して、フェイルオーバーが希望どおりに処理されるようにすることができます。この特定のセットアップでは、ホワイトリストを使用する方が適切な場合があります。フェイルオーバーに使用できるホストを定義し、誰かがセットアップに新しいホストを追加した場合、誰かが手動で決定するまで、マスター候補として考慮されません。それを使用してホワイトリストに追加しても大丈夫です。ブラックリストを使用した場合、チェーンのどこかに新しいレプリカを追加すると、誰かが明示的に使用できないと言わない限り、理論的にはそのようなレプリカをフェイルオーバーに自動的に使用できる可能性があります。安全を確保し、クラスター構成ファイルでホワイトリストを定義しましょう（この場合、クラスターが1つしかないため、/etc/cmon.d/cmon_1.cnfになります）：
replication_failover_whitelist=10.0.0.141:3306,10.0.0.142:3306,10.0.0.143:3306変更を適用するには、cmonプロセスが再開されていることを確認する必要があります：
service cmon restartマスターがクラッシュし、ClusterControlから到達できないと仮定しましょう。フェイルオーバージョブが開始されます：
トポロジは次のようになります。
ご覧のとおり、古いマスターは無効になっており、ClusterControlは自動的にマスターを回復しようとはしません。何が起こったかを確認し、複製されていない可能性のあるデータをマスター候補にコピーして、古いマスターを再構築するのはユーザーの責任です。
次に、トポロジをいくつか変更するだけで、トポロジを元の状態に戻すことができます。10.0.0.141を10.0.0.142に置き換えるだけです。
ブラックリストの構成
次に、ブラックリストがどのように機能するかを確認します。この例では、これは最善の選択肢ではないかもしれないと述べましたが、説明のために試してみます。 10.0.0.141、10.0.0.142、10.0.0.143を除くすべてのホストをブラックリストに登録します。これらは、マスター候補として表示するホストです。
replication_failover_blacklist=10.0.0.145:3306,10.0.0.146:3306,10.0.0.144:3306,10.0.0.147:3306また、cmonプロセスを再起動して、構成の変更を適用します。
service cmon restartフェイルオーバープロセスも同様です。この場合も、マスタークラッシュが検出されると、ClusterControlはフェイルオーバージョブを開始します。
レプリカが優れたマスター候補ではない可能性がある場合
この短いセクションでは、特定のレプリカを新しいマスターに昇格させたくない場合のいくつかについて詳しく説明します。うまくいけば、これにより、フェイルオーバープロセスをより手動で制御することを検討する必要がある場合のアイデアが得られるでしょう。
異なるMySQLバージョン
まず、レプリカがマスターとは異なるMySQLバージョンを使用している場合、それをプロモートすることはお勧めできません。一般的に言って、新しいバージョンから古いバージョンへのレプリケーションはサポートされておらず、正しく機能しない可能性があるため、新しいバージョンは常に使用できません。これは主にメジャーバージョン（たとえば、8.0から5.7への複製）に関連しますが、小さなバージョンの違い（5.7.x + 1-> 5.7.x）について話している場合でも、この設定を完全に回避することをお勧めします。アップグレードプロセスでは必須であるため、下位バージョンから上位/新しいバージョンへの複製がサポートされていますが、それでも、これは避けたいと考えています（たとえば、マスターが5.7.x + 1の場合は、置き換えたくないでしょう。 5.7.xのレプリカを使用）。
さまざまな役割
レプリカに異なる役割を割り当てることができます。開発者が本番データセットでクエリをテストできるように、そのうちの1つを選択できます。それらの1つをOLAPワークロードに使用できます。それらの1つをバックアップに使用できます。それが何であれ、通常、そのようなレプリカをマスターに昇格させたくないでしょう。これらの追加の非標準ワークロードはすべて、追加のオーバーヘッドが原因でパフォーマンスの問題を引き起こす可能性があります。マスター候補の適切な選択は、現在のマスターとほぼ同じタイプの負荷である「通常の」負荷を処理するレプリカです。そうすれば、フェイルオーバー前にマスターロードを処理した場合、フェイルオーバー後にマスターロードを処理できることを確認できます。
さまざまなハードウェア仕様
レプリカのさまざまな役割について説明しました。特にさまざまな役割と組み合わせて、さまざまなハードウェア仕様を確認することも珍しくありません。たとえば、バックアップスレーブは、通常のレプリカほど強力である必要はほとんどありません。開発者は、本番データベースよりも遅いデータベースでクエリをテストすることもできます（主に、開発データベースと本番データベースで同じレベルの同時実行性を期待できないため）。たとえば、CPUコア数を減らすことができます。ディザスタリカバリのセットアップは、主な役割がレプリケーションに対応することであり、DRセットアップをスケーリングする必要がある場合は、サイズを縮小することもできます（垂直方向、インスタンスのサイズ変更、水平方向、レプリカの追加の両方）。トラフィックをリダイレクトする前に。
遅延レプリカ
一部のレプリカは遅延する可能性があります。これは、データが失われた場合の回復時間を短縮するための非常に優れた方法ですが、マスター候補としては非常に悪いものになります。レプリカが30分遅れると、その30分のトランザクションが失われるか、レプリカがすべての遅れたトランザクションを適用するのを待つ必要があります（おそらく、レプリカがより速く追いつく可能性があるため、30分ではありません）。 ClusterControlを使用すると、待機するか、すぐにフェイルオーバーするかを選択できますが、これは非常に小さな遅延（最大で数十秒）で問題なく機能します。フェイルオーバーに数分かかると思われる場合は、そのようなレプリカを使用しても意味がないため、ブラックリストに登録することをお勧めします。
さまざまなデータセンター
スケールダウンされたDRセットアップについて説明しましたが、2番目のデータセンターが本番環境のサイズにスケールダウンされている場合でも、フェイルオーバーを単一のDC内にのみ維持することをお勧めします。手始めに、アクティブなアプリケーションホストがメインデータセンターに配置されている可能性があるため、マスターをスタンバイDCに移動すると、書き込みクエリのレイテンシが大幅に増加します。また、ネットワーク分割の場合は、この状況を手動で処理することをお勧めします。 MySQLにはクォーラムメカニズムが組み込まれていないため、2つのデータセンター間のネットワーク損失を（自動的に）正しく処理するのは難しいです。