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

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

はじめに：SQL Server の DR 対策とは

データベースの DR (Disaster Recovery, ディザスタリカバリ, 災対対策) は、万一の災害やトラブルに備えて本番環境データベース(プライマリ)のコピーを物理的に離れた場所に保持(スタンバイ)しておき、災害などが発生した時にデータベースを切り替えて使用できるようにしておく仕組みです。SQL Server では Always On 可用性グループや、ログシッピングという機能を利用することで構成することもできます。一方で、導入やメンテナンスが容易かというと、使用されたことがある方であればわかると思いますが、簡単ではありません。DR ソフトウェアを使うことで、障害が発生して本番環境が使用できなくなった場合などに、自動でスタンバイ環境に切り替えることなどを容易に構成することができます。

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

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

Test drive の申し込みと起動

ではさっそく Test drive をはじめましょう。https://testdrive.dbvisit.com/ にアクセスすると、以下の画面が表示されます。

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

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

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

ログイン画面で、同じく「START HERE」のところに記載のあるユーザー名とパスワードを使ってログインします。ログイン後、左のメニューの「SETTING」から、言語を日本語に変更することができます。変更すると、再度ログイン画面に戻り、日本語のログイン画面が表示されます。

DR の構成と操作

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

「sql1～」と記載のあるデータベースを選択します。

認証タイプはここでは「SQL Server」を選択し、認証情報を入力します。

「Instance を発見」を選択しインスタンスを確認出来たら「確認 & Instance を追加」で追加します。

次に2つ目のDBサーバーを追加します。「sql2～」を選択します。

ソースからDBを選択し(ここではSQLTestDB)、スタンバイDBサーバーを選択し、一番下にライセンスキーの入力個所があるので、Test drive 構成後に表示された画面の「CONFIGURATION LICENSES」の SQL Server の方の値を入力して、「構成の作成」をクリックします。

ダッシュボードに SQL Server の DR 構成が登録されます。

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

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

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

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

dbvisit@sql1:~$ /opt/mssql-tools/bin/sqlcmd -U sa
Password:
1> select substring(name, 0, 16), state_desc from sys.databases;
2> go
                 state_desc
---------------- ------------------------------------------------------------
master           ONLINE
tempdb           ONLINE
model            ONLINE
msdb             ONLINE
SQLTestDB        ONLINE
SQLTestBigDB     ONLINE

(6 rows affected)

dbvisit@sql2:~$ /opt/mssql-tools/bin/sqlcmd -U sa
Password:
1> select substring(name, 0, 16), state_desc from sys.databases;
2> go
                 state_desc
---------------- ------------------------------------------------------------
master           ONLINE
tempdb           ONLINE
model            ONLINE
msdb             ONLINE
SQLTestDB        RESTORING

(5 rows affected)

sql2 の SQLTestDB 方が RESTORING になっていることがわかりますね。実際に sql1 では use SQLTestDB; などで接続できますが、sql2 では接続することはできません。

スイッチオーバー

スイッチオーバーとは、双方のデータベースが稼働状態にある状態で、プライマリとスタンバイを切り替える作業です。Dbvisit StandbyMP ではデータベースの種類によらず同じオペレーションでスイッチオーバーを行うことができます。

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

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

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

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

dbvisit@sql1:~$ /opt/mssql-tools/bin/sqlcmd -U sa
Password:
1> select substring(name, 0, 16), state_desc from sys.databases;
2> go
                 state_desc
---------------- ------------------------------------------------------------
master           ONLINE
tempdb           ONLINE
model            ONLINE
msdb             ONLINE
SQLTestDB        RESTORING
SQLTestBigDB     ONLINE

(6 rows affected)

1> select substring(name, 0, 16), state_desc from sys.databases;
2> go
                 state_desc
---------------- ------------------------------------------------------------
master           ONLINE
tempdb           ONLINE
model            ONLINE
msdb             ONLINE
SQLTestDB        ONLINE

(5 rows affected)

すると、state_desc が入れ変わっていることもわかります。sql2 に対してはデータベースに接続してのクエリ実行なども可能です。また、sql1 はもちろんですが RESTORING に変わっています。

自動フェイルオーバー

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

まず、Dbvisit StandbyMP ではデフォルトでは自動フェイルオーバーが設定されていないので、まず自動フェイルオーバーの設定を行います。右のメニューから自動フェールオーバーを選択します。

「緊急時のアクション」で「自動フェイルオーバーを実行する」を選択して設定を保存します。また、確認時間短縮のため、チェックリトライ回数を 1 に設定します。

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

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

1> shutdown;
2> go
Server shut down by request from login sa.

データベースを終了した後少し待つと、プライマリに障害があることが検知され、フェールオーバーが実施され sql1 がオンラインになります。

おわりに

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

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

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