データベースの破壊は、ビジネスにとって致命傷となる。24時間365日稼働のシステムを前提に、DB2のバックアップとリカバリについて検討しよう。(編集局)
インターネットを使った商取引が盛んになり、24時間365日Webサイトで買い物ができるようになりました。裏を返せば、24時間365日システムを止められないということです。システムの稼働時間が長くなるということは、それだけデータ・ロスのリスクも大きくなるわけですから、バックアップの重要性が増します。さらに、システムを止められないわけですからバックアップの取り方も難しくなります。
そこで、今回はデータベースのバックアップとリカバリについて解説します。前述したようにシステムを止めることが難しくなっていますので、システム(データベース)を止めないバックアップを中心に進めます。また、普段はリカバリを軽視しがちですが、いざ障害というときにはうまくいかないものです。リカバリ方法についても、普段から手順を確認しておくことが肝心です。
実際の運用場面では、ストレージ管理ツールと呼ばれるバックアップ・ツールを使ってバックアップ/リカバリを行うのが一般的です。しかし、今回はDB2の機能を中心に解説します。Linux対応のストレージ管理ツールとしては、BakBone社のNetVault(http://www.bakbone.co.jp/products/netvault.html)が有名です(もちろんDB2にも対応しています)。
まず、想定されるデータベースの障害について考えてみましょう。データベースの障害は、以下の4つに大別できます。
以下の表に、想定されるデータベース障害とそれに対応するためのバックアップ/リカバリ方式をまとめました。
想定される障害 | バックアップ/リカバリ方式 | |
---|---|---|
データベースの論理障害 | 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
表スペースを別のディレクトリや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 コンテナーはアクセス可能 = はい (以下略)
詳しくは後述しますが、DB2のログは2種類あります。アクティブ・ログとアーカイブ・ログです。アーカイブ・ログの場所は、データベース構成パラメータで確認できます。
$ db2 get database config for sample | grep "ログ・ファイルのパス" ログ・ファイルのパス = /home/db2inst1/db2inst1/NODE0000/SQL00004/SQLOGDIR/
アーカイブ・ログが保存されるディレクトリは、アクティブ・ログのあるディレクトリと同じかUSEREXITプログラム(後述)で指定する保存ディレクトリとなります。
毎回バックアップが必要というわけではありませんが、データベース・マネージャー構成ファイルやDB2レジストリ変数が格納されているので、これらのパラメータや変数を変更した後は、バックアップすることをお勧めします。
それでは、バックアップとリカバリの方式を具体的に見ていきましょう。
クラッシュ・リカバリーは、ディスクに書き込まれた情報(ログコントロールファイル、トランザクションログ)を基にディスクに反映されていないトランザクションを反映させ、コミットされていないトランザクションをディスクから消去し、トランザクションの整合性が保たれた状態にデータベースを戻すリカバリ方式です。この方式には、バックアップという考え方はありません。
クラッシュ・リカバリーは、ユーザーやアプリケーションが特に意識する必要はありません。DB2のデータベース・マネージャーが、クラッシュ後に自動的に再始動を行ってクラッシュ・リカバリー処理を行います。
自動再始動は、データベース構成パラメータのAUTORESTARTがONになっている場合に行われます。AUTORESTARTをOFFにした場合は、明示的に再始動する必要があります。
$ db2 restart database sample DB20000I RESTART DATABASE コマンドが正常に終了しました。
DB2の一般的なバックアップ機能です。データベースもしくは表スペース単位でのバックアップが可能です。表単位ではバックアップできないので注意が必要です。
可用性を求めるのであれば、オンラインバックアップを使用します。バックアップ方式は「フルバックアップ」と「増分バックアップ」。増分バックアップの場合は「累積」か「非累積」を選択します。ごく一般的な方法なので、詳しくはDB2のマニュアルを参照してください。
この場合のリストアはもちろん、リストアコマンドを使います。
ロギングの方式やバックアップのタイプによって、リストアコマンドのオプションも変わってくるので、運用を始める前に十分な確認が必要です。
また、アーカイブ・ロギングを行っている場合は、リストア後にロールフォワードが必要になります。
詳しくは次回の高可用性と災害対策の部分で解説しますが、ローカル・コピー機能はある時点でのディスク領域のコピーを丸ごと取って、データベースをバックアップする方法です。最近は、ディスク領域を高速にコピーする機能がオプションで用意されているストレージデバイスもあります。この高速コピー機能とローカル・コピー機能を組み合わせることで、可用性が高くしかも高速なバックアップが可能になります。
高速コピー機能を使う際に注意が必要なのは、トランザクションがひっきりなしに続いている状態でディスクのコピーを取るのでは、トランザクションの整合性が取れなくなるということです。このような場合は、I/Oを止めてディスクの書き込みの静止点を取る必要があります。DB2には、set write suspend/resumeというコマンドが用意されています。これは、suspendが発行された時点でDB2からディスクへのI/Oを止め、DB2としてI/Oの静止点を取って整合性を保つというコマンドです。resumeコマンドが発行されるまで書き込みはできませんが、読み込みはできるのでSELECT文は実行可能です。
前述のローカル・コピー機能と基本的には同じです。違いは、同じマシン内ではなくマシン間(リモート)でコピーを行う点です。最近は、この方法を使った災害対策を意識したシステムも構築されています。
ログ・シッピングは、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というバイナリファイルを作成します。
$ gcc -D_INCLUDE_POSIX_SOURCE db2uext2.c -o db2uext2
このバイナリを、$INSTHOME/sqllib/adm/db2uext2へコピーします。このパスは固定であり、変更することはできません。また、USEREXITプログラムはインスタンスで1つです。
今回は可用性を重視し、システムを止めることなくバックアップすることにポイントを置いて、データベースのバックアップ/リカバリについて解説しました。ただし、ローカル/リモートのコピー機能を使ったバックアップについては、まだ十分な説明ができていません。次回の高可用性と災害対策で詳しく説明したいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.