この設定を実現するための主な課題は、ネットワークのパーティション分割に関連する問題の可能性を減らす方法でデータベースを設計することです。
MariaDBクラスターは、いくつかの理由から、このような環境を構築するのに適しています。ここでそれらについて話し合い、そのような環境がどのように見えるかについても少し話したいと思います。
最初の理由は、MariaDBクラスターが複数のライターをサポートできることです。これにより、書き込みルーティングの設計が容易になります。ローカルのMariaDBノードに書き込むだけです。もちろん、同期レプリケーションを考えると、レイテンシーは書き込みパフォーマンスに影響を与え、クラスターを地理的に分散しすぎると、書き込みが遅くなることがあります。結局のところ、物理法則を無視することはできず、少なくとも今のところ、ファイバー接続の光の速度さえも制限されていると彼らは言っています。その上にルーターを追加すると、たとえ数ミリ秒であっても、遅延が増加します。
次に、MariaDBクラスターでのラグ処理。非同期レプリケーションはレプリケーションラグの影響を受けます。スレーブがすべての変更を時間内に適用するのに苦労している場合、スレーブはデータを最新の状態に保つことができない可能性があります。 MariaDBクラスターでは、これは異なります。フロー制御は、クラスターの同期を維持することを目的としたメカニズムです。まあ、ほとんど-いくつかのエッジケースでは、まだラグを観察することができます。ここで話しているのは、通常、ミリ秒、最大で数秒ですが、非同期レプリケーションの空では限界です。
3番目のセグメント。デフォルトでは、MariaDB CLusterはすべての通信を使用し、すべての書き込みセットはノードによってクラスター内の他のすべてのノードに送信されます。この動作は、セグメントを使用して変更できます。セグメントを使用すると、ユーザーはMariaDBクラスターをいくつかの部分に分割できます。各セグメントには複数のノードが含まれる場合があり、そのうちの1つをリレーノードとして選択します。このようなノードは、他のセグメントからライトセットを受け取り、セグメントにローカルなMariaDBノード全体にそれらを再配布します。その結果、上の図からわかるように、WANを介して送信されるレプリケーショントラフィックを3回減らすことができます。レプリケーションストリームの2つの「レプリカ」のみがWANを介して送信されます。データセンターごとに1つ、スレーブごとに1つです。非同期レプリケーションで。
最後に、MariaDBクラスターが本当に優れているのは、ネットワークパーティショニングの処理です。 MariaDBクラスターは、クラスター内のノードの状態を常に監視しています。すべてのノードは、そのピアと接続してクラスターの状態を交換しようとします。ノードのサブセットに到達できない場合、MariaDBは通信を中継しようとするため、それらのノードに到達する方法がある場合は、それらに到達します。
上の図に例を示します：DC1が接続を失いましたDC2を使用しますが、DC2とDC3は接続できます。この場合、DC3のノードの1つを使用して、DC1からDC2にデータを中継し、クラスター内通信を維持できるようにします。
MariaDBは、クラスターの状態に基づいてアクションを実行できます。クォーラムを実装します。クラスターが動作できるようにするには、ノードの大部分が使用可能である必要があります。ノードがクラスターから切断され、他のノードに到達できない場合、ノードは動作を停止します。
上の図に示されているように、DC1のネットワーク通信が部分的に失われ、影響を受けるノードがクラスターから削除され、アプリケーションが古いデータにアクセスしないようにします。
>
これは大規模にも当てはまります。 DC1はすべての通信を遮断しました。その結果、データセンター全体がクラスターから削除され、そのノードのどちらもトラフィックを処理しなくなりました。クラスターの残りの部分は過半数を維持し（9ノードのうち6ノードが使用可能）、DC2とDC3の間の接続を維持するようにクラスター自体を再構成しました。上の図では、ライターがDC2のノードにヒットすると想定していますが、MariaDBは複数のライターで実行できることに注意してください。
MariaDBクラスターを地理的に分散した環境に最適にするいくつかの機能について説明しました。ここで、設計に少し焦点を当てましょう。最初に、私たちが取り組んでいる環境について説明しましょう。ワイドエリアネットワーク（WAN）を介して接続された3つのリモートデータセンターを使用します。各データセンターは、ローカルアプリケーションサーバーから書き込みを受信します。読み取りもローカルのみになります。これは、WANを通過する不要なトラフィックを回避することを目的としています。
このブログの複雑さを軽減するために、接続がどのようになるかについては詳しく説明しません。すべてのデータセンター間で、適切に構成された安全な接続があることを前提としています。 VPNまたは他のツールを使用してそれを実装できます。
MaxScaleをロードバランサーとして使用します。 MaxScaleは、各データセンターにローカルに導入されます。また、トラフィックをローカルノードにのみルーティングします。リモートノードはいつでも手動で追加できます。これが適切なソリューションとなる場合について説明します。ラウンドロビンアルゴリズムを使用して、ローカルMaxScaleノードの1つに接続するようにアプリケーションを構成できます。単一のMaxScaleノードがすべてのトラフィックを処理できる限り、Keepalivedと仮想IPを使用してトラフィックを単一のMaxScaleノードにルーティングすることもできます。
別の可能な解決策は、MaxScaleをアプリケーションノードと併置し、ローカルホスト上のプロキシに接続するようにアプリケーションを構成することです。このアプローチは、MaxScaleが利用できない可能性は低いが、アプリケーションが同じノードで正常に動作するという前提の下で非常にうまく機能します。通常、私たちが目にするのはノード障害またはネットワーク障害のいずれかであり、MaxScaleとアプリケーションの両方に同時に影響を及ぼします。
上の図は、MaxScaleがプロキシファームを形成する環境のバージョンを示しています。 -同じ構成のすべてのプロキシノード、Keepalivedを使用して負荷分散、またはすべてのMaxScaleノード間でアプリケーションからのラウンドロビン。 MaxScaleは、ローカルデータセンター内のすべてのMariaDBノードにワークロードを分散するように構成されています。これらのノードの1つは、書き込みを送信するノードとして選択され、SELECTはすべてのノードに分散されます。データセンターに専用のライターノードを1つ持つことで、認証の競合の可能性を減らすことができ、通常、パフォーマンスが向上します。これをさらに減らすには、WAN接続を介してトラフィックを送信し始める必要がありますが、帯域幅の使用率が大幅に増加するため、これは理想的ではありません。現在、セグメントが配置されているため、データセンター間で送信されるライトセットのコピーは2つだけです（DCごとに1つ）。
ご覧のとおり、MariaDBクラスターを使用すると、世界中で機能する地理分散クラスターを簡単に作成できます。制限要因はネットワーク遅延です。高すぎる場合は、非同期レプリケーションを使用して接続された個別のMariaDBクラスターの使用を検討する必要があります。