MHAフェイルオーバー検証時のログより、大体こんなことをやっているんだろうなと思ったことのメモ
- Phase 1: Configuration Check Phase..
- Phase 2: Dead Master Shutdown Phase..
- Phase 3: Master Recovery Phase..
- Phase 3.1: Getting Latest Slaves Phase..
- Phase 3.2: Saving Dead Master's Binlog Phase..
- Phase 3.3: Determining New Master Phase..
- Phase 3.3: New Master Diff Log Generation Phase..
- Phase 3.4: Master Log Apply Phase..
- Phase 4: Slaves Recovery Phase..
- Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..
- Phase 4.2: Starting Parallel Slave Log Apply Phase..
- Phase 5: New master cleanup phase..
Phase 1: Configuration Check Phase..
- MHA設定ファイルで定義されている、Slaveがbinlogを出力しているか確認
Phase 2: Dead Master Shutdown Phase..
- 障害が発生しているMasterを強制的にShutdown
- 多分mysqlプロセスを強制的に停止しているのではないかと
- 障害が発生しているMasterIPを利用不要に
- VIPの取り外し
Phase 3: Master Recovery Phase..
Phase 3.1: Getting Latest Slaves Phase..
- 全Slaveの適用されているMasterのログポジションを確認
*「SHOW SLAVE STATUS」の結果とか
Phase 3.2: Saving Dead Master's Binlog Phase..
- 障害が発生しているMasterの現在のbinlogを退避
Phase 3.3: Determining New Master Phase..
- 全Slaveの中からフェイルオーバー先を判定
- MHA設定ファイルの定義より判定
Phase 3.3: New Master Diff Log Generation Phase..
- Phase 3.2で退避したbinlogと、新Masterのリレーログの差分を生成
Phase 3.4: Master Log Apply Phase..
- Phase 3.3で生成した差分を新Masterに適用
- MasterIPを新Masterに付与
- VIPの取り外し
Phase 4: Slaves Recovery Phase..
Phase 4.1: Starting Parallel Slave Diff Log Generation Phase..
- Phase 3.2で退避したbinlogと、各Slaveのリレーログの差分を生成
Phase 4.2: Starting Parallel Slave Log Apply Phase..
- Phase 4.1で生成した差分を新Masterに適用
- 各SlaveのMaster参照先を新Masterに変更
*「CHANGE MASTER」実行
Phase 5: New master cleanup phase..
- 新MasterのSlave情報を削除
*「RESET SLAVE ALL」実行