こんにちは！インサイトテクノロジーの松尾です。

本記事では、Oracle Database SE の DR ソリューションである Dbvisit StandbyMP のトライアル(test drive)環境を使い、実際に災害発生時にDBが切り替わる様子を体験してみます。環境の用意から実際に試すまで30分程度で無料で試せますので、データベースの DR 製品を検討中の方、理解したい方、ぜひ体験してみてください。

はじめに：Oracle Database の DR 対策とは

データベースの DR (Disaster Recovery, ディザスタリカバリ, 災対対策) は、万一の災害やトラブルに備えて本番環境データベース(プライマリ)のコピーを物理的に離れた場所に保持(スタンバイ)しておき、災害などが発生した時にデータベースを切り替えて使用できるようにしておく仕組みです。Oracle Database Enterprise Edition では Data Guard という機能を利用することで構成することができます。Standard Edition では Dbvisit StandbyMP などのサードパーティソフトウェアで構成します。DR ソフトウェアを使うことで、障害が発生して本番環境が使用できなくなった場合などに、自動でスタンバイ環境に切り替えることなどが可能になります。

参考)

DR ソフトウェアを体験してみよう！

本記事では、Oracle Database Standard Edition 向けに提供されている DR ソフトウェア Dbvisit StandbyMP の試用環境 (Test drive) を使用し、セットアップから、スイッチオーバー (プライマリとスタンバイの切り替え) やフェイルオーバー (障害発生時のスタンバイへの自動切換え) を実際に体験してみます。

参考)

Test drive の申し込みと起動

ではさっそく Test drive をはじめましょう。以下の Test drive ページにアクセスすると、以下の画面が表示されます。

入力は名前とメールアドレスのみです。早速入力してみましょう。

Test drive の構築が始まります。2分間程度で終わるので、その間、製品紹介動画でも見ていましょう♪構築が終わると、アクセスに必要な情報等が表示されます。

「START HERE」のところに記載のある「CONTROL CENTER HOMEPAGE」に記載されている URL へアクセスすると、ログイン画面が表示されます。

ログイン画面で、同じく「START HERE」のところに記載のあるユーザー名とパスワードを使ってログインします。

ログイン後、左のメニューの「SETTING」から、言語を日本語に変更することができます。変更すると、再度ログイン画面に戻り、日本語のログイン画面が表示されます。

DR の構成と操作

では早速 Oracle Database を登録していきます。「Oracleから始める」をクリックします。クリックすると、登録済み(DbvisitのAgentプログラムがインストール済み)のデータベースを選択する画面が出てきます。

「oracle1～」と記載のあるデータベースを選択します。ソースデータベースには「SRC」を選択します。続いて、スタンバイ側のデータベースを選択するところで「oracle2～」と記載のあるデータベースを選択します。

一番下にライセンスキーの入力個所があるので、Test drive 構成後に表示された画面の「CONFIGURATION LICENSES」の ORACLE の方の値を入力して、「構成の作成」をクリックします。ダッシュボードに Oracle の DR 構成が登録されます。

この段階では DR 構成が登録されているのみなので、「今すぐ設定しますか？」をクリックし、確認画面で「Standby Database の作成」をクリックし、スタンバイ DB を作成します。

スタンバイ DB 作成中のステータスは、ダッシュボード画面に表示されます。

また、右側の「Standby Database の構築」をクリックすると、詳細なステータスを確認することもできます。

スタンバイ DB が作成できると、ダッシュボード上のスタンバイ DB が「リカバリ」となります。

さて、Oracle Database はどういう状態になっているでしょうか？

ssh で Oracle Database がセットアップされているマシンにログインしてみます。oracle1、oracle2 でそれぞれ見てみましょう。なお ssh ログインに必要な情報は、デプロイ後に表示される情報に含まれています。

oracle@localhost[/home/oracle]: sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Aug 4 04:59:39 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

SQL> select host_name, instance_name, status from v$instance;

HOST_NAME
----------------------------------------------------------------
INSTANCE_NAME    STATUS
---------------- ------------
oracle1
SRC              OPEN


SQL> select name, open_mode, database_role from v$database;

NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
SRC       READ WRITE           PRIMARY

oracle@localhost[/home/oracle]: . oraenv
ORACLE_SID = [oracle] ? SRC
The Oracle base has been set to /u01/app/oracle
oracle@localhost[/home/oracle]: sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Fri Aug 4 05:02:22 2023
Version 19.3.0.0.0

