tarコマンドを用いた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 コマンドが正常に完了しました。
以上の手順で、ミラーリングされたデータベースが利用可能となります。
Author And Source
この問題について(tarコマンドを用いたDb2フラッシュコピー模擬検証手順), 我々は、より多くの情報をここで見つけました https://qiita.com/mi-kana/items/7215c1b889a10e896870著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .