Data Guardとその目的
Oracle DatabaseにはプライマリDBからスタンバイDBへRedoを転送・適用してスタンバイDBを維持するData Guardという仕組みがあります。Active Data GuardではスタンバイDBを読み取り専用でオープンすることができます。
Data Guardは主に災害対策のためプライマリDBから地理的に離れた場所にスタンバイDBを用意しRedoを転送・適用することで事業継続性を高めることを目的として使用されます。
Data Guard構成においてプライマリDBとスタンバイDBのロールを切り替える操作をスイッチオーバー、プライマリDBを切り離しスタンバイDBをプライマリDBに昇格させる操作をフェイルオーバーといいます。
DB3台でData Guard構成となっている場合についてどのような挙動になるのか調査しました。
今回考える構成
プライマリリージョンに本番DB、検証DB、スタンバイリージョンに災対DBがあり、本番DBをプライマリDBとして検証DBと災対DBはスタンバイDBというActive Data Guard構成を考えます。検証に使うときはフィジカルスタンバイからスナップショットスタンバイDBに変換します。
スイッチオーバー
スイッチオーバーをして災対DBをプライマリDBに昇格させることを考えます。この時、旧プライマリDBである本番DBはスタンバイDBとなります。また検証DBはスタンバイDBのままですがRedoの転送元が新プライマリDBである災対DBになります。
フェイルオーバー
フェイルオーバーをして災対DBをプライマリに昇格し、旧プライマリDBを切り離すことを考えます。このとき本番DBはDisabled StandbyとなりActive Data Guard構成から切り離され、Redoの転送もされなくなります。検証DBは可能であれば災対DBからRedo転送を受けるような形になります。検証DBが新プライマリに対してviableであれば、災対DBからRedoを受けるスタンバイとして継続しますがviableでなければdisabledとなり、reinstateまたは再作成が必要になります。
Disabled StandbyとなったDBはreinstateコマンドでスタンバイDBとして復帰させることができます。ただし、常に成功するとは限らず障害内容によっては再作成が必要となります。
https://docs.oracle.com/en/cloud/paas/base-database/dg-reinstate/#articletitle
まとめ
今回はActive Data Guard構成の3台のDBについてスイッチオーバーとフェイルオーバーの際の挙動を調査しました。
スイッチオーバー、フェイルオーバーのときの挙動を図示することで理解が深まりました。特にフェイルオーバーの際に旧プライマリDBはDisabled Standbyになること、そこから復帰させることができることを知ることができました。