Copyright (c) 1982, 2019, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0

SQL> select host_name, instance_name, status from v$instance;

HOST_NAME
----------------------------------------------------------------
INSTANCE_NAME    STATUS
---------------- ------------
oracle2
SRC              MOUNTED


SQL> select name, open_mode, database_role from v$database;

NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
SRC       MOUNTED              PHYSICAL STANDBY

oracle2 の方が PHYSICAL STANDBY になっていることがわかりますね。実際にテーブルに対するクエリ実行などは行うことができません。

スイッチオーバー

スイッチオーバーとは、双方のデータベースが稼働状態にある状態で、プライマリとスタンバイを切り替える作業です。

スイッチオーバーを実行するには、ダッシュボードにある対象の構成で「処理」をクリックします。右側に表示されるメニューから「スイッチオーバー」を選択します。

確認画面が出るので、そこからスイッチオーバーを実行します。

ダッシュボード画面を見ると、データベースが入れ替わっていることがわかります。

さて、データベースの状態はどうなっているでしょう？再度 oracle2 へ ssh でログインして確認してみましょう。

SQL> select host_name, instance_name, status from v$instance;

HOST_NAME
----------------------------------------------------------------
INSTANCE_NAME    STATUS
---------------- ------------
oracle2
SRC              OPEN


SQL> select name, open_mode, database_role from v$database;

NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
SRC       READ WRITE           PRIMARY

すると、DATABASE_ROLE が PRIMARY に変わっていることもわかります。もちろん実際にクエリなども実行可能です。
また、oracle1 はもちろんですが PHYSICAL STANDBY に変わっています。

SQL> select host_name, instance_name, status from v$instance;

HOST_NAME
----------------------------------------------------------------
INSTANCE_NAME    STATUS
---------------- ------------
oracle1
SRC              MOUNTED


SQL> select name, open_mode, database_role from v$database;

NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
SRC       MOUNTED              PHYSICAL STANDBY

自動フェイルオーバー

さて、次は自動フェイルオーバーを試してみます。自動フェイルオーバーはプライマリで障害が発生した際に、自動でスタンバイ側をプライマリに変更する機能です。

まず、Dbvisit StandbyMP ではデフォルトでは自動フェイルオーバーが設定されていないので、まず自動フェイルオーバーの設定を行います。

「緊急時のアクション」で「自動フェイルオーバーを実行する」を選択して設定を保存します。

さて、では自動フェイルオーバーを試してみましょう。

早速、プライマリデータベースを終了して使えない状態にします。ssh で oracle2 (今はスイッチオーバー実行後のため oracle2 がプライマリ) にログインし、sqlplus で接続後にデータベースを終了します。

SQL> shutdown abort;
ORACLE instance shut down.

データベースを終了した後少し待つと、プライマリに障害があることが検知されます。

3回チェックに失敗すると、自動でフェイルオーバーが開始されます。

ダッシュボードを確認すると、oracle1がオンライン状態となっていることがわかります。

再度 oracle1 へ ssh でログインして確認してみると、oracle1 の DB が PRIMARY となり使用可能状態となっています。

SQL> select host_name, instance_name, status from v$instance;

HOST_NAME
----------------------------------------------------------------
INSTANCE_NAME    STATUS
---------------- ------------
oracle1
SRC              OPEN

SQL> select name, open_mode, database_role from v$database;

NAME      OPEN_MODE            DATABASE_ROLE
--------- -------------------- ----------------
SRC       READ WRITE           PRIMARY

参考

おわりに

Dbvisit StandbyMP を用いて、Oracle Database のスイッチオーバー (DR 環境との切り替え操作) や、自動フェイルオーバー (プライマリ環境がダウンしたときの自動切り替え) を体験してみました。

Dbvisit StandbyMP はここで紹介した Oracle Database 以外に SQL Server と PostgreSQL をサポートしています。以下のページもご参考になればと思います。

このようなソフトを使わない場合に、災害発生時にバックアップから復旧させるなどの作業を行うのは、かなりしっかりとした手順を構築しておかないと骨の折れる作業だと思います。繰り返しになりますが、障害が発生して本番環境が使用できなくなった場合など多くの環境に対して対応しなければならいことを想像してみてください。DR 製品を活用し、災害発生時にも事業継続できるよう備えておきましょう。