ハイブリッドクラウドでのGaleraクラスターの実行は、少なくとも2つの異なる地理的サイトで構成され、オンプレミスまたはプライベートクラウドのホストをパブリッククラウドのホストに接続する必要があります。壊れないプライベートクラウドまたはパブリッククラウドプラットフォームのどちらを使用する場合でも、ディザスタリカバリ（DR）は確かに重要な問題です。これは、データをバックアップサイトにコピーして復元できるようにすることではなく、ビジネス継続性と、災害が発生したときにサービスをどれだけ迅速に回復できるかについてです。
このブログ投稿では、ハイブリッドクラウド環境でフォールトトレランスを実現するためにGaleraクラスターを設計するさまざまな方法を検討します。
Galera Clusterは、クラスター内の合計ノード数が奇数で実行されている必要があり、通常は3ノードで開始されます。これは、Galera Clusterがクォーラムを使用して、クラスターのパーティション分割が発生した場合に、接続されたノードの大部分が一度にクラスターにサービスを提供できるプライマリコンポーネントを自動的に決定するためです。
アクティブ-アクティブセットアップハイブリッドクラウドセットアップの場合、Galeraには少なくとも3つの異なるサイトが必要であり、WAN全体でGaleraクラスターを形成します。一般に、仲裁人として機能し、定足数に投票し、いずれかのサイトに到達できない場合は「主要コンポーネント」を保持するために、3番目のサイトが必要になります。これは、次の図のように、3つの異なるサイト（サイトごとに1ノード）に少なくとも3ノードのクラスターとして設定できます。
ただし、パフォーマンスと信頼性の観点から、7を使用することをお勧めします。 -次の図に示すように、ノードクラスター：
これは、アクティブ-アクティブセットアップをサポートするのに最適なトポロジと見なされます。この場合、DRサイトは、介入なしでほぼ即座に使用可能になります。クラスターがクォーラム内にある場合、両方のサイトはいつでも読み取り/書き込みを受信できます。
ただし、3つのサイトと7つのデータベースノードを使用するには非常にコストがかかります（7番目のノードはクライアント/アプリケーションにデータを提供するために使用される可能性が非常に低いため、garbdに置き換えることができます）。これは、プロジェクトの開始時に一般的に普及していない展開です。これは、初期費用が莫大であり、Galeraグループの通信とレプリケーションがネットワーク遅延にどれほど敏感であるかによるものです。
アクティブ-パッシブ構成では、少なくとも2つのサイトが必要であり、一度に1つのサイトのみがアクティブになります。これはプライマリサイトと呼ばれ、セカンダリサイトのノードはプライマリからのデータのみを複製します。サーバー/クラスター。 Galera Clusterの場合、MySQL非同期レプリケーション（マスタースレーブレプリケーション）を使用するか、Galeraの仮想同期レプリケーションを使用して、ライトセットレプリケーションをトーンダウンして非同期レプリケーションとして機能させることもできます。
データフローは常にプライマリサイトからセカンダリサイトに送られるため、読み取り専用フラグ、アプリケーションファイアウォール、リバースプロキシ、またはその他の手段を使用して、偶発的な書き込みからセカンダリサイトを保護する必要があります。フェイルオーバーにより、セカンダリサイトが開始され、プライマリとして昇格されました。
非同期レプリケーションの良い点は、レプリケーションがソースサーバー/クラスターに影響を与えないことですが、マスターより遅れることができます。この設定により、プライマリサイトとDRサイトが互いに独立し、非同期レプリケーションとの接続が緩くなります。これは、次の図のように、2つの異なるサイトに最低4ノードのクラスターとして設定できます。
DRサイトのGaleraノードの1つはスレーブになり、プライマリサイトのGaleraノード（マスター）の1つから複製されます。両方のサイトでGTIDを使用してバイナリログを生成する必要があり、log_slave_updatesが有効になっています。非同期レプリケーションストリームからの更新は、クラスター内の他のノードに適用されます。ただし、本番環境で使用する場合は、次の図に示すように、両方のサイトに2セットのクラスターを配置することをお勧めします。
2つの別々のクラスターを使用することで、それらは緩く結合され、相互に影響を与えません。プライマリサイトでのクラスタ障害は、DRサイトに影響を与えません。パフォーマンス面では、WAN遅延はアクティブクラスターの更新に影響を与えません。これらは、バックアップサイトに非同期で出荷されます。 DRクラスターは、プライマリクラスターに対応できる限り、パブリッククラウド環境の小規模なインスタンスで実行できる可能性があります。インスタンスは必要に応じてアップグレードできます。アプリケーションはプライマリサイトに書き込みを送信する必要があり、セカンダリサイトは読み取り専用モードで実行するように設定する必要があります。ディザスタリカバリサイトは、データベースのバックアップ、バイナリログのバックアップ、分析クエリ（OLAP）のレポートまたは処理などの他の目的に使用できます。
欠点として、スレーブが遅れていた場合、フェイルオーバー/フォールバック中にデータが失われる可能性があります。したがって、データ損失のリスクを下げるために、準同期レプリケーションを有効にすることをお勧めします。準同期レプリケーションを使用しても、Galeraの仮想同期レプリケーションと比較した場合、データ損失に対する強力な保証は提供されないことに注意してください。このMySQLマニュアルを注意深く読んでください。たとえば、次の文章を読んでください。
"半同期レプリケーションでは、ソースがクラッシュしてレプリカへのフェイルオーバーが実行された場合、失敗したソースをレプリケーションソースとして再利用せず、破棄する必要があります。レプリカによって確認されないため、フェイルオーバー前にコミットされませんでした。」
アクティブ-パッシブセットアップの場合、次の3のスクリーンショットに示すように、プライマリサイトにあるノードの大部分と、ディザスタリカバリサイトにあるノードの少数を配置できます。ノードガレラクラスター：
プライマリサイトがダウンしている場合、クォーラムが不足しているため、クラスターは失敗します。ディザスタリカバリサイト（db3-dr）のGaleraノードは、単一ノードのプライマリコンポーネントとして手動でブートストラップする必要があります。プライマリー・サイトが復旧したら、プライマリー・サイトの両方のノード（db1-prodおよびdb2-prod）は、同期するためにgalera3に再参加する必要があります。かなり大きなgcacheがあると、WANを介したSSTのリスクを減らすのに役立ちます。このアーキテクチャは、セットアップと管理が簡単で、費用対効果が非常に高くなっています。
フェイルオーバーは手動です。管理者は単一ノードをプライマリコンポーネントとして昇格させる必要があるためです（bootstrapdb3-drまたはwsrep_provider_optionsパラメーターでsetpc.bootstrap=1を使用します。その間にダウンタイムが発生します。 。DRサイトは、すべての負荷を実行するために少数のノードで実行されるため（DRサイトは常に少数であるため）、パフォーマンスが問題になる可能性があります。に切り替えた後、より多くのノードでスケールアウトできる場合があります。 DRサイトですが、追加の負荷に注意してください。
Galera Clusterは、事実上同期しているため、ネットワークの影響を受けやすいことに注意してください。ガレラノードが特定のクラスター内にあるほど、レイテンシーが高くなり、ライトセットを配布および認証するための書き込み機能があります。また、接続が安定していない場合、クラスターのパーティション分割が簡単に発生し、ジョイナーノードでクラスターの同期がトリガーされる可能性があります。場合によっては、これによりクラスターが不安定になる可能性があります。これには、このブログ投稿「Percona XtraDBクラスターのハイブリッドインフラストラクチャ環境の展開」に示されているように、Galeraパラメーターを少し調整する必要があります。
Galera Clusterは、さまざまな方法で展開できる優れたテクノロジーです。1つのクラスターが複数のサイトにまたがっており、複数のクラスターが非同期レプリケーションを介して同期されている、同期レプリケーションと非同期レプリケーションの混合などです。実際のソリューションは、WAN遅延、最終的なデータと強力なデータの一貫性、予算などの要因によって決まります。