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

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

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

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

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

### 前提
1. データベースが既に作成・構成済であること (下記は必要最低限の項目)
 - データベース作成
 - アーカイブログの構成
2. バックアップ(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作成) はこの画面から行います

![Backup.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/b0302b7d-7c28-6643-aac1-a5f74282354c.png)

#### [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で、フラッシュコピー取得対象ディレクトリーを削除します。
![RemoveDir.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/102ed6a3-b69d-c7fc-75df-a9daf9384fa2.png)


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

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

![Restore.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/6bd1d761-a6f6-99bb-bc7a-a9222c15d8a8.png)


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

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

![db2inidb_rollforward.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/468682/69439ac1-b333-e810-61d1-19a4ae594a81.png)

 - 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 コマンドが正常に完了しました。
```

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