Cisco Broadband Access Center アドミニストレータ ガイド Release 4.0

データベース ストレージ ファイル

RDU サーバは、データベース ディレクトリにある bpr.db というファイルに自身のデータベースを格納します。このディレクトリは、 BPR_DATA/rdu/db ディレクトリにあり、コンポーネントのインストール時に BPR_DATA パラメータを指定することでこの場所を設定できます。データベースの移動の詳細については、「データベースの場所の変更」を参照してください。

（注） 通常、データベース ファイルはランダムにアクセスされます。したがって、最高のデータベース パフォーマンスを得るためには、シーク時間が最も速く、回転アクセス レイテンシが最も小さいディスクを選択する必要があります。

データベースのトランザクション ログ ファイル

RDU サーバでは、データベースのトランザクション ログは 25 MB のファイルに保存され、そのファイルはデータベースのログ ディレクトリに保存されます。このディレクトリは、 BPR_DBLOG パラメータを指定することでインストール時に設定します。ログ ディレクトリは、 BPR_DBLOG/rdu/dblog ディレクトリにあります。トランザクション ログの新しいディレクトリへの移動の詳細については、「データベースの場所の変更」を参照してください。

データベースのログ ファイルの名前には、最初に log.00000001 、次に log.00000002 というように連番が付けられます。

（注） トランザクション ログが保存されるディスクは、通常、シーケンシャルにアクセスされるので、データはログ ファイルの最後に追加されます。最高のデータベース パフォーマンスを達成するには、このアクセス パターンを効率的に処理できるディスクを選択する必要があります。システム上で最も高速なディスクにデータベースのトランザクション ログ ディレクトリを置くことをお勧めします。また、1 GB のディスク容量を使用可能にしてください。

自動ログ管理

データベースのトランザクション ログ ファイルは、トランザクション データのデータベースへの書き込みが完了するまで、そのデータを保存しておくために使用されます。その後、トランザクション ログ データは冗長になり、ファイルがシステムから自動的に削除されます。

通常の状況では、データベースのトランザクション ログ ディレクトリ内にあるログ ファイルの数は数個以内にする必要があります。時間の経過とともに古いトランザクション ログはなくなり、新しいトランザクション ログが作成されます。

（注） データベースのトランザクション ログは、データベースにとって不可欠です。トランザクション ログ ファイルを手動で削除すると、データベースが破損します。

各種データベース ファイル

データベース ディレクトリには、他にもデータベースの動作に不可欠なファイルが保存されています。これらのファイルは、 rdu.db ファイルとともに BPR_DATA/rdu/db ディレクトリにあり、データベース バックアップの一環としてコピーされます。

• DB_VERSION：データベースの物理的および論理的なバージョンを識別するためのもので、RDU によって内部で使用されます。

• history.log ：ログ ファイルの自動的な削除、バックアップ、回復、復元処理などの不可欠なデータベース管理タスクに関するロギング動作のために使用されます。このログ ファイルは、管理者に有用な履歴情報を提供するだけでなく、RDU のデータベース処理にとっても非常に重要です。

ディスク容量不足の対処方法

RDU サーバでディスク容量が不足すると、syslog ファシリティを通じて syslog アラートが生成され、RDU ログが記録されます。その後、RDU サーバは自動的に再起動を試みます。RDU サーバが再起動を試みたときに out of disk space エラーが再び発生し、もう一度再起動が試みられる場合があります。

RDU サーバは、空きディスク容量が使用可能になるまで、繰り返し再起動しようとします。空き容量がほぼなくなっているディスク上である程度のディスク領域を解放すると、次の再起動で RDU が正常に起動します。

データベースのサイズが増大して現在のディスク パーティションの容量を超えた場合は、そのデータベースを新しいディスクまたはパーティションに移動してください。詳細については、「データベースの場所の変更」を参照してください。

（注） ディスク容量の使用率を監視して障害を防止するのが望ましい方法です。詳細については、「disk_monitor.sh ツールの使用方法」を参照してください。

データベースのバックアップ

バックアップとは、データベース ファイルをバックアップ ディレクトリにコピーする処理です。そのときに、これらのファイルを圧縮し、テープやその他のアーカイブに保存することができます。

RDU データベースのバックアップは、サーバのアクティビティを中断しないでファイルをコピーするだけなので、非常に効率的です。ただし、RDU データベース ディスクにアクセスするため、バックアップを行うと RDU のパフォーマンスが低下する場合があります。その反対も真実です。バックアップ中の RDU アクティビティは、バックアップのパフォーマンスに悪影響を与えます。そのため、バックアップは、RDU の使用率の低い時間帯に行う必要があります。

バックアップのパフォーマンスは、同時に実行されているシステム アクティビティ以外に、基礎となっているディスクおよびファイル システムのパフォーマンスからも影響を受けます。基本的にバックアップ速度は、データベース ファイルをコピー元からコピー先へコピーする速度と同じです。

BPR_HOME/rdu/bin ディレクトリにある backupDb.sh ツールを使用して、データベースのバックアップを行います。

