検索
連載

止められないデータベースのバックアップ/リカバリDB2マイスター養成講座(4)

データベースの破壊は、ビジネスにとって致命傷となる。24時間365日稼働のシステムを前提に、DB2のバックアップとリカバリについて検討しよう。(編集局)

Share
Tweet
LINE
Hatena

 インターネットを使った商取引が盛んになり、24時間365日Webサイトで買い物ができるようになりました。裏を返せば、24時間365日システムを止められないということです。システムの稼働時間が長くなるということは、それだけデータ・ロスのリスクも大きくなるわけですから、バックアップの重要性が増します。さらに、システムを止められないわけですからバックアップの取り方も難しくなります。

 そこで、今回はデータベースのバックアップとリカバリについて解説します。前述したようにシステムを止めることが難しくなっていますので、システム(データベース)を止めないバックアップを中心に進めます。また、普段はリカバリを軽視しがちですが、いざ障害というときにはうまくいかないものです。リカバリ方法についても、普段から手順を確認しておくことが肝心です。

 実際の運用場面では、ストレージ管理ツールと呼ばれるバックアップ・ツールを使ってバックアップ/リカバリを行うのが一般的です。しかし、今回はDB2の機能を中心に解説します。Linux対応のストレージ管理ツールとしては、BakBone社のNetVault(http://www.bakbone.co.jp/products/netvault.html)が有名です(もちろんDB2にも対応しています)。

データベースの障害

 まず、想定されるデータベースの障害について考えてみましょう。データベースの障害は、以下の4つに大別できます。

  • データベースの論理障害
     論理障害とは、ファイルシステムが壊れたり、人為的にファイルを消してしまうなどでデータベースが破壊される障害のことです。また、DB2のプロセスがダウンして、トランザクションが不整合な状態になることも論理障害の1つです。

     論理障害に対するリカバリ方法としては、バックアップ・イメージからのリストアやDB2の機能である「クラッシュ・リカバリー」があります。

  • ストレージ・ディスクの障害
     ストレージ・ディスクの障害とは、文字通りディスクが壊れてしまうことです。障害の程度にもよりますが、最悪のケースとしてはディスク装置全体が壊れてしまう事態も想定しなければいけません。

     この障害に対しては、やはりバックアップ・イメージからのリストアが必要です。また、最近はハードウェアあるいはソフトウェア的にストレージデバイス間でコピーを取る仕組みも用意されているので、これを使ったスナップショット・バックアップも有効な手段です。

  • サーバの障害
     サーバがダウンしてしまう障害です。サーバとストレージを分離して構成している場合やHAクラスタを構成してスタンバイ機を用意している場合は、ストレージにデータが残っているので、クラッシュ・リカバリーなどで復旧可能です。これ以外の場合は、やはりバックアップ・イメージからのリカバリが必要です。

  • サイトの障害
     この場合の「サイト」とは、データセンターやマシンルームのある建物を指します。サイト障害は、地震や火災などでサイト全体が利用できなくなるような致命的な障害です。災害時に同じ場所で復旧するのは無理ですから、別のサイトでの復旧が必要になります。バックアップの方法としては、遠隔地のリモート・サイトにバックアップ・イメージやデータのコピーを取る必要があります。

 以下の表に、想定されるデータベース障害とそれに対応するためのバックアップ/リカバリ方式をまとめました。

想定される障害 バックアップ/リカバリ方式
データベースの論理障害 DB2クラッシュ・リカバリー(DB2機能)
DB2バックアップ/リストア(DB2機能)
ストレージ・ディスク障害 DB2バックアップ/リストア(DB2機能)
ローカル・コピー機能(ハード/ソフト機能)
サーバの障害 DB2クラッシュ・リカバリー(DB2機能)
ローカル・フェイルオーバー(HAクラスタ)
レプリケーション(DB2機能)
ログ・シッピング(DB2機能)
サイト全体の障害 DB2クラッシュ・リカバリー(DB2機能)
DB2バックアップ/リストア(DB2機能)
グローバル・フェイルオーバー(HAクラスタ)
遠隔コピー機能(ハード/ソフト機能)
レプリケーション(DB2機能)
ログ・シッピング(DB2機能)

データベースのリカバリに必要なものは?

 具体的なバックアップ/リカバリの解説に入る前に、まずデータベースのリカバリに必要なものは何かを整理しておきましょう。

■データベース・ディレクトリー

 DB2でデータベースを作成すると、データベース・ディレクトリーとデフォルトの表スペースなどが作られます。データベース・ディレクトリーの場所は、list database directoryコマンドで確認できます。

$ db2 list database directory
 
  システム・データベース・ディレクトリー
 
 ディレクトリー中の項目数 = 4
 
 データベース 1 項目 :
 
 データベース別名                                    = WEATHER
 データベース名                                      = WEATHER
 ローカル・データベース・ディレクトリー                 = /home/db2inst1
 データベース・リリース・レベル                         = a.00
 コメント                                           =
 ディレクトリー項目タイプ                              = 間接
 カタログ・データベース・パーティション番号                = 0
 
 データベース 2 項目 :
 
 データベース別名                                    = TOOLSDB
 データベース名                                      = TOOLSDB
 ローカル・データベース・ディレクトリー                 = /home/db2inst1
 データベース・リリース・レベル                         = a.00
 コメント                                           =
 ディレクトリー項目タイプ                              = 間接
 カタログ・データベース・パーティション番号                = 0
 
 データベース 3 項目 :
 
 データベース別名                                    = II
 データベース名                                      = II
 ローカル・データベース・ディレクトリー                 = /home/db2inst1
 データベース・リリース・レベル                          = a.00
 コメント                                            =
 ディレクトリー項目タイプ                               = 間接
 カタログ・データベース・パーティション番号                 = 0
 
 データベース 4 項目 :
 
 データベース別名                                    = SAMPLE
 データベース名                                      = SAMPLE
 ローカル・データベース・ディレクトリー                 = /home/db2inst1
 データベース・リリース・レベル                          = a.00
 コメント                                            =
 ディレクトリー項目タイプ                               = 間接
 カタログ・データベース・パーティション番号                 = 0
list database directory実行例

■テーブルスペース・コンテナー

 表スペースを別のディレクトリやRAWデバイスに作成した際は、テーブルスペース・コンテナーもバックアップ対象になります。コンテナーの場所は、list tablespacesで表スペースの概要を出力し、get snapshot for tablespaces on [DB名]で詳細なパスなどを確認します。

$ db2 get snapshot for tablespaces on sample
 
             表スペース・スナップショット
 
最初のデータベース接続タイム・スタンプ                = 12/15/2003 22:20:02.583522
最後のリセット・タイム・スタンプ                     =
スナップショット・タイム・スタンプ                   = 12/15/2003 22:20:39.317588
データベース名                                    = SAMPLE
データベース・パス                                 = /home/db2inst1/db2inst1/NODE0000/SQL00004/
入力データベース別名                               = SAMPLE
アクセスされた表スペース数                          = 3
 
 
表スペース名                                      = SYSCATSPACE
  表スペース ID                                   = 0
  表スペース タイプ                                = システム管理スペース
  表スペース・コンテンツ・タイプ                     = 任意のデータ
  表スペース・ページ・サイズ (バイト)                = 4096
  表スペース・エクステント・サイズ (ページ)           = 32
  表スペース・プリフェッチ・サイズ (ページ)           = 32
  現在使用中のバッファー・プール ID                  = 1
  次回始動のバッファー・プール ID                    = 1
  表スペース状態                                   = 0x'00000000'
   詳しい説明:
     標準
  合計ページ数                                     = 0
  使用可能ページ数                                 = 0
  使用済みページ数                                 = 0
  最小リカバリー時間                              =
  静止状態の数                                   = 0
  コンテナー数                                   = 1
 
  コンテナー名                                    = /home/db2inst1/db2inst1/NODE0000/SQL00004/SQLT0000.0
      コンテナー ID                               = 0
      コンテナー・タイプ                           = パス
      コンテナーの合計ページ数                      = 0
      コンテナーの使用可能ページ数                   = 0
      ストライプ・セット                           = 0
      コンテナーはアクセス可能                      = はい
(以下略)
get snapshot for tablespaces on実行例

■ログ・ディレクトリ(アクティブ・ログ、アーカイブ・ログ)

 詳しくは後述しますが、DB2のログは2種類あります。アクティブ・ログとアーカイブ・ログです。アーカイブ・ログの場所は、データベース構成パラメータで確認できます。

$ db2 get database config for sample | grep "ログ・ファイルのパス"
 ログ・ファイルのパス
    = /home/db2inst1/db2inst1/NODE0000/SQL00004/SQLOGDIR/
実行例

 アーカイブ・ログが保存されるディレクトリは、アクティブ・ログのあるディレクトリと同じかUSEREXITプログラム(後述)で指定する保存ディレクトリとなります。

■インスタンス・ホーム

 毎回バックアップが必要というわけではありませんが、データベース・マネージャー構成ファイルやDB2レジストリ変数が格納されているので、これらのパラメータや変数を変更した後は、バックアップすることをお勧めします。

バックアップ/リカバリの方式

 それでは、バックアップとリカバリの方式を具体的に見ていきましょう。

■クラッシュ・リカバリー

 クラッシュ・リカバリーは、ディスクに書き込まれた情報(ログコントロールファイル、トランザクションログ)を基にディスクに反映されていないトランザクションを反映させ、コミットされていないトランザクションをディスクから消去し、トランザクションの整合性が保たれた状態にデータベースを戻すリカバリ方式です。この方式には、バックアップという考え方はありません。

 クラッシュ・リカバリーは、ユーザーやアプリケーションが特に意識する必要はありません。DB2のデータベース・マネージャーが、クラッシュ後に自動的に再始動を行ってクラッシュ・リカバリー処理を行います。

DB2のクラッシュ・リカバリー
DB2のクラッシュ・リカバリー

 自動再始動は、データベース構成パラメータのAUTORESTARTがONになっている場合に行われます。AUTORESTARTをOFFにした場合は、明示的に再始動する必要があります。

$ db2 restart database sample
DB20000I  RESTART DATABASE コマンドが正常に終了しました。
実行例

■DB2のバックアップ/リストアコマンド

 DB2の一般的なバックアップ機能です。データベースもしくは表スペース単位でのバックアップが可能です。表単位ではバックアップできないので注意が必要です。

 可用性を求めるのであれば、オンラインバックアップを使用します。バックアップ方式は「フルバックアップ」と「増分バックアップ」。増分バックアップの場合は「累積」か「非累積」を選択します。ごく一般的な方法なので、詳しくはDB2のマニュアルを参照してください。

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0001933.htm

 この場合のリストアはもちろん、リストアコマンドを使います。

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0001976.htm

 ロギングの方式やバックアップのタイプによって、リストアコマンドのオプションも変わってくるので、運用を始める前に十分な確認が必要です。

 また、アーカイブ・ロギングを行っている場合は、リストア後にロールフォワードが必要になります。

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0001978.htm

■ローカル・コピー機能

 詳しくは次回の高可用性と災害対策の部分で解説しますが、ローカル・コピー機能はある時点でのディスク領域のコピーを丸ごと取って、データベースをバックアップする方法です。最近は、ディスク領域を高速にコピーする機能がオプションで用意されているストレージデバイスもあります。この高速コピー機能とローカル・コピー機能を組み合わせることで、可用性が高くしかも高速なバックアップが可能になります。

 高速コピー機能を使う際に注意が必要なのは、トランザクションがひっきりなしに続いている状態でディスクのコピーを取るのでは、トランザクションの整合性が取れなくなるということです。このような場合は、I/Oを止めてディスクの書き込みの静止点を取る必要があります。DB2には、set write suspend/resumeというコマンドが用意されています。これは、suspendが発行された時点でDB2からディスクへのI/Oを止め、DB2としてI/Oの静止点を取って整合性を保つというコマンドです。resumeコマンドが発行されるまで書き込みはできませんが、読み込みはできるのでSELECT文は実行可能です。

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/core/r0009503.htm

■リモート・コピー機能

 前述のローカル・コピー機能と基本的には同じです。違いは、同じマシン内ではなくマシン間(リモート)でコピーを行う点です。最近は、この方法を使った災害対策を意識したシステムも構築されています。

■ログ・シッピング

 ログ・シッピングは、FTPなどを使ってアーカイブ・ログをスタンバイサイトへ転送し、スタンバイサイトは転送されてきたログを適用して常にプライマリサイトに近い状態を保つ方式です。

データベースのロギングについて

 後回しになってしまいましたが、データベースロギングについて説明しておきます。DB2のロギングは、循環ログ方式と保存ログ(アーカイブ・ログ)方式に大別できます。

 循環ログ方式は文字通り、ログを循環式に利用する方式です。循環ログ方式では、オンラインバックアップができません。一方のアーカイブ・ログ方式は、クローズされたログを保存していく方式で、オンラインバックアップも可能です。

 どちらのログ方式を使用するかは、データベース構成パラメータのLOGRETAINで設定します。

LOGRETAIN = OFF     : 循環ログ方式
LOGRETAIN = RECOVERY : アーカイブ・ログ方式

 また、アーカイブ・ログ方式では、アーカイブ・ログを任意のディレクトリに保存し、リカバリ時に必要なログを取り出すUSEREXITプログラムを使用することもできます。USEREXITプログラムを使用するかしないかは、USEREXITパラメータで選択します。

USEREXIT = OFF   : USEREXITプログラムを使用しない
USEREXIT = ON   : USEREXITプログラムを使用する

 USEREXITプログラムは標準では提供されていませんが、サンプルが用意されているのでこれを編集して利用します。サンプルには、以下の4つがあります。

/home/db2inst1/sqllib/samples/c/db2uext2.cdisk : ディスクに保存
/home/db2inst1/sqllib/samples/c/db2uext2.ctape : テープに保存
/home/db2inst1/sqllib/samples/c/db2uext2.ctsm : TSMを使う
/home/db2inst1/sqllib/samples/c/db2uext2.cxbsa : XBSAを使う

 コンパイルや使用方法はソースの中に書いてあります。例えば、ログをディスクに保存するサンプルを使う場合は適当なディレクトリにファイルをコピーして、230行目から236行目を編集します。

#define ARCHIVE_PATH      "/db2log/"           /* path must end with a slash      */
#define RETRIEVE_PATH     "/db2log/"           /* path must end with a slash      */
#define AUDIT_ACTIVE          1           /* enable audit trail logging      */
#define ERROR_ACTIVE          1           /* enable error trail logging      */
#define AUDIT_ERROR_PATH  "/db2log/"           /* path must end with a slash      */
#define AUDIT_ERROR_ATTR    "a"           /* append to text file             */
#define BUFFER_SIZE          32           /* # of 4K pages for output buffer */
db2uext2.cdisk修正点

 このソースをコンパイルして、db2uext2というバイナリファイルを作成します。

$ gcc -D_INCLUDE_POSIX_SOURCE db2uext2.c -o db2uext2

 このバイナリを、$INSTHOME/sqllib/adm/db2uext2へコピーします。このパスは固定であり、変更することはできません。また、USEREXITプログラムはインスタンスで1つです。


 今回は可用性を重視し、システムを止めることなくバックアップすることにポイントを置いて、データベースのバックアップ/リカバリについて解説しました。ただし、ローカル/リモートのコピー機能を使ったバックアップについては、まだ十分な説明ができていません。次回の高可用性と災害対策で詳しく説明したいと思います。


Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る