物理的に異なる場所での自動フェイルオーバーを備えた高可用性MySQLのアーキテクチャ
データセンター間のMySQLの高可用性（HA）ソリューションを研究しています。
同じ物理環境にあるサーバーの場合は、アクティブパッシブアプローチを使用したハートビート（フローティングVIP）を備えたデュアルマスターを優先しました。ハートビートは、シリアル接続とイーサネット接続の両方を経由します。
最終的に、私の目標は、これと同じレベルの可用性をデータセンター間で維持することです。手作業による介入なしに、両方のデータセンター間で動的にフェイルオーバーし、データの整合性を維持したい.
上にBGPがあります。両方の場所にあるWebクラスター。これにより、両側のデータベースにルーティングされる可能性があります。サイト1でインターネット接続がダウンした場合、クライアントはサイト2を経由してWebクラスターにルーティングされ、両方のサイト間のリンクがまだアップしている場合はサイト1のデータベースにルーティングされます。
このシナリオでは、物理リンク（シリアル）がないため、スプリットブレインが発生する可能性が高くなります。 WANが両方のサイト間でダウンした場合、VIPは両方のサイトで終了し、さまざまな不愉快なシナリオが同期解除を引き起こす可能性があります。
私が目にするもう1つの潜在的な問題は、将来的にこのインフラストラクチャを3番目のデータセンターに拡張するのが難しいことです。
ネットワーク層は焦点ではありません。この段階では、アーキテクチャは柔軟です。繰り返しますが、私の焦点は、MySQLデータベースでのデータの整合性と自動フェイルオーバーを維持するためのソリューションです。残りはこのあたりで設計するでしょう。
2つの物理的に異なるサイト間のMySQL HAの実績のあるソリューションを推奨できますか？
お読みいただき、ありがとうございました。私はあなたの推薦を読むのを楽しみにしています。
「CAP」の定理問題に直面します。一貫性、可用性、パーティション許容度を同時に確保することはできません。
DRBD/MySQL HAは、ブロックデバイスレベルでの同期レプリケーションに依存しています。これは、両方のノードが利用可能である間、または1つが一時的な障害に遭遇した場合、再起動などで問題ありませんが、その後戻ってきます。ネットワークパーティションを取得すると、問題が発生します。
2つのデータセンターで実行している場合、ネットワークパーティションが発生する可能性が非常に高くなります。基本的に、どちらのパーティも、障害が発生している他のノードとパーティションを区別できません。セカンダリノードは、引き継ぐべきか（プライマリが失敗した）かどうか（リンクがなくなった）を認識していません。
マシンが同じ場所にあるときに、通信のセカンダリチャネル（通常はシリアルケーブルまたはクロスオーバーイーサネット）を追加して、この問題を回避できます。これにより、セカンダリがプライマリが完全にダウンしていることを認識し、ネットワークパーティションではありません。 。
次の問題はパフォーマンスです。 DRBDは、マシンに低遅延接続（ギガビットイーサネット-ただし、専用の高速ネットワークを使用している人もいる）の場合、まともな**パフォーマンスを提供できますが、ネットワークの遅延が大きいほど、トランザクションのコミットに時間がかかります*** 。これは、書き込みの耐久性を確保するために、アプリに「OK」と言う前に、セカンダリサーバー（オンラインのとき）がすべての書き込みを確認するのを待つ必要があるためです。
異なるデータセンターでこれを行うと、近くにある場合でも、通常は数ミリ秒のレイテンシがあります。
**それでもまともなローカルよりもはるかに遅いIOコントローラ
***フェイルオーバー中に必要となるクリーンでないシャットダウンから適切に/自動的に回復しないため、高可用性DRBDシステムにMyISAMを使用することはできません。
最初の段階は、現在のHAソリューションをクラスターメンバーシップレイヤーとしてOpenAISを使用するHAソリューションにアップグレードすることです。これにより、柔軟性が大幅に向上し、サイト間の低レイテンシリンクを使用すると、全体に到達できる可能性があります。 PaceMakerとRHELクラスタリングはこれをサポートしています。
データセンターの自動フェイルオーバーの場合、タイブレーカーとして機能する3番目のサイトが本当に必要です。そうしないと、サイトはサイト間のルーティングの問題とリモートサイトの障害を区別できなくなります。 Microsoftはこの領域をカバーする驚くほど優れたWebキャストをいくつか持っています。
Windows Server 2008マルチサイトクラスタリング
明らかに、正確なテクノロジーはLinuxドメインにマッピングされていませんが、概念は同じです。
VLANを使用して、2つ（またはそれ以上）のデータセンターのすべてのサーバーを結合します。その後、CARPを使用して自動フェイルオーバーを実行できます。データベースレプリケーションを使用してすべての同期を維持します。
データセンターを所有している場合は、各データセンターに複数のWANアップリンクがあることを確認できます。
申し訳ありませんが、これは別のネットワークですが、今後の検討事項...
前述のスプリットブレインシナリオでは、2つのサイト間のリンクを冗長化して、これが発生する可能性を減らすこともできます。
MySQLとその長所と短所で利用可能なオプションに関するブログ投稿を見つけました。 http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html
シリアルケーブルの欠如を克服することは実際には本当に簡単です。暗黒時代のモデムと呼ばれるものを使用します-両端に1つずつあり、PPPリンク上でハートビートを実行します。また、フレームリレーを使用します。どちらの方法でも、layer1/2冗長パスに関する問題が解決されます。
ただし、言われていること-約300µs（0.3msに注意）をはるかに超える待ち時間でリンク上で実行されるDRBDは、とんでもなくばかばかしくなります。
標準のMySQLレプリケーションと、フェイルオーバーを実行するためのLinuxHA PPP＆eth）を使用するほうがよいでしょう。
少なくともそれは私が過去にクライアントのためにやったことです。
最小のルーティング可能なブロックは4kであり、/ 22でそれを取得できるので、BGPはおそらく使用できないことに注意してください。おそらくDNSベースのソリューションが必要です。
あなたが持っているデータの量、これを入れたいサーバーの量などによっては、正しい答えを出すのは難しいかもしれません。
MySQLを使用する複数のサイトに対する実証済みのソリューションはありません。しかし、機能する解決策があります。一部の人が指摘したように、はい、DRDBは正常に動作しますが、設定によっては制限または問題が発生する可能性があります。
3番目のサイト（別のデータセンター）が必要ですか？もしそうなら、あなたはこれをどのくらいの時間とお金でする必要がありますか？
マスター/スレーブ/ dnsサーバー、バックアップなどを追加するたびに、自分で管理するサーバーを追加するとします。サーバー数の観点から、管理能力はどれくらいですか。この数値を定義できる場合は、考えられる解決策をいくつか捨てて、管理者がボトルネックにならないように、数値に適合する解決策に取り組む必要があるかもしれません。
データセンターが頻繁にダウンしないことを考えると、複数のサイトはロードバランシングと一部のDNSハッキングを意味しますが、これは同じデータセンターにあるのでしょうか？その場合、何らかの理由で1つのデータセンターがダウンすると、DNSと負荷分散の大部分がこのデータセンターにあるため、問題が発生します。
したがって、そのスプリットブレイン状況を計画する必要があるかもしれません。可能なセットアップごとに、唾液の脳の状況を解決する方法は異なります。また、各ソリューションにはX時間かかります。
最初から3つのデータセンターの使用を計画する方がはるかに簡単な場合もあります。私はMySQLの専門家ではありませんが、問題が発生した場合、本番環境では2つよりも3つマスターの方が簡単であると聞きました。
Zeusのような一部のネットワーキングベンダーが提供する負荷分散サービスが役立つかもしれません。 ここ この種類のサービスを提供しているサービスは他にもたくさんあるでしょう。私はそれが価格で来ると確信していますが、時々あなたは他のいくつかのものを減らすことができます。
幸運を！
DRBDは、データベースとレプリケーションの速度に影響を与える可能性のある帯域幅を必要とするため、リモートデータセンターには推奨されないソリューションです。推奨されるソリューションは、マスター-マスターレプリケーションです。これに関する唯一の問題は、フィールドを自動インクリメントする必要があることです。
MySQLに真のHAソリューションが必要な場合、障害発生時にDRBDがデータの整合性を提供できないため、MySQL Clusterを使用する必要があります。