想定課題としては、 ・今までのDBでは、PITRを利用し、データの冗長性を確保していた。そのためマスター障害発生時に切り替え時間がかかっていたのを自動化して短縮したい ・障害発生時のデータロストを最小にする 上記を解決するために今回の変更を実施します。 冗長構成の仕組み 障害発生後は、まず新Slaveを設定して、Replicationを再開させます。その後故障機を修理or交換・原因調査をして、ColdStandby設定を施します。 再びDB2が故障した場合は、DB3がマスターになって、DB1をStandbyに設定することでぐるぐる回っていきます。 この構成の利点は、フェールバック作業が不要なので、停止メンテナンスが要らないことです。 故障したサーバもゆっくり対応・修理が出来、詳細な原因追及やナレッジを作成する余裕ができます。サーバ一台余裕を持つコストより運用負担軽減とサービス向上のメリット