コーソルDatabaseエンジニアのブログ
技術ブログ
渡部です。Dbvisit 9の有償オプションDbvisit Standby Snapshot Optionが日本で正式リリースされました! Snapshot Optionを使うと、スタンバイDBをレポート生成やアプリケーションのテストなどの用途に活用しやすくなります。
コーソルでは、Dbvisit Standbyの販売および設計、導入、製品サポートを行っています。Dbvisit Standbyをご検討の際はぜひコーソルにお声がけください。
Dbvisit Standby Snapshot Optionを使うと、以下のことが可能になります。
スタンバイDBと、スタンバイDBのスナップショットは独立した別個のデータベースです。 スタンバイDBのスナップショットに対して変更を加えても、スタンバイDBにその変更は波及しません。
また、スタンバイDBのスナップショットの利用中、スタンバイDBは通常のスタンバイ動作を継続します。 すなわち、ログ同期(ログ転送+適用)を継続します。スタンバイDBは、プライマリDBの変更に追従し、プライマリDBの安全なスペアという役割を担い続けます。
Dbvisit Standby Snapshot Optionには、以下の2つの機能があります。
メカニズムや考え方がシンプルで理解しやすいのは、シングルスナップショットです。 スタンバイDBのコピーを1つ作成し、スタンバイDBとは全く別個の独立したデータベースとして、自由に活用する機能です。必要になったら作成し、不要になったら適宜削除します。
スナップショットグループは、シングルスナップショットを作成および削除を定期化/自動化した位置づけです。定期的にスナップショットを作成することで、準リアルタイム的にプライマリDBの変更に追従することを狙っています。
の2つの項目が用意されており、対応する機能の制御が可能です。
シングルSnapshotsの動作イメージは以下の通りです。
上記で説明した、Dbvisit Standby Snapshot Optionの特性がそのままあてはまります。
Snapshotグループは、Active Data Guardのリアルタイム問合せモード(スタンバイDBにREDO適用しつつ、スタンバイDBを読取り専用モードでオープンできる)を意識して作られた機能のようです。
Active Data Guardのリアルタイム問合せモードの狙いは、プライマリDBへの追従とスタンバイDBのOPENを両立することと言えます。
Snapshotグループは、少し異なる仕組みで、この狙いを達成しようとしています。 Dbvisitが基礎とする技術である基本スタンバイでは、REDO適用中のスタンバイDBをOPENすることはできません。このため、若干力業的ですが、一定間隔でREDO適用中のスタンバイDBを複製することで、準リアルタイム的(=一定間隔毎にスタンバイDBが新しくなる)にプライマリDBに追従する動作を実現しています。
Snapshotグループは、シングルスナップショットを作成および削除を定期化/自動化した位置づけです。定期的にスナップショットを作成することで、準リアルタイム的にプライマリDBの変更に追従することを狙っています。
ただ、単に、1つのスナップショットを作成→削除するだけだと、スナップショットを利用できない時間帯ができてしまいます。よって、Snapshotグループでは、複数のスナップショットをグループ化して、循環的にスナップショットを作成することで、この問題に対処しています。
Snapshotグループ作成時に、グループに含まれるスナップショットの個数を指定します。1~4のスナップショット数を指定できます。
Snapshotグループの動作イメージは以下の通りです。(スナップショット数=2の場合)
Dbvisit Standby Snapshot OptionはLinux LVMのスナップショットをベースに実装されています。
このため、2020年6月時点でDbvisit Standby Snapshot OptionはLinux限定リリースです。 Windowsでは、Dbvisit Standby Snapshot Optionを使用できません。
以下の領域にDbvisit Standby Snapshot Optionを活用できると考えています。
コーソルでは、Dbvisit Standbyの販売および設計、導入、製品サポートを行っています。Dbvisit Standbyをご検討の際はぜひコーソルにお声がけください。