• このツールを使用するには、バックアップ ファイルを保存するバックアップ先ディレクトリを指定する必要があります。このディレクトリは、現在のデータベース ファイル サイズの 120% に相当する使用可能ディスク容量があるディスクまたはパーティション上に存在する必要があります。

• 次の例で説明するように、このツールは、ユーザが指定したディレクトリの下に、タイムスタンプ付きのサブディレクトリを自動的に作成し、そこにバックアップを保存します。また、必要であれば、 -nosubdir というオプションのフラグを使用して、サブディレクトリの自動作成をディセーブルにできます。

また、 backupDb.sh コマンドは、自動的に経過を画面にレポートし、その動作を history.log に記録します。

backupDb.sh ツールを使用するときに、 -help オプションを使用すると、使用状況情報を取得できます。

例

この例において、 /var/backup はデータベース バックアップ ファイルの保存先を示します。

この例では、バックアップするすべてのデータベース ファイルは /var/backup/rdu-backup- 20070316-031028 というディレクトリに格納されます。最下位のサブディレクトリ（ rdu-backup-20070316-031028 ）は自動的に作成され、現在のタイムスタンプが付けられます。

タイムスタンプ付きのサブディレクトリの形式は、 rdu-backup-yyyyMMdd-HHmmss です。この例では、サブディレクトリは rdu-backup-20070316-031028 になります。これは、そのディレクトリに 2007 年 3 月 16 日午前 3 時 10 分 28 秒に開始したバックアップが保存されていることを意味しています。

（注） 移行が完了した後は、verifyDb.sh ツールを実行してデータベースの整合性を確認できます。検査はオプションのタスクです。リソースを集中的に使用する動作なので、データベースのバックアップを使用するシステムで実行してください。BPR_HOME/rdu/internal/db/bin ディレクトリにある verifyDb.sh スクリプトを実行します。

データベースの回復

データベースの回復とは、データベースを一貫性のある状態に戻す処理です。バックアップは稼働中の RDU 上で行われるので、データベースはコピー中に変更される場合があります。ただし、データベースのログ ファイルによって、データベースを一貫性のある状態に戻せることが保証されています。

回復は、データベースのスナップショットに対して行われます。つまり、このタスクは、稼働中の RDU サーバ上のデータベースには作用しません。回復タスクは、バックアップの直後か、または、データベースを RDU サーバに復元する前に実行できます。

（注） シスコでは、バックアップを行うたびに、その直後に回復を行うことを推奨しています。この方法をとると、緊急時にバックアップしたデータベースをより速やかに復元できます。

データベースの回復に要する時間は、バックアップの一環としてコピーするデータベースのログ ファイルの数によって決まり、したがって、バックアップの実行時の RDU のアクティビティ レベルによって決まります。バックアップの実行時に RDU が同時に実行している活動の数が多いほど、バックアップの一環としてコピーする必要があるトランザクション ログ ファイルの数が多くなり、回復に要する時間が長くなります。一般に、データベースの回復の所要時間は、トランザクション ログ ファイルあたり 10 ～ 60 秒です。

BPR_HOME/rdu/bin ディレクトリにある recoverDb.sh ツールを使用して、データベースのスナップショットの回復を行います。このツールを使用するときは、バックアップの場所を指定する必要があります。このディレクトリでは、回復も行われます。

recoverDb.sh ツールを使用するときに、 -help オプションを使用して、ツールの使用状況情報を取得できます。

例

この例では、 /var/backup/rdu-backup-20070316-031028 ディレクトリにあるスナップショットを一貫性のある状態に回復します。回復処理の経過は画面に表示され、そのアクティビティはスナップショット ディレクトリにある history.log ファイルに記録されます。

データベースの復元

データベースの復元とは、あらかじめ回復したデータベースのスナップショットを、RDU サーバによって使用されるデータベース上の場所にコピーする処理です。復元できるのは、あらかじめ回復しておいたデータベースだけです。

データベースの復元とは現行の RDU データベースの交換を意味するので、最初に古いデータベースを適切に削除し、アーカイブすることが非常に重要になります。

BPR_HOME/rdu/bin ディレクトリにある restoreDb.sh ツールを使用して、現行の RDU データベースを別のデータベースと置換します。このツールを使用するときは、入力ディレクトリを指定する必要があります。このディレクトリには、RDU サーバに復元するデータベースの、回復したバックアップ スナップショットが含まれている必要があります。

（注） restoreDb.sh ツールを実行する前に、/etc/init.d/bprAgent stop rdu コマンドを実行して RDU サーバを停止する必要があります。また、データベースをバックアップしてから、すべてのファイルを rdu/db ディレクトリおよび rdu/dblog ディレクトリから削除する必要もあります。

restoreDb.sh ツールを使用するときに、 -help オプションを使用すると、使用状況情報を取得できます。

例

この例では、 /var/backup/rdu-backup-20070316-031028 ディレクトリにあるデータベースが RDU サーバに復元されます。

復元処理の完了後は、RDU を再起動する必要があります。RDU ログ ファイルには、起動が成功したことを示すメッセージが書き込まれます。

このツールでは、経過がユーザに報告され、動作が history.log ファイルに記録されます。