MySQL Clustering
約50Gbのデータ（主に約250のWebサイト）をホストするmysqlサーバーを実行していますが、冗長MySQLクラスターをセットアップするためのオプションは何ですか？主な目的は、データベースの可用性に影響を与えることなく、メンテナンスまたは再起動のために1つのサーバーを停止できることです。次に、ライブサーバーに問題が発生した場合に、何らかの種類のホットフェイルオーバーが発生することです。
私の理解では、mysql-clusterでは、DBが完全にメモリに含まれている必要があり、大量のデータが含まれているため、実用的なオプションではありません。
必要なのはレプリケーションです。多くの人がMySQLレプリケーションを使用していますが、私はそれを十分に扱っており（数十の大容量の本番MySQLインスタンス）、それが勝利の選択肢ではないことを知っています。それはかなり壊れやすく、不便な時に失敗します。現在、MySQLストアの整合性を保つためにDRBDなどのブロックレプリケーションソリューションを使用することに傾倒しています。
フェイルオーバーに関する限り、MySQLレプリケーションはこれを特にうまく処理しません。マスターからスレーブへのフェイルオーバーはかなり自動化可能な操作ですが、余波への対処（レプリケーションを別の方法で再度実行する）は常に手動プロセスであり、すべてが正しく機能することを確認するために突っついたり突っ込んだりする必要があります。どちらのレプリケーション方法を選択した場合でも、ハートビートを使用して、すべてが正常に機能しているかどうか、現在アクティブなサーバーがいつフォールオーバーしたかを検出し、リソースの正常な乗っ取りが行われるようにします。
DRBD/Heartbeatをしばらく使用していて、かなり良いですが、必要があるため、仮想サーバーの状況（私たちが持っている）には理想的ではありませんサーバー間に複数の接続があり、仮想環境では、すべての接続（シリアル、イーサネットなど）は基本的に同じワイヤーを介して伝送されるため、1回タイムアウトすると、すべての接続が常に実行されます。でる。 （実際のシリアルケーブルをそこに接続できることに気付きましたが、ホスト間でVMを移行できなくなりました。これはあきらめたくない機能です）
この状況では、どちらのサーバーも他方を認識できず、両方が同時に「プライマリ」になる場合があります（スプリットブレインと呼ばれる状況で、回復するのが頭痛の種です）
しかし、それは間違いなく、その前に使用していたbinlog Replicationよりも優れたソリューションです-そしてこれまでのコメントから、mysql-clusterよりも堅牢なソリューションのように聞こえます。
Mysql 5.1以降、mysqlクラスターデータ（インデックスではありません）をディスクに保存できます： MySQL 5.1の新機能
ただし、mysql-cluster/ndbの制限の多くとレプリケーションの脆弱性を考えると、汎用ソリューションのいずれかを検討することを躊躇するという疑問に同意します。よく理解された使用モデルと開発者と連携する実際のDBAを備えた単一のデータベースの場合はどうでしょうか。おそらく。ただし、多くの異なるアプリケーションをサポートする汎用データベースサーバークラスターには適していません。
代わりに、DRBDアプローチを使用するか、問題にお金を投じてSANを使用したいと思います。私が知っている解決策は完璧ではありません。