私の組織は、バックアップを最新の状態に保ち、理想的には負荷を分散しながら、サーバーを地理的に分散する方法を検討してきました。
私が最初に念頭に置いているのは、Rails on MySQLです。書き込み速度はあまり高くありません（記事/コメントは1分あたり1未満で残っていますが、大きなメディアが添付されているものもあります）。
そう、
回答:
いくつかのヨーロッパ諸国のデータセンター間でレプリケーションを使用しているため（相互に世界中にあるわけではありませんが、ローカルではありません）、問題なく機能します。
可能な場合、レプリケーションは自動的に再起動します。クエリに問題がある場合（たとえば、データベースがスレーブではなくマスターに存在し、クエリがそれを使用する場合）、デフォルトで手動修正が必要になります（ただし、このようなエラーを無視するように設定できます）。データベースが完全なミラーである場合、レプリケーションを手動で再起動する必要はありません。
2つのサーバーがあり、マスターが消えた場合、スレーブを「マスター」に変更するには、レプリケーションを停止してコードを変更します（新しい「マスター」に書き込むため）。3つ以上のサーバーがあり、マスターが表示されなくなった場合は、スレーブでレプリケーションを停止し、新しいマスターを使用するようにスレーブを変更して、再起動します。それらが正確に同期していない場合（転送されるデータの量、サーバーのビジー状態、ネットワーク接続の状態などによって異なります）、それ以上の作業が必要になる場合があります。 これについては、MySQLのドキュメントの複製セクションで詳しく説明しています。
SSL経由でレプリケートしていることを確認することをお勧めします（つまり、SSL接続を要求するようにレプリケーションユーザーを設定します）。
MySQL 5.1ではレプリケーションが劇的に変わりました。5.0では、ステートメントベースのレプリケーションのみが使用されました。行ベースのレプリケーションまたは混合ベースのレプリケーションを実行するオプションがあります。これは、WANを介した複製方法に大きく影響します。
A）IPが引き継ぐ場合（サーバーが地理的に離れている場合、これは起こりそうにない）B）俊敏なDNS変更を行うマスターを変更するためのアプリコード/構成の変更を回避できます。短いキャッシュと偽の.internalドメインで内部DNSを使用します。masterdb.internalを他のサーバーに変更する必要がある場合、5秒で変更が反映されます。
単一のデータセンター内では、IPテイクオーバーを使用します。すべてのDBサーバーには、起動時にifupされない仮想インターフェース（eth0：1、eth0：2、eth0：3）があります。スレーブの1つが引き継ぐ必要がある場合は、eth0：2をifupし、それがマスターになります。このシナリオでは、eth0はシェルなどに使用する「if」です。アプリはeth0：1に接続しますが、スクリプトがIPの取得を検出した場合、起動時にアクティブになりません。（wikipedia STONITH）他のifsは、フェイルオーバーが必要な可能性のあるマスターのIPを引き継ぐためのものです。