回答:
MySQLプロキシを実際に使用する前に、この質問に対する他の回答を読んでください。CMSが書き込みを行う2つのマスターマスターサーバーがあり、CMSから読み取るだけの10のhttpdがある場合は問題ありませんが、（他の回答で指摘されているように）常にそうとは限りません。あなたは警告されました。
MySQL Proxyは、クライアントとMySQLサーバーの間にあり、それらの通信を監視、分析、または変換できる単純なプログラムです。その柔軟性により、無制限に使用できます。一般的なものには次のものがあります。フェイルオーバー。クエリ分析; クエリのフィルタリングと変更; などなど。
。
HAProxyは無料で、非常に高速で信頼性の高いソリューションであり、TCPおよびHTTPベースのアプリケーションに高可用性、負荷分散、プロキシを提供します
TCPモードで実行する場合は、Wackamoleよりも優れている可能性があります。どちらかを選択する必要がある場合は、HAProxyを使用します。また、HAProxyは多くのバックエンドを持つことができ、Waclamoleは2つしか持てません。HAProxyは「ダム」であることに注意してください。これは、ストリームの内部を見ることなくソケットを接続します。 。
おそらく言及する価値があります。真のマルチマスターMySQLセットアップ用のGalera Replication for MySQLです。Galeraは同期レプリケーションプロトコルであるため、アプリケーションは任意のMySQLサーバーに対して読み取りおよび書き込みを行うことができます。ここに簡単なチュートリアルがあります：http : //www.severalnines.com/clustercontrol-mysql-galera-tutorial
MySQLサーバーの前にあるロードバランサーについては、この機能をサポートするMySQLコネクターを使用します（Javaの場合はConnector / J、phpの場合はMysqlnd）。
これを実行できるコネクタがない場合は、HAプロキシなどを使用します。このスクリプトは、HAプロキシを自動的にセットアップし、適切なMySQLサーバーのリストを維持します。https： //github.com/severalnines/haproxy
宜しくお願いします、
ビナイ
www.severalnines.com
マスターマスターレプリケーションは、思ったほど良くありません。ラウンドロビンプロキシや同様の「簡単な」ソリューションについても同様です。衝突するデータを別々のサーバーに十分な速度でコミットすると（サーバー間の遅延よりも速く、実動サーバーでは最大1秒になる可能性があります*）、両方がデータを受け入れます。オークションサーバーを所有している場合、同じ車を2回販売しただけです。誰が買ったの？どのDBを使用するかによって異なります。
アプリケーションは、実際には2つのデータベースがあり、両方のIPアドレスを知っている必要があることを認識する必要があります。「売りたい」なら、
DB_number = `auction_number` % `number_of_databases`（%はmodulo）
...そして、それをDB_numberデータベースにコミットします。接続エラーが発生した場合は、おそらく他のエラーを使用してください（ただし、オークションサーバーの場合は、エラーを表示します）。
また、IPアドレスは両方のサーバー間でwackamole -dにする必要があります。1つのデータベースサーバーがピークの使用時間で数時間ダウンするという災害シナリオでは、アプリケーションが不在のサーバーに接続しようとし、タイムアウト（たとえば3秒）までハングすることがわかります。突然、クエリの半分が3秒長く実行されます（最終的にはすべて同じデータベースに移動するため、災害前よりも高速に実行されません）。おそらく同時リクエストハンドラスレッドの接続プールが限られているため、これはあなたのhttpdを幸せにしません...
* 本番サーバーでのレプリケーションの遅延は最大 1 秒になる可能性があります -私はこれをリモートコロケーションとデータセンターでテストしましたが、99％の時間はゼロですが、mysqlが1を示す場合があります。大規模なトラフィックでは、クライアントアプリケーションが2つのリクエストを作成し、結果として挿入と選択の2つのクエリが発生するため、多くの衝突が発生しました。一部のケースでは、行がまだ存在しなかったため、userIDのハッシュを使用して問題を修正しました
私の過ちから学んでほしいと思います;-)
負荷分散されたMySQL（またはその他の）データベースクラスターはかなり無駄です。複数のサーバーに書き込んでいる場合、問題が発生するか、同期レプリケーション（MySQLはいずれにしてもサポートしていません）を使用します。これにより、ロックを同期する必要があるため、パフォーマンスが著しく低下します。
読み取り/書き込みの負荷を分割し、mysqlスレーブ間で読み取りの負荷を分散し、書き込み用に単一のマスターを使用するか、マスターにアクティブ/パッシブフェイルオーバーペアを使用することをお勧めします。
基本的に、それぞれがアプリケーションの書き込み負荷全体を書き込む必要があるため、より多くのサーバーをスレーブとしてデータベースに配置して書き込みをスケーリングすることはできません。
書き込みをスケーリングするには、パーティション化または「シャーディング」などにより、データを複数のサーバーに論理的に分割する必要があります。これには通常、アプリケーションに重要な（テストするのは非常に難しいと思われる）変更が必要なので、本当にそうしない限り、これを実行したくないでしょう。それが必要。
もちろん、必要に応じてMySQLクラスタを使用することもできますが、それは独自の機能と欠点を備えた完全に異なるエンジンです-セットアップは少し複雑ですが、実際に市販のハードウェアでHA負荷分散データベースを提供します。同期レプリケーションを使用すると書き込みパフォーマンスのペナルティが発生しますが、サーバー間のパーティション分割が組み込まれているため、書き込みをスケーリングできます。
私が見つけたこの主題に関する別の素晴らしいガイド...
http://www.dancryer.com/2010/01/mysql-circular-replication
これは、3つの投稿シリーズのパート1です。
MySQL負荷分散クラスタガイド–パート1-サーバー自体のセットアップとMySQLレプリケーションの構成。
MySQL負荷分散クラスターガイド–パート2-次のガイドでプロキシを設定するために使用するMySQLクラスターノードのステータスを監視するスクリプトを設定します。
MySQL負荷分散クラスターガイド–パート3-監視スクリプトを使用して、HAProxyでロードバランサーを設定する
Connector / Jには、複数のサーバー間でクエリを負荷分散する機能があります。これは主に、すべてのSQLノードがデータの一貫したビューを持つMySQL NDBクラスターを対象としていますが、2つのマスターデータベースがこれらの2つのマスター間で合理的に一貫していることを確認できれば、アプリケーションにとって安全かもしれません。
接続文字列は次のようになります。
jdbc：mysql：loadbalance：// host-1、host-2、... host-n / dbname？loadBalanceStrategy = "random"＆loadBalanceBlacklistTimeout = 5000
書き込みをレプリケートする必要があるため、書き込みを分割してもサーバーの負荷はかかりません。
2つのサーバーのみを使用している場合、drbdでハートビートを使用し、drbdにレプリケーションを処理させます。最初のサーバーに障害が発生すると、2番目のサーバーが引き継ぎます。2番目のサーバーを使用する場合は、gfsをdrbdで使用して、2番目のサーバーを読み取り専用として実行し、読み取りサーバーとして使用できます。フェイルオーバーが発生したら、サーバーを読み取り/書き込みに変更します。
re：wackamole-wackamoleは2台のサーバーに限定されない
これをカバーするチュートリアルシリーズを作成していますが、設定は非常に簡単です。
MySQLのバージョン5.6でこの質問に対するより最近の回答を提供するために、非同期レプリケーションをより堅牢にし、MySQLを再びHA（高可用性）の競争に参加させることを目的とするGTID（グローバルトランザクション識別子）を導入しました。
このセクションでは、グローバルトランザクション識別子（GTID）を使用したトランザクションベースのレプリケーションについて説明します。GTIDを使用する場合、元のサーバーでコミットされ、スレーブによって適用されるときに、各トランザクションを識別および追跡できます。つまり、GTIDを使用して、新しいスレーブを起動したり、新しいマスターにフェイルオーバーしたりするときに、ログファイルまたはそれらのファイル内の位置を参照する必要がないため、これらのタスクが大幅に簡略化されます。GTIDベースのレプリケーションは完全にトランザクションベースであるため、マスターとスレーブが一貫しているかどうかを判断するのは簡単です。マスターでコミットされたすべてのトランザクションがスレーブでもコミットされている限り、2つのトランザクション間の整合性が保証されます。GTIDではステートメントベースまたは行ベースのレプリケーションを使用できます（セクション16.2.1「レプリケーション形式」を参照）。ただし、最良の結果を得るには、
参照：16.1.3グローバルトランザクション識別子を使用したレプリケーション（MySQLドキュメント）
HAProxyを使用してクエリの負荷を分散するとSPOF（Single Point Of Failure）が発生し、ハートビートを追加するとこのソリューションが煩雑になると思いました。
より簡単な解決策は、すべてのMySQLノードでjdbc urlを介してクエリの負荷分散を目的とするJavaコネクタJConnectorを介して接続することです。マスター/スレーブまたはマスター/マスターのセットアップを処理できます。
これにより、MySQLでそのままHAクラスターソリューションをセットアップできます。