2 つのサーバー間の接続は安定しているので、スプリット ブレインについては心配していません (3 台目のマシンも持っていないため)
自動フェイルオーバー機能を備えた MariaDB レプリケーションを導入し、1 つのデータベースが停止しても引き続き動作するようにしたいと考えています。MaxScale は見たことがありますが、マシンが 2 台しかないため、サーバーの 1 つと同じマシンで実行する必要があり、そのサーバーが停止すると何も動作しなくなります。私の知る限り、MariaDB Galera クラスターでは、2 台のみで実行して自動フェイルオーバーを実行することはできません (クォーラムが必要)。ただし、別のマシンでアービトレーターを実行したり、別のデータベースを実行したりすることはできるかもしれませんが、速度は遅くなります。
さらに、バックエンドは PHP です。mysqli の設定などを変更するつもりですが、何を変更する必要があるのか、また変更する必要があるのかはわかりません。
編集: 自動フェイルオーバーは省略しても構いませんが、その場合に必要な動作は次のようになります。
サーバー A に接続すると、データベース A (マスター) に接続され、正常に読み取り/書き込みが行われます。
Serer B に接続すると、データベース B (読み取り専用スレーブ) に接続され、正常に読み取りが行われます。書き込みが必要な場合は書き込みは可能ですが、データベース A にプッシュされます。
両方のサーバーで MaxScale などを使用すると、これは可能でしょうか?
答え1
ノードが 2 つあります。いかなる種類のマスター マスターも使用しないでください。2 つのノードでスプリット ブレインが発生する可能性が非常に高くなります (最終的にはほぼ確実に発生します)。
この種のステートフル アプリケーションは、2 ノード クラスターの展開を単独でうまく処理することは期待できません。障害発生時にクラスターを堅牢にするには、オペレーターの介入または CRM のいずれかが必要になります。これが、そもそもクラスター化される理由です。
2ノードのクラスタがあります。このアーキテクチャはスプリットブレイン状態になりやすいため、スプリットブレインについて絶対に心配する必要があります。ノード間のネットワークリンクが現在安定しているからといって、常に安定しているとは限りません。これは、2ノードクラスタにおけるリスクの最大の要素の1つです。このリンクを失うと、次の場合を除き、クラスタは即座にスプリットブレインになります。フェンシングまたは定足数ノード間で確立されます。これは、2 ノード クラスターにおける最大の考慮事項の 1 つです。フェンシングにより、スプリット ブレイン状態が発生する可能性が、高いレベルからほぼゼロにまで低下します。
これを Pacemaker/Corosync で処理することをお勧めします。これは複雑なスタックですが、2 つのノードで実稼働レベルのクラスターを生成するために必要なメカニズムを提供します。また、このようなクラスター マネージャーの強制下にある場合でも、マルチマスターではなく、一度に 1 つのマスター インスタンスのみを使用することをお勧めします。
HA MariaDB の優れたガイドがあり、出発点として役立ちます。フェンシングの使用については説明されていません。フェンシングを実現できない場合、Corosync には、投票デーモンを実行する小さなアービトレータ ノードを使用して、アプリケーションのオーバーヘッド コストなしでクォーラムによる全体的な実装を提供する機能もあります (Corosync qdevice の情報を参照してください)。
サブスクリプションの壁の背後にあるが、一度に 1 つのノードで実行し、ノード間でブロック ストレージを複製するアクティブ/パッシブ MySQL クラスタを構成するためのエンドツーエンドのガイド
Pacemaker の高度なリソース タイプは、リソースを線形依存関係チェーンにグループ化する機能や、ノード間でアプリケーションの複数のインスタンスを実行するためのマルチステート リーダー選出セマンティクスを表現する機能により、フェイルオーバーを適切にオーケストレーションする方法に関するほとんどの質問に対応します。それはここにあります。
バンドルは、Docker や RKT などのコンテナ ランタイムを介して Pacemaker でアプリケーションの分離を実現する方法です。これにより、バンドル自体がクラスターに対して Pacemaker ノードとして表示されるため、他のアプリケーションとは独立してクラスターによって「フェンス」できるため、フェンシングの別の手段が開かれます。それはここにあります。
答え2
私は、「問題は気にしない、実行できるのは 2 つのノードだけだ」という同じ哲学で、さまざまな DB (Mongo、Elasticsearch、SQL Server など) を実行しました。
それは本当に苦痛でした。
マスタースレーブで実行する場合は問題ありません。しかし、頭痛の種になります。
何年もこの問題を回避し、2 つのノードのみにこだわったために生じたさまざまな DevOps の頭痛の種に対処した後 (データベースが非常に大きく、3 番目のノードのコストが重大だったため、2 つのノードのみにこだわった)、ついに 3 つのノードを実行し始めました。
そして、すべては良くなりました。
長年のダンスから私が得た教訓は、選択肢は 2 つあるということです。
- ウォームっぽいスペアを備えた単一ノード（例：マスタースレーブ）
- 3つのノード
私の経験から言うと、2 つのノードをアクティブ/アクティブで実行することは二度とないでしょう (私が見たことがある、非常に醜いスプリット ブレインを完全に防止する魔法のピースがない限り)。
さまざまなスタック上で複数の 0.5～1.5 TB データベースを 5 年間実行した結果です。
答え3
1 つのオプションは、keepalived を使用して非同期マスター間レプリケーションを実行し、フローティング IP をフェイルオーバーすることです。これは優れた方法ではありませんが、完全なサーバー障害のシナリオをカバーできます。
ILO または、1 台のマシンから他のマシンの電源を強制的にオフにするその他の方法 (STONITH) はありますか? これは、部分的な障害 (たとえば、マシンがクラッシュしたが完全にはクラッシュしておらず、ハートビート パケットに応答できる程度には稼働しているが、それ以外は動作していない) を防ぐために必要です。これにより、フェイルオーバーが、必要なときに発生しない可能性があります。