マスター-マスターレプリケーションのリカバリ戦略

マスター/マスターレプリケーションに基づいてMySQLのHAソリューションを実装しました。フロントエンド部分には、一度に1つのdbのみが読み書きされることを保証するメカニズムがあります（つまり、HAのレプリケーションのみを使用します）。

レプリケーションが期待どおりに機能することを確認しましたが、障害のシナリオと回復について疑問に思っています。特に、一方のマスターが回復不可能な状態で失敗し、もう一方のマスターから再作成する必要がある場合にどうなるかについて心配しています。

• 他のマスターはライブで使用されている可能性が高いため、ロックしてダンプを作成することはできませんmysqldump（データベースは適度に大きく、mysqldump数か月使用すると数時間かかることがあります）。
• ダンプがあると仮定しても、データベースがロックされた後に実行されるダンプにSHOW MASTER STATUSで示されるbinlogの位置が対応していることが重要です。

最初の問題の簡単な解決策は、バックアップとして機能する3番目のデータベースを使用することですmysqldump。しかし、どのようにして、再作成されたマスターが一貫した方法で実行中のマスターからレプリケーションを開始できることを確認できますか？

私が認識しているこの問題への2つの基本的なアプローチがあります。まず、Myisamの代わりにInnoDBを実行している場合は、トランザクションでバックアップを実行できます（--single-transaction --lock-tables = FALSE）。 --master-dataは、レプリケーションの位置情報を含む一貫したバックアップを提供します。ログをフラッシュすると、ダンプが作成される前にログがリセットされます。つまり、位置は常に106になり、-master-dataはログファイルの名前と位置をダンプファイルに書き込みます。もちろん、-master-dataを機能させるには、これをマスター上で実行する必要があります。

あなたが述べた2番目の方法は、3番目のホストを使用してバックアップを作成することです。この場合、レプリケーションを停止し、DBが読み取り専用であることを確認してください（ただし、レプリケーションからの書き込みには影響しないため、すべてのレプリカは読み取り専用にする必要があります）。次に、バックアップを作成し、レプリケーションの位置を記録します。この場合、-master-dataは使用できません。代わりに、次のようなことをするかもしれません：

echo 'stop slave' | mysql {options)
mysqldump {your options} > DB.sql
echo 'show slave status\G' > DB.replication
echo 'start slave' | mysql {options)

このバックアップから復元する必要がある場合は、復元を実行してから、レプリケーションをセットアップし、2つのパラメーターmaster_log_fileとmaster_log_posがDB.replicationファイルから取得されるようにします。

master_log_file = value of Master_Log_File
master_log_pos = value of Exec_Master_Log_Pos

注：別のレプリカからテストすることもできます。

追加の注記：レプリカのプールがある場合（たとえば、Webアプリの読み取りと書き込みを分離した場合）、レプリカが新しいマスターと同期していない可能性があります。これは、レプリカが非同期にストリーミングし、フェイルオーバー時にスタンバイが他のレプリカと同じ位置にあるという保証がないため、書き込みI / Oの負荷が高いときにフェイルオーバーが発生した場合に発生する可能性があります。しかし、これはまだ私には起こりません...