物理的に多様な場所での自動フェイルオーバーを備えた高可用性MySQLのアーキテクチャ

私は、データセンター間のMySQLの高可用性（HA）ソリューションを研究しています。

同じ物理環境にあるサーバーの場合、アクティブパッシブアプローチを使用するハートビート（フローティングVIP）を備えたデュアルマスターを優先しました。ハートビートは、シリアル接続とイーサネット接続の両方で行われます。

最終的に、私の目標はこの同じレベルの可用性をデータセンター間で維持することです。手動の介入なしで両方のデータセンター間で動的にフェールオーバーし、データの整合性を維持したい

上部にBGPがあります。両方の場所にあるWebクラスター。これにより、両側のデータベースにルーティングされる可能性があります。サイト1でインターネット接続がダウンした場合、クライアントはサイト2を介してWebクラスターにルーティングし、両方のサイト間のリンクがまだアップしている場合はサイト1のデータベースにルーティングします。

このシナリオでは、物理リンク（シリアル）がないため、スプリットブレインが発生する可能性が高くなります。WANが両方のサイト間でダウンした場合、VIPは最終的に両方のサイトで終了し、さまざまな不快なシナリオが非同期を引き起こす可能性があります。

私が見る別の潜在的な問題は、将来このインフラストラクチャを3番目のデータセンターに拡張するのが難しいことです。

ネットワーク層は焦点ではありません。この段階では、アーキテクチャは柔軟です。繰り返しになりますが、私の焦点は、データの整合性とMySQLデータベースの自動フェイルオーバーを維持するためのソリューションです。私はおそらくこれを中心に残りを設計するでしょう。

物理的に異なる2つのサイト間でMySQL HAの実績のあるソリューションを推奨できますか？

これを読んでくれてありがとう。あなたの提案を読むのを楽しみにしています。

「CAP」定理の問題に直面します。一貫性、可用性、パーティション耐性を同時に持つことはできません。

DRBD / MySQL HAは、ブロックデバイスレベルでの同期レプリケーションに依存しています。これは、両方のノードが使用可能である場合、または一時的な障害が発生した場合、リブートされた場合など、正常に戻ります。問題は、ネットワークパーティションを取得するときに始まります。

ネットワークパーティションは、2つのデータセンターで実行している場合に非常に多く発生します。基本的に、どちらのパーティも、障害の発生した他のノードとパーティションを区別できません。セカンダリノードは、引き継ぐべきか（プライマリに障害が発生したか）わからない（リンクが失われたか）を知りません。

マシンが同じ場所にある間に、この問題を回避するために通信のセカンダリチャネル（通常はシリアルケーブルまたはクロスオーバーイーサネット）を追加できます。そのため、セカンダリはプライマリが完全にダウンし、ネットワークパーティションではないことを認識します。

次の問題はパフォーマンスです。マシンに低遅延接続がある場合（例：ギガビットイーサネット-一部の人々は専用の高速ネットワークを使用している場合）、DRBDはまともなパフォーマンスを提供しますが、ネットワークの遅延が大きいほど、トランザクションのコミットに時間がかかります*** 。これは、書き込みの耐久性を確保するために、アプリに「OK」と言う前に、セカンダリサーバー（オンラインの場合）がすべての書き込みを確認するのを待つ必要があるためです。

異なるデータセンターでこれを行うと、たとえ近くにある場合でも、通常はさらに数ミリ秒の遅延が発生します。

**まともなローカルIOコントローラーよりもはるかに遅い

*** MyISAMは、フェールオーバー中に必要な不審なシャットダウンから適切に/自動的に回復しないため、高可用性DRBDシステムには使用できません。

VLANを使用して2つ（またはそれ以上）のデータセンターにあるすべてのサーバーを結び付けることはどうですか。その後、自動フェールオーバーにCARPを使用できます。データベースのレプリケーションを使用して、すべての同期を維持します。

データセンターを所有している場合、各データセンターに複数のWANアップリンクがあることを確認できます。

