ドイツのプロバイダーから大規模なデータ障害が発生したため、フェイルオーバー シナリオに対処せざるを得なくなりました。しかし、実際に答えが見つからない質問がいくつかあります。誰か助けていただければ幸いです。
現在、server1 では、別々の Docker コンテナで 2 つの MySQL データベースを実行しています。これらは、2 番目のサーバーに複製される必要があります。server1 に障害が発生した場合は、ClusterIP を介して比較的迅速に server2 に切り替えることができます。
知っておくべき重要な点: データベースを使用するソフトウェアは、データベースに対して大量の書き込み操作を実行するスポーツ競技管理システムです (テストは行われていませんが、読み取り操作で書き込みは行われません)。
私にとっての疑問は次の通りです。
- どのレプリケーション方法が最も適していますか?
- 私の理解では、MASTER <-> MASTER が最も適切でしょう。しかし、問題が発生する可能性があることもここで何度も読みました。
- MASTER <-> SLAVE の場合、スレーブは読み取りのみ可能であるという疑問が生じます。マスターに障害が発生した場合はどうなりますか? スレーブは自動的にマスターになり、書き込みもできるようになりますか?
- それとも、クラスターが最善の解決策でしょうか? 現時点では、アクティブなノードは 1 つだけです。将来的には、米国に別の DB ノードが追加される可能性があります。ただし、現時点では存在しません。
すぐに機能するソリューションが必要であり、この一般的なトピックは非常に大きく、それほど簡単ではないと思われるため、どのようなご助力も本当にありがたく思います。
答え1
あなたは2つの問題を提起しています。
MySQL トポロジ順番に（OKからベストまで）
- プライマリ -> レプリカ - 「フェイルオーバー」は実現できますが、手作業が必要となり、時間がかかります。
- プライマリ <=> プライマリ - セットアップが少し複雑になりますが、他のサーバーを「即座に」使用できます。
- 少なくとも 3 台のサーバーのクラスター。これにより、フェイルオーバーがさらに自動化されます。「InnoDB CLuster」(MySQL 8) または「Galera」(MariaDB に付属) を参照してください。
地理 - データ センターでも障害が発生する可能性があることに注意してください。たとえば、フロリダ州のどのくらいの範囲が、1 回のハリケーンでオフラインになる可能性がありますか?
「スプリット ブレイン」シナリオに注意してください。これは、サーバーが 2 台しかなく、両方とも正常に動作しているが、ネットワークがダウンしている状況です。サーバーもユーザーも状況がわかりません。各サーバーが、自分だけが動作しているサーバーであると判断して書き込みを続行すると、混乱が生じます。そのため、代わりに、システム全体がダウンしていると想定する必要があります。
結論として、物理的に分離された少なくとも 3 台のサーバーが必要です。
プロキシ
問題は依然としてクライアントデータベース システムのどの部分がアクティブであるか (読み取りおよび/または書き込み) を知ること。「読み取り」のみが重要な場合は、任意の数のレプリカを持つ多くのトポロジで十分であり、「無制限」のスケーリングが提供されます。「書き込み」こそが真の課題です。
1 台のサーバーがダウンしていることを検知し、別のサーバーに再ルーティングするという「適切な処理」を実行するのが得意なサードパーティ製品がいくつかあります。それらを調べてください。
コーディング
障害が発生すると、コードに何らかのエラーが発生する可能性があります。エラーをチェックする必要があります。エラーの中には、自動的に修復されないものもあります。また、ほとんどのネットワーク エラーは、気づくまでに時間がかかります。