マスターがオフラインになった場合、マスターMySQL DBをスレーブDBの変更とどのように再同期しますか？

MySQLサーバー1はマスターとして実行されています。
MySQLサーバー2はスレーブとして実行されています。

両方のDBがオンラインの場合、「完全に同期」しています。スレーブがオフラインになった場合でも、マスターがオンラインのままであれば問題はありません。スレーブが再びオンラインになると、同期が戻ります。

サーバー構成に加えて、マスターがオフラインになった場合、スレーブDBの接続を（JSPコードで）リダイレクトしました（もちろん、/ etc / init.d / mysqld stopでテストしました）。

マスターがオンラインに戻ったときに、マスターとスレーブの更新を自動的に同期する方法はありますか？

その性質の何かを引き出すための1つの良い方法は、マスターマスターレプリケーションまたは循環レプリケーションを設定することです。これをMultiMaster Replciationと混同しないでください。

マスター/スレーブレプリケーションを設定していれば、循環レプリケーションの設定は非常に簡単です。これを構成するために必要な作業は次のとおりです。

この例では、マスタースレーブレプリケーションがアクティブであると想定しますが、少しのダウンタイム（1〜2分）が発生します。

ステップ1）この行をマスターの/etc/my.cnfに追加します。

log-slave-updates

ステップ2）スレーブの/etc/my.cnfに次の行を追加します。

log-bin = mysql-bin（またはこのためにマスターが持っているものは何でも）log-slave-updates

警告：ここにダウンタイムの短い瞬間があります!!!

ステップ3）スレーブで、mysqlを再起動します。

これにより、スレーブのバイナリログがアクティブになります

ステップ4）マスターで、mysqlを停止します。

ステップ5）rsyncを使用して、スレーブの/ var / lib / mysqlフォルダーをマスターにコピーします。

警告：ダウンタイムの長い瞬間です!!!

ステップ6）スレーブで、mysqlを停止します

手順7）スレーブで、最後のバイナリログを確認します

ステップ8）スレーブで、最後のバイナリログのファイルサイズを確認します

ステップ9）rsyncを使用して、スレーブの/ var / lib / mysqlフォルダーをマスターにコピーします。これはより高速なコピーになるはずです。

ステップ10）マスターで、
master.infoの行2をスレーブの最後のバイナリログで編集します。
master.infoの3行目。スレーブの最後のバイナリログのファイルサイズ。
master.infoの4行目、スレーブのIP。
5行目はレプリケーションユーザーのユーザーIDです（DO NOT TOUCH）
6行目はレプリケーションユーザーのパスワードです（DO NOT TOUCH）

手順11）マスターのすべてのバイナリログとバイナリログインデックスファイルを削除します。

ステップ12）スレーブで、mysqlのサービスを開始し、15秒待ちます

ステップ13）マスターで、mysql startサービス

ステップ14）マスターで、STOP SLAVEを実行します。マスターステータスを表示;

ステップ15）スレーブでCHANGE MASTER TO MASTER_HOST = 'IP of Slave'、MASTER_USER = 'userid of replication user from Step10'、MASTER_PASSWORD = 'password of replication user from Step10'、MASTER_LOG_FILE = 'binary log from Step14'、 MASTER_LOG_POS = Step14のLogPos。

ステップ16）スレーブで、START SLAVEを実行します。

ステップ17）マスターで、START SLAVEを実行します。

私が回答した別のStackExchange質問に対しても、同様の手順を実行しました。

試してみる ！！！

MySQLが提供する非同期レプリケーションではありません。「箱から出してすぐ」のMySQLレプリケーション（5.5より前）がそれ自体では高可用性ソリューションではないということの典型的な釘を打っただけです。半同期レプリケーション（http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html）を備えた5.5を使用すると、状況は少し改善されますが、マスターが待機するため、トランザクション時間が遅くなります。奴隷からのACK。

マスターがダウンしたときにデータが失われる可能性を受け入れることができない場合は、単純なマスター/スレーブよりも洗練されたセットアップが適切だと思います。

マスターからマスターへのレプリケーションは、MySQLで有名な多くの人々の利益よりも問題が多いと考えられています（MySQL ABでさえ、高可用性ソリューションとして推奨されなくなりました）。したがって、ブロックレベルのコピーを使用してアクティブマスターとパッシブスレーブの同期を保つためにDRBDセットアップを使用することが、ここで実際に必要なことだと思います。

IMHO、まず第一に、非マルチマスター（マスター/スレーブ）構成では、スレーブは書き込みを行わないでください。スレーブmy.cnfを構成し、サーバーを次のように起動する必要があります。

# Flag to not take writes from network
read-only

次に、誤って書き込みを行っている書き込み可能なスレーブと同期していないマスターの問題を解決するには、両方のホストのデータを比較する必要があります。キーの衝突がない場合は、以前のスレーブホストをマスターに昇格させ、古いマスターを新しいマスターから複製するスレーブホストとして再イメージ化する必要があります。（ここにデータの問題がある可能性があります）

最後に、この停止/ダウンタイムのシナリオが今後も発生する可能性がある場合は、時間をかけて両方のホストをマルチマスター（ログビン、サーバーID、オフセットなど）として設定してください。これは、停止とダウンタイムをある程度軽減するのに役立ちます。

master / slaveを実行する必要がある場合は、ACLとアプリケーションで読み取りと書き込みのユーザー接続を分離することで、少なくともいくつかのボーナスポイントを獲得します。