最初の段階は、現在のHAソリューションをOpenAISをクラスターメンバーシップレイヤーとして使用するものにアップグレードすることです。これにより、柔軟性が大幅に向上し、サイト間の低遅延リンクが提供される可能性があります。PaceMakerとRHEL Clusteringはこれをサポートしています。

データセンターの自動フェールオーバーでは、タイブレーカーとして機能する3番目のサイトが本当に必要です。そうしないと、サイト間でのルーティングの問題とリモートサイトの障害を区別できなくなります。Microsoftには、この分野をカバーする驚くほど優れたWebキャストがいくつかあります。

Windows Server 2008マルチサイトクラスタリング

明らかに、正確な技術はLinuxドメインにマッピングされませんが、概念は同じです。

申し訳ありませんが、これはさらに別のネットワークですが、将来的には...

あなたが言及したスプリットブレインのシナリオでは、このような可能性を減らすために、2つのサイトへの冗長リンクを設定することもできます。

最小のルーティング可能なブロックは4k（/ 22）であるため、おそらくBGPを使用できないことに注意してください。おそらくDNSベースのソリューションが必要です。

持っているデータの量、これに適合させたいサーバーの量などによっては、正しい答えを出すのは難しいかもしれません。

MySQLを使用した複数サイトの実証済みのソリューションはありません。しかし、有効な解決策があります。一部の人が指摘したように、はい、DRDBは正常に機能しますが、セットアップによって制限または問題が発生する可能性があります。

3番目のサイト（別のデータセンター）が必要になりますか？もしそうなら、どれくらいの時間とお金をこれをしなければなりませんか？

マスター/スレーブ/ dnsサーバー、バックアップを追加するたびに...管理するサーバーを追加することを考慮し、サーバーの数の観点からあなたの管理能力はどれくらいですか？この番号を定義できる場合は、いくつかの可能な解決策を捨てて、管理がボトルネックにならないように、自分の番号に合うものに向かって作業する必要があります。

データセンターが頻繁にダウンしないことを考慮すると、複数のサイトは負荷分散といくつかのDNSハッキングを意味しますが、これは同じデータセンターにあるのでしょうか？その場合、何らかの理由で1つのデータセンターがダウンすると、DNSと負荷分散の大部分がこのデータセンターに存在するため、問題が発生します。

そのため、あなたはそのスプリットブレインの状況を計画する必要があるかもしれません。考えられるセットアップごとに、唾を吐く脳の状況を解決する方法は異なります。また、各ソリューションにはX時間かかります。
また、最初から3つのデータセンターの使用を計画する方がはるかに簡単な場合があります。私はMySQLの専門家ではありませんが、実稼働環境で問題が発生した場合、2つよりも3つのマスターを持っている方が簡単だと聞いています。

Zeusのようなネットワークベンダーが提供するロードバランシングサービスが役立つ場合があります。こちらをご覧ください。私はそれが価格で来ると確信していますが、時にはあなたはいくつかの他のものを削減することができます。

がんばろう！

DRBDは、データベースとレプリケーションの速度に影響を与える可能性のある帯域幅を必要とするため、リモートデータセンターの推奨ソリューションではありません。推奨されるソリューションは、マスター-マスター複製です。これに関する唯一の問題は、フィールドを自動インクリメントする必要があることです。

MySQLに真のHAソリューションが必要な場合、DRBDは障害発生時にデータの整合性を提供できないため、MySQL Clusterを使用する必要があります。

MySQLで利用可能なオプションとその長所と短所に関するブログ記事を見つけました。 http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

シリアルケーブルの欠如を克服するのは実際には非常に簡単です。暗黒時代のモデムと呼ばれるものを使用します。両端に1つずつあり、PPPリンクでハートビートを実行します。フレームリレーを使用することもできます。どちらの方法でも、レイヤー1/2の冗長パスに関する心配はすべて修正されます。

ただし、それは言われています-約300µs（0.3msに相当）を超える遅延でDRBDが実行されているリンクは、非常に急速にばかげています。

標準のMySQLレプリケーションと、PPP＆ethを介したLinuxHAを使用してフェールオーバーを行うことで、より良いサービスを提供できます。

少なくともそれは私が過去にクライアントのためにしたことです。