tarコマンドを用いたDb2フラッシュコピー模擬検証手順 #db2

フラッシュ・コピーによるDb2バックアップ（スプリット・ミラー）

24時間稼働でサービスが提供されるような環境では、データベース・サービスを止めず、オンラインでバックアップ取得を行います。
特にサイズが大きいデータベースでは、ストレージ装置の提供する高速コピー機能(たとえばIBMのDSシリーズやIBM StorwizeファミリーではFlashCopy)が利用されます。Db2では、フラッシュコピーなどの高速コピー機能を使用して作成されたデータベースのコピーのことをスプリット・ミラーと呼びます。

フラッシュ・コピーの模擬検証

フラッシュコピーを取る手順を確認・検証するにはストレージ装置が必要ですが、任意のタイミングで利用できないことも少なくありません。とはいえ、早いうちに手順を確立しておきたいとも思うものです。
そういった場合も、tarコマンドを利用することで、ストレージ装置の機能が使えない時でもスプリット・ミラーを利用した Db2 バックアップ・リストア手順の検証を行うことができます。

tarコマンドによる Split Mirror バックアップ・リストア手順

想定するシナリオ

スタンドアローンで動いているDBサーバで、ファイルシステム障害が起きたと仮定
事前にとっておいたスプリット・ミラー(tarファイル)をリストア
スプリット・ミラー・データベースを初期化した後ログを適用し、障害発生直前までロールフォワード

前提

データベースが既に作成・構成済であること (下記は必要最低限の項目)
- データベース作成
- アーカイブログの構成
バックアップ(tar)取得対象のディレクトリーも、予め確認しておいてください
- DBディレクトリー、ストレージパス、ログパス、等
- 設計書のDb2ディレクトリー設計の項目などを参考に。
- わからない場合は、下記コマンドでも確認できます。

Db2のディレクトリー構成確認コマンド実行例：
（※Docker版Db2環境の例であり、インストーラを用いて導入したDb2とはディレクトリ構成が異なります)

$ db2 "select dbpartitionnum, substr(type,1,20) as type, substr(path,1,60) from sysibmadm.dbpaths"

DBPARTITIONNUM TYPE                 3
-------------- -------------------- ------------------------------------------------------------
             0 LOGPATH              /database/data/db2inst1/NODE0000/SQL00001/LOGSTREAM0000/
             0 DB_STORAGE_PATH      /database/data/
             0 LOCAL_DB_DIRECTORY   /database/data/db2inst1/NODE0000/sqldbdir/
             0 DBPATH               /database/data/db2inst1/NODE0000/SQL00001/
             0 DBPATH               /database/data/db2inst1/NODE0000/SQL00001/MEMBER0000/

  5 record(s) selected.

1. バックアップ取得

ターミナルを2つ開きます。手順の終わりまで、引き続き同じターミナルを利用します。

ターミナル1：
- Db2管理者権限のあるユーザでログインし、DB接続を行う
- Db2コマンドはこの画面から行います
ターミナル2：
- FlashCopy取得対象ディレクトリ・ファイルすべてに対する読取・書込権限のあるユーザでログインする
- ストレージ操作(ここではFlashCopyの代わりにtar作成) はこの画面から行います

[Hints & Tips]

Db2のディスクI/Oの一時停止/再開を行わせる SET WRITE SUSPEND / RESUME コマンドは、同じDb2セッションの中から実行することが推奨されます。SET WRITE SUSPENDを行ったターミナルはクローズせずそのままの状態で置いておき、別ターミナルから tar コマンドを実行します。
Db2管理者権限でもtar作成が可能な権限を有する場合にはターミナル1のみで作業するのでも構いません。
本番環境においては、ストレージのフラッシュコピー取得コマンドやOSコマンド(ファイルシステムのFreeze/thawなど)を行うための権限を持つユーザで処理を行うことになることから、上の図のようにDb2の操作を行う親シェルスクリプト(ターミナル1)から、コピー取得操作を行う子シェルスクリプト(ターミナル2)を呼び出す構成とすることが一般的です。

2. ディスク障害

疑似的な障害ケースとして、フラッシュコピー対象ディレクトリーを削除します(≒ディスク障害発生)
ターミナル2で、フラッシュコピー取得対象ディレクトリーを削除します。

3. tar を展開し、FlashCopy対象ディレクトリーを復元

障害後の復旧を行うためにDb2を停止します(db2stop)。
その後、tarを展開して Split Mirror イメージをリストアした状態とします。

4. ミラーリングされたDBの初期化とロールフォワード

スプリット・ミラー・データベースを初期化(db2inidb)すると、ロールフォワード・ペンディング状態となります。
この状態のデータベースにログを適用し、ロールフォワード(db2 rollforward) を行います。
tar 作成前後でログ・アーカイブ処理を行っているため、ロールフォワードに必要なログは、アーカイブログパスにすべて存在しています。

db2inidb コマンド標準出力：

$ db2inidb mydb as standby
DBT1000I  ツールは正常に完了しました。

db2 rollforward コマンド標準出力：

$ db2 rollforward database mydb to end of logs and stop

                                 ロールフォワード状況

 入力データベース別名                   = mydb
 状況を返したメンバーの数               = 1

 メンバー ID                            = 0
 ロールフォワード状況                   = 非ペンディング
 次に読み込むログ・ファイル             =
 処理したログ・ファイル            = S0000003.LOG - S0000005.LOG
 最後にコミットしたトランザクション     = 2019-11-14-11.08.22.000000 UTC

DB20000I  ROLLFORWARD コマンドが正常に完了しました。

以上の手順で、ミラーリングされたデータベースが利用可能となります。