データベースインフラストラクチャの一部がオンプレミスにあり、一部がパブリッククラウドにあるハイブリッド環境も珍しくありません。このようなセットアップを使用する理由はさまざまです。スケーラビリティ、柔軟性、高可用性、ディザスタリカバリです。この設定を適切な方法で実装するにはどうすればよいですか？一緒に収まらなければならないパズルのいくつかのピースを考慮する必要があるので、これは難しいかもしれません。このブログは、そのような設定がどのように見えるかについての洞察を提供することを目的としています。
オンプレミス設定とパブリッククラウド間の接続を設定する方法は多数あるため、ここでは詳しく説明しません。それは、設置しているインフラストラクチャ、使用したいパブリッククラウド、およびその他の多くの要因によって異なります。オプションの範囲は、ハードウェアVPNを介して、BGP対応ルーターから始まり、パブリッククラウド内のインスタンスにネットワークを一時的に接続する方法としてSSHトンネルで終わる可能性があります。重要なのは、何をしようとしても、最終的な結果は、オンプレミスネットワークからパブリッククラウドにあるインスタンスへの完全で透過的な接続である必要があります。
MySQLレプリケーションは、高可用性システムを構築するための優れた方法ですが、大きな制限があります。考慮すべき主なことは、ライターです。書き込みを送信する場所は1つだけです。マスターです。環境全体をどのように設計する場合でも、マスターの配置を慎重に検討する必要があります。ほとんどの場合、アプリケーションホストを含む環境の一部にする必要があります。次の設定について考えてみましょう。
3つのMySQLノードと2つの追加のスレーブを備えたオンプレミスセットアップがありますパブリッククラウドに配置され、企業のディザスタリカバリ手段として機能するため、書き込み可能なノードをクラウドのプライベート部分のアプリケーションホストと同じ場所に配置する必要があることは明らかです。最も重要な接続の遅延を可能な限り低く抑えたいと考えています。
この種の設計は、データベースの可用性に重点を置いています。オンプレミスにあるノードが利用できない場合、アプリケーションホストはセットアップのリモート部分に接続できる可能性があります。データベースノードは次の場所にあります。パブリッククラウドで。理想的には、このために何らかのプロキシを使用します。ProxySQLは、トポロジを追跡し、既存のレプリケーションチェーンに基づいて必要に応じて再構成できるソリューションの1つです。
プライベートとパブリックの両方にアプリケーションノードがあるアクティブ-アクティブセットアップをもっと検討したい場合は、書き込みをWAN経由で転送する必要があるため、妥協する必要があります。パブリッククラウドからプライベートクラウドへ（または、パブリッククラウドで運用するメインの場所の場合はその逆）
繰り返しになりますが、ProxySQLが最適なプロキシです。すばらしいことに、ProxySQLはProxySQLクラスターとして構成できるため、1つのノードで導入された構成変更が、残りのProxySQLノード間で確実に複製されます。
前述のように、クラウドのプライベート部分が使用できなくなった場合、スレーブの1つを新しいマスターに昇格させるために手動アクションが必要になります。次に、ローカルProxySQLを使用して、パブリッククラウドに配置されている残りのすべてのWebアプリケーションサーバーは、トラフィックを新しいマスターと残りのすべてのスレーブにリダイレクトします。一方、5つのMySQLノードのうち3つが失われたことを考えると、パブリッククラウドのセットアップをスケールアウトしたいと考えています。ClusterControlは、クラスターにノードを効率的に追加するのに役立ちます。
別のシナリオとして、オンプレミスのセットアップとパブリッククラウド間の接続が正常に機能しているときにライターがクラッシュした可能性があります。
このようなシナリオでは、スレーブの1つを新しいマスターに昇格させたいと考えています。要件によっては、環境の特定の部分のノード間で新しいマスターを昇格させたい場合もあります。 ClusterControlには、フェイルオーバーのノードをホワイトリストまたはブラックリストに登録する機能があり、フェイルオーバープロセスを完全に制御し、新しいマスターの候補と見なすノードとその順序を選択できます。
このブログで、MySQLレプリケーションのハイブリッドクラウドセットアップがどのように機能し、データベースまたはネットワークに障害が発生した場合にどのように保護できるかについてのアイデアが得られたことを願っています。