MariaDBサーバーは、非同期および同期レプリケーションを提供します。マルチソースレプリケーションまたはマルチマスターセットアップを使用するように設定できます。
読み取りと書き込みを多用するアプリケーションの場合、マスタースレーブのセットアップは一般的ですが、高可用性データベース環境を構築するために必要な基盤となるスタックによって異なる場合があります。
マスター/スレーブレプリケーションのセットアップがあると、特に実稼働環境ではニーズを満たさない場合があります。 MariaDBサーバーだけでは（マスタースレーブセットアップ）、単一障害点（SPOF）がまだあるため、高可用性を提供するには不十分です。
MariaDBは、この高可用性の問題に対処するためにエンタープライズ製品（MariaDBプラットフォーム）を導入しました。エンタープライズバージョンのMariaDB、MariaDB ColumnStore、MaxScale、軽量のMariaDBコネクタなどのさまざまなコンポーネントが含まれています。同じエンタープライズソリューションを提供している他のベンダーと比較すると、費用対効果の高いオプションになる可能性がありますが、すべての人がこのレベルの複雑さを必要としているわけではありません。
このブログでは、可用性の高い環境でレプリケーションを使用してMariaDBサーバーを使用する方法を紹介します。また、すべての無料ツールまたはコスト効率の高い管理ソフトウェアを使用して実行することもできます。 MariaDBサーバーインフラストラクチャを監視します。
MariaDB高可用性トポロジのセットアップ
MariaDBサーバーを使用したマスター/スレーブトポロジの通常のセットアップでは、1つのマスターが書き込みを受信する非同期または同期アプローチを使用し、次の図のように変更をスレーブに複製します。
ただし、これも高可用性を提供せず、単一障害点。マスターが停止すると、アプリケーションクライアントは機能しなくなります。ここで、スタックに追加して、SPOFを回避する自動フェイルオーバーメカニズムを持たせる必要があります。また、読み取り/書き込みを分割するための負荷分散とラウンドロビン方式も提供します。したがって、今のところ、トポロジのタイプを使用することになります。
現在、このトポロジはSPOFの観点からより安全に機能します。 MaxScaleは、マスターからスレーブに対してデータベースノードの読み取りと書き込みの分割を行います。 MaxScaleは、このタイプのセットアップを処理するときに完璧なアプローチを実行します。 MaxScaleには自動検出機能も組み込まれています。したがって、データベースノードの状態に変更が発生しても、それに応じて検出して動作します。 MaxScaleには、フェイルオーバーまたはスイッチオーバーを続行するための可用性があります。そのフェイルオーバーメカニズムの詳細については、MariaDBMaxScaleフェイルオーバーのメカニズムに取り組んでいる以前のブログをお読みください。
MariaDBMonitorを使用したMaxScaleフェイルオーバーメカニズムにも制限があることに注意してください。これは、過度に複雑なセットアップのないマスタースレーブセットアップにのみ適用するのが最適です。これは、マスターマスターセットアップがサポートされていないことを意味します。ただし、MaxScaleにはさらに多くの機能があります。読み取り/書き込み分割を実行するときに負荷分散を行うだけでなく、クエリを最もパフォーマンスの高いノードに送信するSmartRouterが組み込まれています。これは高可用性の機能を追加しませんが、ノードがトラフィックでスタックするのを防ぎ、タイムアウトを引き起こす可能性のある特定のデータベースノードのパフォーマンス低下や、進行中のリソース集約型のアクティビティによって完全に利用できないサーバーを回避するのに役立ちます。
MaxScaleを使用する際の注意点の1つは、BSL（Business Source LIcense）を使用していることです。このソフトウェアを採用する前に、FAQを確認する必要がある場合があります。
選択できるもう1つのオプションは、より便利なアプローチを使用することです。 ClusterControlを使用して選択し、HaProxy、MaxScale、またはProxySQLを使用してプロキシを中間に配置すると、コスト効率が高くなる可能性があります。後者は、軽量からクエリルーティングを行うより本番レベルの構成に構成できます。クエリフィルタリング、ファイアウォール、またはセキュリティ。下の図を参照してください：
今、それらの上に座っているのはClusterControlです。 ClusterControlは、高可用性、つまりCMONHAでセットアップされます。または、プロキシレイヤーは、HaProxy（前述のように非常に軽量なオプション）、または高スケールに理想的な柔軟性と構成が必要な場合は、より洗練されたパラメーターのセットを持つProxySQLのいずれかから選択できます。プロダクションセットアップ。 ClusterControlは、ノード、特にフェイルオーバーが必要かどうかを判断するためのメインノードであるマスターのヘルスステータスの観点から自動検出を処理します。現在、これはより自給自足である可能性がありますが、このセットアップを実装するために必要なノードの数と、アドバンスライセンスおよびエンタープライズライセンスに適用されるClusterControl自動フェイルオーバーを使用するため、より多くのコストが追加されます。しかし一方で、データベースインフラストラクチャに対するすべての安全性、セキュリティ、および可観測性を提供します。実際には、グローバル市場で利用可能なソリューションと比較して、より低コストのエンタープライズ実装です。
MariaDBの既存のマスタースレーブセットアップがあると仮定しましょう。この例では、無料でインストールして使用できる無料のコミュニティエディションを使用してClusterControlを使用します。それはあなたの仕事を簡単かつ迅速にセットアップすることを可能にするだけです。これを行うには、既存のMariaDBレプリケーションクラスターをインポートする必要があります。 ClusterControlを使用してMariaDBを管理する方法については、以前のブログをご覧ください。このブログでは、以下に示すように、最初はMariaDBレプリケーションクラスターとして次の設定を行っています。
ここで、MariaDBプラットフォームの代替ソリューションとしてMaxScaleを使用しましょう。高可用性を提供します。これを行うには、数回クリックするだけでClusterControlを非常に簡単に使用できます。その後、既存のMariaDBレプリケーションクラスター上で実行されるMaxScaleをセットアップできます。これを行うには、[管理]→[ロードバランサー]→[MaxScale]に移動するだけで、以下に示すように適切な値を設定して提供できます。
次に、チェックボックスオプションを有効にするかクリックして、サーバーを選択します。 MaxScaleモニタリングの一部として追加されました。以下を参照してください
追加するMaxScaleノードが複数あると仮定して、繰り返します。同じ手順。
最後に、必要なときにMaxScaleノードを常に使用できるようにKeepalivedを設定します。これは、ClusterControlを使用した簡単な手順で非常にすばやく実行できます。ここでも、[管理]→[ロードバランサー]に移動する必要がありますが、代わりに[キープアライブ]を選択します
お気づきのとおり、キープアライブをMaxScaleと一緒に配置しましたスレーブの同じノード（192.168.10.30）。一方、2番目（2番目）のKeepalivedは、同じホスト上のMaxscaleとともに192.168.10.40で実行されています。
トポロジの結果、本番環境に対応し、クエリルーティング、高可用性、およびClusterControlを使用した広範な監視と監視機能を備えた自動フェイルオーバーを提供できます。以下を参照してください
MariaDBサーバーレプリケーションを単独で使用しても、高可用性は提供されません。サードパーティのツールを拡張して使用すると、MariaDB製品に依存するだけでなく、MariaDBプラットフォームを使用することで、データベーススタックの可用性を高めることができます。
これを達成し、より費用対効果の高い方法で管理する方法があります。それでも、ClusterControlなどの市場で入手可能なこれらのソリューションを利用することには大きな違いがあります。これは、スピード、煩わしさの軽減、そしてもちろん、健康だけでなくリアルタイムで最新のイベントによる究極の可観測性を提供するためです。データベースクラスタで発生するイベントも含まれます。