MySQL にはレプリケーション機能が付いています。非常に多くの導入事例があり、mixi のような大規模サイトでも使われています。単に、マスタ・スレーブの関係だけではなく、マルチマスタの構成も可能です。

...そんなことはもう知ってる、と言われるかもしれません。嬉しいのか悲しいのかわかりませんが、MySQL は Sun の社員よりも社外のかたの方が詳しいこともあります; ではレプリケーションは同期処理なのか非同期処理なのかご存知でしょうか？「レプリケーション」という言葉のイメージから想像できるかもしれませんが答えは「非同期」です。
詳しい説明は「MySQL 5.1 リファレンスマニュアル 5.5.1. レプリケーション実装の詳細」に記載されていますが、改めて絵でご紹介すると次のようになります。

1. MySQL サーバのマスタに書き込みが行われると、マスタは更新情報を バイナリ ログ (binlog) に書き込みます。 2. スレーブでは I/O スレッドが作成され、マスタに接続要求を投げます。 3. マスタはバイナリログを送信するためにスレッドを作成してスレーブに送信します。 4. スレーブはマスタから受信した情報をリレーログと呼ばれるローカルファイルに書き込みます。(絵の中では「中継 binlog」と表記) 5. 続いてスレーブは SQL スレッドを起動して、リレーログのクエリを実行します。

しかし、この方式ではマスタが関与するのは binlog に書き込む所までで、それ以降は知ったこっちゃない、ということになってしまいます。つまり、スレーブが更新情報を取得する前にマスタがダウンするとデータの不整合が起こります。これを解消しようという試みが次のメージャーバージョン 6.0 で追加されます。それが、 半同期レプリケーション (Semisynchronous Replication) です。既に「MySQL 6.0 Reference Manual 16.2.9. Semisynchronous Replication」にその仕組みが記載されています。

If semisynchronous replication is enabled on the master side and there is at least one semisynchronous slave, a thread that performs a transaction commit on the master blocks after the commit is done and waits until at least one semisynchronous slave acknowledges that it has received all events for the transaction, or until a timeout occurs.

マスタは少なくとも１つのスレーブがトランザクションのすべてのイベントを受信するか、もしくはタイムアウトする仕組みだそうです。