web-dev-qa-db-ja.com

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

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

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

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

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

mysqlmysql-replicationdisaster-recoverymaster-master
8
David Cournapeau

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

あなたが言及した2番目の方法は、3番目のホストを使用してバックアップを作成することです。この場合、レプリケーションを停止し、DBがread_onlyであることを確認して（実際には、レプリケーションからの書き込みには影響しないため、すべてのレプリカは読み取り専用である必要があります）、バックアップを作成してレプリケーション位置を記録する必要があります。この場合、-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の期間中にフェイルオーバーが発生した場合に発生する可能性があります。しかし、これは私にはまだ起こっていません...

2
grep