地理的に離れたサーバー間でのMySQLレプリケーション
私の組織は、バックアップを最新の状態に保ち、理想的には負荷を分散させながら、サーバーを地理的に分散させる方法を検討してきました。
私が最初に頭に浮かぶのはRailsです。書き込み速度はそれほど高くありません（記事/コメントは1分あたり1未満のままですが、大きなメディア添付ファイルがあるものもあります）。
そう、
- mySQLレプリケーションはワイドエリアネットワーク全体でうまく機能しますか？
- 接続（またはスレーブサーバー）がダウンしているということは、手動による介入が必要であることを意味しますか（2つのサーバーが再び通信できるようになると）、それとも回復は自動的に行われますか？
- マスターが消えた場合、スレーブをマスターに変えるには何が必要ですか？それを管理するのに役立つ標準のスクリプト/ツールはありますか？
- 他の落とし穴などはありますか？
私たちはヨーロッパのいくつかの国のデータセンター間でレプリケーションを使用しており（したがって、それらは互いに世界中にありませんが、確かにローカルではありません）、問題なく機能します。
可能であれば、レプリケーションは自動的に再開されます。クエリに問題がある場合（たとえば、データベースがスレーブではなくマスターに存在し、クエリがそれを使用する場合）、デフォルトで手動で修正する必要があります（ただし、このようなエラーを無視するように設定できます）。データベースが完全ミラーである場合は、レプリケーションを手動で再開する必要はありません。
2つのサーバーがあり、マスターが消えた場合、スレーブを「マスター」に変えるには、レプリケーションを停止してコードを変更します（新しい「マスター」に書き込むため）。サーバーが3つ以上あり、マスターが消えた場合は、スレーブでのレプリケーションを停止し、新しいマスターを使用するようにスレーブを変更して、再開します。それらが正確に同期していない場合（転送されるデータの量、サーバーのビジー状態、ネットワーク接続の状態などによって異なります）、それ以上の作業が必要になる場合があります。 MySQLドキュメントのレプリケーションセクションでこれについて詳しく説明しています 。
SSLを介して複製していることを確認することをお勧めします（つまり、SSL接続を要求するように複製ユーザーを設定します）。
MySQL5.1ではレプリケーションが劇的に変更されました。 5.0では、ステートメントベースのレプリケーションのみが使用されていました。行ベースのレプリケーションまたは混合ベースのレプリケーションを実行するオプションがあります。これは、WANを介した複製方法に大きく影響します。
次のいずれかの機能がある場合：A）IPテイクオーバーを実行します（サーバーが地理的に離れている場合、これは起こりそうにありません）B）アジャイルDNS変更を行うアプリコード/構成を変更してマスターを変更することを回避できます。短いキャッシュと偽の.internalドメインを持つ内部DNSを使用します。 masterdb.internalを他のサーバーに変更する必要がある場合は、5秒で変更が反映されます。
単一のデータセンター内で、IPテイクオーバーを使用します。すべてのDBサーバーには、起動時に起動されない仮想インターフェイス（eth0：1、eth0：2、eth0：3）があります。スレーブの1つが引き継ぐ必要がある場合は、eth0：2をifupするだけで、それがマスターになります。このシナリオでは、eth0はシェルインなどに使用する「if」です。アプリはeth0：1で接続しますが、スクリプトがIPの取得を検出した場合、起動時にアクティブ化されません。 （wikipedia STONITH）他のifは、フェイルオーバーが必要な可能性のあるマスターのIPを引き継ぐためのものです。
MySQLレプリケーションを使用する場合、海を渡ることはお勧めしません。スレーブがテキサスにいる間に、ヨーロッパのマスターから複製しようとしたことがあります。このプロジェクトを放棄するまで、複製はほぼ毎日壊れていました。もちろん動作しますが、マスターとスレーブの間の距離が大きいほど、より脆弱になる傾向があります。