| StorageTek Tape Analytics 管理ガイド リリース 2.0 E53287-01 |
|
 前 |
 次 |
この章では、各種 STA サービスの管理について説明します。最初に『STA インストールおよび構成ガイド』の「STA サービスの構成」章を参照し、これらのサービスを構成してください。
STA サービスデーモン staservd は常時実行の Linux サービスで、STA バックアップサービスと STA リソースモニターサービスを管理および実行します。STA バックアップサービスと STA リソースモニターサービスは、STA サービスデーモン内でそれぞれ別の実行スレッドとして実行します。
STA start all コマンドを使用して STA サーバーをブートすると STA サービスデーモンが開始し、サーバーを停止するとサービスデーモンは停止します。次のコマンドを使用して STA サービスデーモンの開始、停止、およびステータスの確認を実行できます。
STA サービスデーモンを開始するには:
# STA start staservd
Starting staservd Service...
staservd service was successfully started
STA サービスデーモンを停止するには:
# STA stop staservd
Stopping the staservd Service...
Successfully stopped staservd service
STA サービスデーモンのステータスを確認するには:
# STA status staservd
staservd service is running
STA コマンドの詳細は、章 2, "サーバー管理."を参照してください
|
注: STA をインストールすると、STA サービスデーモンが STA バックアップサービスと STA リソースモニターサービスを開始しますが、未構成の状態ではこれらのサービスは有効になりません。これらのサービスを構成するには、『STA インストールおよび構成ガイド』の「STA サービスの構成」章を参照してください。 |
STA バックアップサービスは STA サービスデーモン内で実行するサービスの 1 つです。これは STA データベースおよび鍵構成ディレクトリの自動完全バックアップを実行し、それらのファイルを STA サーバー上の指定場所または圧縮形式でリモートサーバーに書き込みます。Oracle では、リモートバックアップサーバーを構成することをお勧めしています。
続行する前に、STA サービスデーモンが実行していることを確認します。"STA サービスデーモン"を参照してください。
STA バックアップサービスは、/Oracle/StorageTek_Tape_Analytics/common/bin にある staservadm という管理ユーティリティーを使用して構成します。STA バックアップサービスを構成するには、『STA インストールおよび構成ガイド』の「STA サービスの構成」章を参照してください。
STA バックアップサービスを構成すると、次のプロセスが 24 時間ごとに 1 回実行されます。
次のファイルタイプの高速ダンプ (「ホットバックアップ」とも呼ばれています) を開始します。
MySQL データベースダンプファイル
MySQL バイナリログファイル
STA サービスデーモンおよび STA WebLogic の構成ファイル
STA サービスデーモンおよび STA バックアップサービスの管理ログ
指定されたバックアップホストにダンプファイルを転送します
前日の完全ダンプファイルを STA サーバーから削除します
現在日のダンプファイルのコピーを STA サーバー上の /dbbackup/local ディレクトリに書き込みます。
現在のプリファレンス設定のステータスを表示するには、次のコマンドを入力します。
# ./staservadm -Q
"Configured" フィールドに ”no,” が表示されている場合、バックアップサービスは ”アイドル” モードで実行されているため、バックアップは実行されていません。『STA インストールおよび構成ガイド』の説明に従って、適切な構成設定を行う必要があります。
構成済 STA バックアップサービスの出力例:
# ./staservadm -Q Contacting daemon...connected. Querying Preferences. Current STA Backup Service Settings: Configured [yes] File Transfer -S [SCP] Full Backup -T [11:00] Sleep Interval -i [350 sec] Backup Hostname -s [stabaksvr] Backup Username -u [stabck] Backup Password -p [*******] Backup Directory -d [/home/stabck/STAbackups] Database Username -U [stadba] Database Password -P [*********]
現在のプリファレンス設定をクリアするには、次のコマンドを入力します。
# ./staservadm -C
バックアップサービスが未構成の状態になり、”アイドル” 状態に戻ります。『StorageTek Tape Analytics インストールおよび構成ガイド』の説明に従って、新規の設定を指定できます。例:
# ./staservadm -C Contacting daemon...connected. Clearing Preferences. Done. Current STA Backup Service Settings: Configured [no] File Transfer -S [SCP] Full Backup -T [00:00] Sleep Interval -i [300 sec] Backup Hostname -s [] Backup Username -u [] Backup Password -p [] Backup Directory -d [] Database Username -U [] Database Password -P []
ファイルが正常に送信されたかどうかを確認するには:
STA サーバー上のログを確認します。
ターゲットバックアップサーバーにログオンし、バックアップディレクトリの内容を一覧表示します。
staservd.log.0 ファイルにはバックアップサービス構成ユーティリティーのアクティビティーが記録されます。
作業ディレクトリを STA バックアップログディレクトリに変更します。
# cd /var/log/tbi/db/backups
staservd.log.0 ファイルで、次の文字列を検索します: "INFO: done.Database dump completed."
# grep "INFO: done. Database dump completed" staservd.log.0
INFO: done. Database dump completed, file located at
/dbbackup/local/20130721_133755.stafullbackup.sql
INFO: done. Database dump completed, file located at
/dbbackup/local/20130722_133755.stafullbackup.sql
INFO: done. Database dump completed, file located at
/dbbackup/local/20130723_133755.stafullbackup.sql
INFO: done. Database dump completed, file located at
/dbbackup/local/20130724_133755.stafullbackup.sql
ターゲットバックアップサーバーにログオンします。
ファイルを一覧表示します。この例では、STA サーバー「tbivb01」からのバックアップファイルを受信するディレクトリとして /backups/tbivb01 が設定されています。
# ls -1 /backups/tbivb01 0.stadb-bin.000023.gz 0.stadb-bin.000024.gz 0.stadb-bin.000026.gz 0.stadb-bin.000027.gz 20130723_133755.stadb-bin.000023.gz 20130723_133755.conf.zip.gz 20130723_133755.fmwconfig.zip.gz 20130723_133755.stadb-bin.000025.gz 20130723_133755.stadb-bin.000026.gz 20130723_133755.stafullbackup.sql.gz
/dbbackup/local ディレクトリ内のファイルを一覧表示し、最新のバックアップファイルのコピーが STA サーバーにローカルで保存されていることを確認します。
# ls -l /dbbackup/local
20130721_133755.conf.zip
20130721_133755.fmwconfig.zip
20130721_133755.stafullbackup.zip
一覧表示されるファイルの形式は、YYYYMMDD_HHMMSS.filename.zip です。
章 4, "パスワード管理"を参照してください。
STA リソースモニターサービスは、STA サーバーリソース (データベーステーブル領域、ディスクボリューム領域、ロギングボリュームディスク領域、物理メモリーの使用率など) に関するモニターとレポート作成を行います。
各リソースに使用率の高水位標 (HWM) を設定できます。高水位標とは、警告が発行されるときのしきい値です。しきい値に到達するか、しきい値を上回ると、標準日次リソースレポートに警告が記録され、警告を 1 人以上の指定受信者に電子メールで送信する (オプション) ことも可能です。
たとえばデータベーステーブル領域の HWM を 60% に設定した場合、許可されている最大データベーステーブル領域の 60% 以上を STA アプリケーションが使用すると、STA リソースモニターがこれを検知し、テーブル領域警告を有効にして、指定受信者に電子メールを送信します。また、永続モードを有効にした場合、リソースモニターは、システムのスキャンを行うたびに警告の電子メールを送信します。
STA リソースモニターサービスは、/Oracle/StorageTek_Tape_Analytics/common/bin にある staresmonadm という管理ユーティリティーを使用して構成します。STA リソースモニターサービスを構成するには、『STA インストールおよび構成ガイド』の「STA サービスの構成」章を参照してください。
現在のプリファレンス設定の状態を問い合わせるには、次のコマンドを入力します。
# ./staresmonadm -Q
Configured フィールドに ”no,” が表示されている場合、リソースモニターサービスは ”アイドル” モードで実行されているため、リソースのモニタリングもレポートの送信も実行されていません。『StorageTek Tape Analytics インストールおよび構成ガイド』の説明に従って、サーバーを構成する必要があります。
構成済 STA リソースモニターサービスの出力例:
# ./staresmonadm -Q Contacting daemon...connected. Querying Preferences. Current STA Resource Monitor Service Settings: Configured [yes] Send Reports -T [13:00] Sleep Interval -i [600 sec] Alert Nagging -n [on] DB Username -U [sta_dba] DB Password -P [*********] DB Tablespace hwm -t [65%] DB Backup hwm (/dbbackup) -b [65%] DB Data hwm (/dbdata) -d [65%] Log Volume hwm (/var/log/tbi) -l [65%] Root Volume hwm (/) -z [70%] Tmp Volume hwm (/tmp) -x [80%] System Memory hwm -m [75%] Email 'From:' -f [StaResMon@localhost] Email 'To:' -r [john.doe@company.com] Email 'Subject:' -s [STA Resource Monitor Report] Output File -o [/var/log/tbi/db/staresmon.csv]
現在のプリファレンス設定をクリアするには、次のコマンドを入力します。
# ./staresmonadm -C
リソースモニターサービスが未構成の状態になり、”アイドル” 状態に戻ります。『StorageTek Tape Analytics インストールおよび構成ガイド』の説明に従って、新規の設定を指定できます。例:
# ./staresmonadm -C Contacting daemon...connected. Clearing Preferences. Done. Current STA Resource Monitor Service Settings: Configured [no] Send Reports -T [00:00] Sleep Interval -i [300 sec] Alert Nagging -n [off] DB Username -U [] DB Password -P [] DB Tablespace hwm -t [-1%] DB Backup hwm (/dbbackup) -b [-1%] DB Data hwm (/dbdata) -d [-1%] Log Volume hwm (/var/log/tbi) -l [-1%] Root Volume hwm (/) -z [-1%] Tmp Volume hwm (/tmp) -x [-1%] System Memory hwm -m [-1%] Email 'From:' -f [StaResMon@localhost] Email 'To:' -r [] Email 'Subject:' -s [STA Resource Monitor Report] Output File -o [/var/log/tbi/db/staresmon.csv]
章 4, "パスワード管理."を参照してください
リソースモニターレポートは、staresmonadm という STA リソースモニターサービス管理ユーティリティーを使用して構成します。STA リソースモニターサービスを構成するには、『STA インストールおよび構成ガイド』の「STA サービスの構成」章を参照してください。
リソースモニターでは次の 2 種類のレポートを作成できます。
リソースモニター標準レポートは 1 日 1 回、staresmonadm -T オプションで指定された時間付近で送信されます。時間を設定しなかった場合、午前 0 時を過ぎてから最初のスキャン時にレポートが送信されます。このサービスの構成時に指定した電子メール受信者にレポートが送信されます。
レポートには次のサーバーリソースのデータが表示されます。これらのリソースのいずれかが高水位標しきい値を超えた場合、レポートに警告が表示されます。
データベーステーブル領域およびボリューム
ロギング、バックアップ、およびルートボリューム
一時ディレクトリ
システムメモリー使用率
|
注: レポートの値はマウントポイントに依存します。複数のモニター対象項目がマウントポイントを共有している場合、これらの項目のレポート値は同一になります。 |
標準レポートの例 (切り捨て後)
STA RESOURCE MONITOR STANDARD REPORT System: tbivb03 Scanned: 2013-10-24 11:30:14 Database Tablespace HWM : 60.00% Used : <0.1% MB Used : 13 MB Free : 75763 MB Total : 75776 Location : /dbdata/mysql Database Volume HWM : 60.00% Used : 6.80% MB Used : 6855 MB Free : 93939 MB Total : 100794 Directory : /dbdata/mysql ...
staresmonadm 警告の永続モード (-n) オプションが ”on”. に設定されている場合、毎スキャン後にリソース減少警告レポートが送信されます。永続モードが off の場合、警告は標準レポートにのみ表示されます。
各スキャンの間隔は Sleep Interval (-i) 属性によって決まり、このサービスの構成時に指定した電子メール受信者にレポートが送信されます。レポートには、報告された問題の解決に役立つ情報が表示されます。
リソース減少警告レポートの例
STA RESOURCE DEPLETION REPORT
System: server01
Scanned: 2013-10-24 11:34:47
************************************************************
* A L E R T S *
************************************************************
==================================================
ALERT - Low System Physical Memory
==================================================
Physical memory usage has exceeded threshold value!
HWM [1.00%]
Used [48.24%] (!)
MB Used [7757]
MB Free [8324]
MB Total [16080]
Hostname [server01]
Recommendations:
1) Shutdown unneeded processes.
2) Under Linux, try releasing unused caches using commands:
# free -m
# sync
# /sbin/sysctl -q vm.drop_caches=3
# free -m
3) Install additional memory.
STA サービスは、実行可能スクリプト、サーバーおよびクライアントアプリケーションが含まれている Java jar ファイル、構成ファイル、ダンプファイル、ロギングファイル、および累積データファイルで構成されます。このセクションでは、それらの用途と場所について説明します。
STA サービスデーモンの開始/停止スクリプト staservd とシステム実行レベルのシンボリックリンクは次の場所にあります。
/etc/init.d/staservd - メインの開始/停止スクリプト
/etc/rc0.d/K04staservd - システム停止のシンボリックリンク
/etc/rc1.d/K04staservd - システム停止のシンボリックリンク
/etc/rc2.d/S96staservd - システム開始のシンボリックリンク
/etc/rc3.d/S96staservd - システム開始のシンボリックリンク
/etc/rc4.d/S96staservd - システム開始のシンボリックリンク
/etc/rc5.d/S96staservd - システム開始のシンボリックリンク
/etc/rc6.d/K04staservd - システム停止のシンボリックリンク
staservd init スクリプトと関連するシンボリックリンクは STA インストーラによって作成されます。
Perl スクリプトである STA バックアップサービス管理ユーティリティー staservadm は、oracle.tbi.serveradm.jar ファイルに含まれている ServerAdm という Java クライアントアプリケーションを呼び出します。詳細は、"STA バックアップサービス"を参照してください。
Perl スクリプトである STA リソースモニター管理ユーティリティー staresmonadm は、oracle.tbi.resmonadm.jar ファイルに含まれている StaResMonAdm という Java クライアントアプリケーションを呼び出します。StaResMonAdm は、STA サービスデーモンと通信して実行時プリファレンスの設定とリセットを行う RMI クライアントです。詳細は、"STA リソースモニターサービス"を参照してください。
表 3-1 は、実行可能プログラムとそれらの場所を示しています。
表 3-1 実行可能プログラムの場所
| プログラム |
場所 |
|---|---|
|
STA サービスプログラム jar ファイル |
$STAHOME/common/lib/oracle.tbi.server.jar |
|
STA バックアップサービス管理ユーティリティー Java アプリケーション jar ファイル |
$STAHOME/common/lib/oracle.tbi.serveradm.jar |
|
STA バックアップサービス管理ユーティリティーユーザースクリプトファイル staservadm |
$STAHOME/common/bin/staservadm |
|
STA ResMon 管理ユーティリティー Java アプリケーション jar ファイル |
$STAHOME/common/lib/oracle.tbi.resmonadm.jar |
|
STA ResMon 管理ユーティリティー Java ユーザースクリプトファイル staresmonadm |
$STAHOME/common/bin/staresmonadm |
ここでは:
$STAHOME =/Oracle/StorageTek_Tape_Analytics
バックアップ操作に関連するファイルの種類は次のとおりです。
これらは STA サービスデーモンサーバー、STAServer、およびバックアップサービス構成ユーティリティーである ServerAdm のアクティビティーのロギングを行います。管理ログは最大 10 個のログファイルで構成され、各ログファイルのサイズは最大 1.0M バイトです。ログファイル名は "*.log.N" という形式で、"N" はログの番号です (staservd.log.0、staservadm.log.0、staservd.log.1 など)。
ログは循環方式で、たとえばログファイル staservd.log.9 がいっぱいになると、#1 のログファイルがふたたび使用されます。アクティブなログファイルは常に #0 (staservd.log.0) です。ログ #0 がいっぱいになるとファイル名がログ #1 に変更され、新しいログ #0 が開始します。デフォルトで STAServer と ServerAdm のログは次の場所にあります。
/var/log/tbi/db/backups
場所と内部ログ形式タイプ (単純 ASCII テキストまたは XML マークアップ) は、次の場所にあるロギングプロパティーファイル staservd.log.props および staservadm.log.props によって決まります。
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
ここでは:
$STAHOME =/Oracle/StorageTek_Tape_Analytics
MySQL データベースダンプファイルは、データベーススキーマとデータ内容の瞬間のスナップショットです。STA バックアップサービスは次のアクションを実行します。
24 時間に 1 回、このセクションで説明するファイルタイプの高速ダンプ (「ホットバックアップ」とも呼ばれています) を実行します
指定されたバックアップホストに最新のダンプファイルを転送します
前日の完全ダンプファイルをローカルバックアップディレクトリから削除します
現在日のダンプファイルのコピーをローカルバックアップディレクトリに書き込みます。
デフォルトで STA バックアップサービスは、ローカルダンプファイルと増分 binlog ファイルを /dbbackup/local ディレクトリに YYYYMMDD_HHMMSS.filename.sql の形式で保存します。
増分ダンプとは、データベース変更の原因となったすべてのトランザクションを記録する MySQL バイナリログ (binlog) のことです。STA バックアップサービスは binlog をメインのデータベースダンプに続く増分バックアップとして扱います。
STA 増分ダンプは、最後の完全ダンプ以降に生成されたすべてのバイナリログで構成されます。binlog を再生することで、ログに記録されている最後のトランザクション時の状態までデータベースを復元できます。復元では、最新のダンプファイルのロード後、最後のデータベースダンプ以降に生成されたすべての MySQL binlog が順番に再生されます。
binlog のバックアップでは、最後の完全ダンプ後に作成されたすべての binlog のリストが作成され、それらの各ログがバックアップサーバーに転送されます (現行ログはオープン状態のため転送されません)。
バックアップバイナリログの命名形式は、YYYYMMDD_HHMMSS.stadb-bin.log_sequence_number です。
MySQL バイナリログの場所は MySQL 設定ファイル /etc/my.cnf で定義されます。これは現在次のように設定されています。
/var/log/tbi/db/
バックアップ binlog ファイルのローカルコピーは次の場所にあります。
/dbbackup/local
バックアップサーバーに正常に転送されたすべての binlog (最新の binlog を除く) は、MySQL コマンド PURGE BINARY LOGS BEFORE NOW() を使用してパージできます。そのため、現行の binlog と現在日の完全バックアップファイルはサーバー上に残ります。
|
注意: binlog ファイルは絶対に手動で削除しないでください。 |
STA アプリケーションデータベースの復元に必要なファイルに加え、STA バックアップサービスは自身の STA サービスデーモン構成ファイルと、STA の WebLogic 構成ファイルもバックアップします。このバックアップでは、それぞれの構成ディレクトリ内のすべてのファイルとディレクトリが繰り返しバックアップされます。
構成ファイルのバックアップは 24 時間ごとに 1 回、完全 STA データベースダンプが実行されたときに実行されます。バックアップファイルの名前形式は、YYYYMMDD_HHMMSS.filename.zip.gz です。
これらのバックアップのソースとターゲットの場所は、表 3-2 のとおりです。
表 3-2 バックアップソース/ターゲットの場所
| ソースの場所 |
ローカルコピー |
リモートコピー |
|---|---|---|
|
$STAHOME/common/conf/* |
$BACKUPS/YYYYMMDD_HHMMSS.conf.zip |
$RHOST:$RDIR/YYYYMMDD_HHMMSS.conf.zip.gz |
|
$WLHOME/config/fmconfig/* |
$BACKUPS/YYYYMMDD_HHMMSS.fmconfig.zip |
$RHOST:$RDIR/YYYYMMDD_HHMMSS.fmconfig.zip.gz |
ここでは:
$STAHOME =/Oracle/StorageTek_Tape_Analytics
$WLHOME =/Oracle/Middleware/user_projects/domains/TBI
$BACKUPS =/dbdata/mysql/backups
$RHOST = バックアップサーバーの IP アドレスまたは名前
$RDIR = バックアップサーバー上のディレクトリ
モニタリング操作に関連する 2 種類のファイルがあります。
これらは STA サービスデーモンとリソースモニター管理ユーティリティーである staresmonadm のアクティビティーのロギングを行います。これらのログは最大 10 個のログファイルで構成され、各ログファイルのサイズは最大 1.0M バイトです。ログファイル名は "*.log.N" という形式で、"N" はログの番号です (staservd.log.0、staresmonadm.log.0、staservd.log.1 など)。
ログは循環方式で、たとえばログファイル staservd.log.9 がいっぱいになると、#1 のログファイルがふたたび使用されます。アクティブなログファイルは常に #0 (staservd.log.0) です。ログ #0 がいっぱいになるとファイル名がログ #1 に変更され、新しいログ #0 が開始します。デフォルトでは STA サービス、STA ResMon、および STA ResMonAdm のログはすべて次の場所にあります。
/var/log/tbi/db/backups
場所とログ形式 (単純 ASCII テキストまたは XML マークアップ) は、次の場所にあるロギングプロパティーファイル staservd.log.props および staresmonadm.log.props によって決まります。
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staresmonadm.log.props
ここでは:
$STAHOME =/Oracle/StorageTek_Tape_Analytics
ResMon はシステムをスキャンするたびに収集した値をカンマ区切り値 (CSV) ファイルとして、デフォルトの次の場所に書き込みます。
/var/log/tbi/db/staresmon.csv
このデータファイルは Excel や MySQL などのプログラムにロードできるので、時間ベースの値を元に各種の分析を行なったり、グラフを作成したりできます (リソースの減少傾向の分析など)。
|
注: ResMon CSV ファイルを STA バックアップサービスを使用してパージ、ロール、またはバックアップすることはできません。 |
staresmon.csv 内の各レコードはシステムの 1 回のスキャンを表しています。21 列レコードの形式を、表 3-3 に示します。
表 3-3 リソースモニターの CSV ファイル形式
| 列 |
ヘッダー |
説明 |
形式 |
|---|---|---|---|
|
1 |
TIMESTAMP |
スキャンの日時 |
"YYYY-MM-DD HH:MM:SS" |
|
2 |
TS_MB_MAX |
最大テーブル領域 |
123 |
|
3 |
TS_MB_USED |
使用されているデータベース領域合計 |
123 |
|
4 |
TS_MB_AVAIL |
残っているデータベース領域 |
123 |
|
5 |
TS_PCT_USED |
使用されているデータベーステーブル領域 (最大に占めるパーセンテージとして) |
12.34% |
|
6 |
TS_PCT_HWM |
データベーステーブル領域の高水位標 (最大に占めるパーセンテージとして) |
12.34% |
|
7 |
DBVOL_MB_MAX |
データベースが含まれているボリューム上の最大使用可能領域 |
123 |
|
8 |
DBVOL_MB_USED |
使用されているデータベースディスクボリューム領域合計 |
123 |
|
9 |
DBVOL_MB_AVAIL |
残っているデータベースボリュームディスク領域 |
123 |
|
10 |
DBVOL_PCT_USED |
使用されているデータベースボリュームディスク領域 (最大に占めるパーセンテージとして) |
12.34% |
|
11 |
DBVOL_PCT_HWM |
データベースボリューム高水位標 (最大に占めるパーセンテージとして) |
12.34% |
|
12 |
LOGVOL_MB_MAX |
ログが含まれているボリューム上の最大使用可能領域 |
123 |
|
13 |
LOGVOL_MB_USED |
使用されているロギングディスクボリューム領域合計 |
123 |
|
14 |
LOGVOL_MB_AVAIL |
残っているロギングボリュームディスク領域 |
123 |
|
15 |
LOGVOL_PCT_USED |
使用されているロギングボリュームディスク領域 (最大に占めるパーセンテージとして) |
12.34% |
|
16 |
LOGVOL_PCT_HWM |
ロギングボリューム高水位標 (最大に占めるパーセンテージとして) |
12.34% |
|
17 |
MEM_MB_MAX |
インストールされている最大物理 RAM |
123 |
|
18 |
MEM_MB_USED |
使用されている物理メモリーの合計 |
123 |
|
19 |
MEM_MB_AVAIL |
残っている物理メモリー領域 |
123 |
|
20 |
MEM_PCT_USED |
使用されている物理メモリー領域 (最大に占めるパーセンテージとして) |
12.34% |
|
21 |
MEM_PCT_HWM |
物理メモリー高水位標 (最大に占めるパーセンテージとして) |
12.34% |
STA サービスデーモン、バックアップサービス、バックアップサービス管理ユーティリティー、および STA リソースモニターユーティリティーのロギングは、次の場所にあるロギング構成ファイルで制御されます。
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
$STAHOME/common/conf/staresmonadm.log.props
ここでは:
$STAHOME =/Oracle/StorageTek_Tape_Analytics
ロギングファイルの内容と形式は Java Log Manager 構成プロパティーによって初期化および制御されます。これらのプロパティーは前述のロギングプロパティーファイルから読み取られます。次の情報は次の場所から入手できます。
http://download.oracle.com/javase/1.4.2/docs/api/java/util/logging/FileHandler.html。
表 3-4 ロギングファイルの内容
| プロパティー |
説明 |
StorageTek Tape Analytics の設定 |
|---|---|---|
|
java.util.logging.FileHandler.append |
FileHandler を既存のファイルに付加するかどうかを指定します (デフォルトは false) |
true |
|
java.util.logging.FileHandler.count |
循環させる出力ファイルの数を指定します (デフォルトは 1)。 |
10 |
|
java.util.logging.FileHandler.formatter |
使用する Formatter クラスの名前を指定します (デフォルトは java.util.logging.XMLFormatter) |
Java.util.logging.SimpleFormatter (可読性を得るため)。java.util.loggin.XMLFormatter はコメント化されており、使用可能です |
|
java.util.logging.FileHandler.level |
ハンドラーのデフォルトレベルを指定します (デフォルトは Level.ALL)。 |
CONFIG |
|
java.util.logging.FileHandler.limit |
1 つのファイルに書き込むおおよその最大量 (バイト) を指定します。これがゼロの場合、制限はありません。(デフォルトは制限なし)。 |
1000000 (1M バイト) |
|
java.util.logging.FileHandler.pattern |
出力ファイル名を生成する際のパターンを指定します。詳細については、次を参照してください。(デフォルトは "%h/java%u.log")。 |
/var/log/tbi/db/backups/staservd.log.%g /var/log/tbi/db/backups/staservadm.log.%g |
STA の復元手順では、最新の完全ダンプをロードし、そのダンプ後のすべてのバイナリログを再生します。
バックアップサーバーディレクトリ上にあるバックアップファイルのセットは状況によって異なります。例:
# cd /data/stabackups # ls -1 20130721_133755.conf.zip.gz 20130721_133755.fmwconfig.zip.gz 20130721_133755.stadb-bin.000024.gz 20130721_133755.stafullbackup.sql.gz 20130722_133755.conf.zip.gz 20130722_133755.fmwconfig.zip.gz 20130722_133755.stadb-bin.000024.gz 20130722_133755.stafullbackup.sql.gz 20130723_133755.conf.zip.gz 20130723_133755.fmwconfig.zip.gz 20130723_133755.stadb-bin.000021.gz 20130723_133755.stadb-bin.000022.gz 20130723_133755.stadb-bin.000023.gz 20130723_133755.stadb-bin.000024.gz 20130723_133755.stafullbackup.sql.gz
ファイル名のタイムスタンプの形式は YYYYMMDD_HHMMSS です。同じ日付のタグが付いたバイナリログはすべて、完全ダンプのロード後にデータベースで再生されます。
ここでは、次の管理タスクについて説明します。
バックアップファイルをサーバーにコピーするには:
1 日分のファイルをすべてコピーして STA サーバーに戻します。
Oracle では、/tmp ディレクトリにすべてをコピーすることをお勧めしています。たとえば、STA がサーバー sta.server.com にインストールされていて、現在バックアップサーバーにログオンしているとします。
# scp 20130723*.* sta.server.com:/tmp/. Password:
STA サーバーにルートとしてログオンし、*.gz ファイルを解凍します。例:
# cd /tmp # gunzip 20130723*.*.gz
構成ディレクトリファイルを復元するには:
すべての STA プロセスを停止します。次に、MySQL サーバーのみを再起動します。
# STA stop all # STA start mysql
STAServer および STA サービスデーモンの構成ディレクトリを解凍します。
zip ファイルは完全ディレクトリパスで作成されており、既存ファイルの復元または上書き (あるいはその両方) が可能です。zip コマンドでは、-d オプションを使用して復元パスのルートを先頭に付け直すことができます。その他のオプションを使用して、選択的な置換など、操作を細かく制御できます。
全面的な復元の場合、既存の構成ディレクトリを完全に置換する必要がありますが、最初にオリジナルをバックアップしておいてください。例:
# cd $WLSHOME # zip -vr fmwconfig.orig.zip fmwconfig # rm -rf fmwconfig # cd /tmp # unzip -X -d/ 20130723_133755.fmwconfig.zip # cd $STAHOME/common # zip -vr conf.orig.zip conf # rm -rf conf # cd /tmp # unzip -X -d/ 20130723_133755.conf.zip
ここでは:
$WLSHOME =/Oracle/Middleware/user_projects/domains/TBI/config
$STAHOME =/Oracle/StorageTek_Tape_Analytics
MySQL のルートユーザーとして、次のコマンドを実行します。
データベースをリロードするには:
stadb データベースが残っている場合は、削除します。例:
# mysql -uroot -p -e 'drop database stadb;' Password:
最新の完全ダンプをロードします。スキーマが作成されすべてのデータがインストールされます。例:
# mysql -uroot -p -e 'source 20130723_133755.stafullbackup.sql;' Password:
binlog を再生するには:
各増分ダンプ (binlog) を新しいものから順番に実行します。
MySQL サーバーで複数のバイナリログを実行する場合のもっとも安全な方法は、すべてのバイナリログを 1 つのサーバー接続で処理し、すべてのバイナリログの内容を 1 つの mysql プロセスで実行することです。
例:
# mysqlbinlog 20130723_133755.sta-binlog.000021 \ > 20130723_133755.sta-binlog.000022 \ > 20130723_133755.sta-binlog.000023 \ > 20130723_133755.sta-binlog.000024 |mysql -u root -p
別の方法として、すべてのログを 1 つのファイルに連結し、そのファイルを処理する方法もあります。
# mysqlbinlog 20130723_133755.sta-binlog.000021 > /tmp/recoversta.sql # mysqlbinlog 20130723_133755.sta-binlog.000022 >> /tmp/recoversta.sql # mysqlbinlog 20130723_133755.sta-binlog.000023 >> /tmp/recoversta.sql # mysqlbinlog 20130723_133755.sta-binlog.000024 >> /tmp/recoversta.sql # mysql -u root -p -e 'source /tmp/recoversta.sql'
|
注: コマンド行でパスワードを指定しなかった場合、処理前に MySQL からパスワードの入力を求められます。 |
次の例のようなバイナリログの処理では、複数のサーバー接続が作成される場合があります。複数の接続を使用すると、最初のログファイルに CREATE TEMPORARY TABLE 文が含まれていて、次のログにその一時テーブルを使用する文が含まれていた場合に問題が発生します。最初の mysql プロセスが終了したときに、サーバーは一時テーブルを削除します。2 つ目の mysql プロセスがそのテーブルを使用しようとしたときに、サーバーが「不明テーブル」を報告します
# mysqlbinlog binlog.000001 |mysql -u root -p #<=== DANGER!! # mysqlbinlog binlog.000002 |mysql -u root -p #<=== DANGER!!
Linux システムのルートユーザーとして、次のコマンドを入力します。
# STA start all
別の復元方法である "特定時点" の復元では、開始時点と終了時点を指定してバイナリログを再生できます。
たとえば、バイナリログの内容を調査した結果、ログエントリ #6817916 の直後に不正な操作によりいくつかのテーブルが削除されたことが判明した場合などです。前日の完全ダンプからデータベースを復元したあと、すべての STA サービスを再起動する前に、この手順で説明したコマンドを使用して、最新のバイナリログの最初のログエントリ番号 "176" からエントリ番号 "6817916" までを再生します。
ログ番号の範囲から復元するには:
すべての STA プロセスが停止していて、MySQL サービスのみが実行していることを確認します。
# STA stop all # STA start mysql
MySQL ルートユーザーとして、有効な操作を抽出します。例:
# mysqlbinlog --start-position=176 --stop-position=6817916 /var/log/tbi/db/stadb-bin.000007 > ./recover.sql
それらをデータベースに適用します。例:
# mysql -uroot -p -e 'source ./recover.sql' Password:
Linux システムルートユーザーとして、STA アプリケーションと STA サービスデーモンを再起動します。
# STA start all
特定時点の復元または増分復元の方法の詳細は、MySQL のドキュメントを参照してください。
http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery.html
