この章では、各種 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 コマンドの詳細は、第1章 サーバー管理を参照してください。
注:
STA をインストールすると、STA サービスデーモンが STA バックアップサービスと STA リソースモニターサービスを開始しますが、未構成の状態ではこれらのサービスは有効になりません。これらのサービスを構成するには、『STA インストールおよび構成ガイド』を参照してください。STA バックアップサービスは STA サービスデーモン内で実行するサービスの 1 つです。これは STA データベースおよび鍵構成ディレクトリの自動完全バックアップを実行し、それらのファイルを STA サーバー上の指定場所または圧縮形式でリモートサーバーに書き込みます。Oracle では、リモートバックアップサーバーを構成することをお勧めしています。
続行する前に、STA サービスデーモンが実行していることを確認します。STA サービスデーモンを参照してください。
STA バックアップサービスは、/Oracle_storage_home/StorageTek_Tape_Analytics/common/bin にある staservadm という管理ユーティリティーを使用して構成します。STA バックアップサービスを構成するには、『STA インストールおよび構成ガイド』を参照してください。
STA バックアップサービスを構成すると、次のプロセスが 24 時間ごとに 1 回実行されます。
次のファイルタイプの高速ダンプ (ホットバックアップとも呼ばれています) を開始します。
MySQL データベースダンプファイル
MySQL バイナリログファイル
STA サービスデーモンおよび STA WebLogic の構成ファイル
STA サービスデーモンおよび STA バックアップサービスの管理ログ
指定されたバックアップホストにダンプファイルを転送します
前日の完全ダンプファイルを STA サーバーから削除します
現在日のダンプファイルのコピーを STA サーバー上の /sta_db_backup/local ディレクトリに書き込みます。
現在のプリファレンス設定のステータスを表示します。
# ./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 [*********]
Configured フィールドが [no] の場合、バックアップサービスはアイドルモードで実行されているため、バックアップは実行されていません。適切な構成設定を行う必要があります。詳細については、『STA インストールおよび構成ガイド』を参照してください。
現在のプリファレンス設定をクリアします。
# ./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 インストールおよび構成ガイド』を参照してください。
ターゲットサーバーにファイルが正常に送信されたかどうかを確認するには:
STA サーバー上のログを確認します。
ターゲットバックアップサーバーにログオンし、バックアップディレクトリの内容を一覧表示します。
STA サーバーにシステムの root ユーザーとしてログオンします。
ディレクトリを STA データベースのバックアップログディレクトリに変更します。
# cd /sta_logs/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
/sta_db_backup/local ディレクトリ内のファイルを一覧表示し、最新のバックアップファイルのコピーが STA サーバーにローカルで保存されていることを確認します。例:
# ls –l /dbbackup/local
20130721_133755.conf.zip 20130721_133755.fmwconfig.zip 20130721_133755.stafullbackup.zip
一覧表示されるファイルの名前の形式は、YYYYMMDD_HHMMSS.filename.zip です。
第3章 パスワード管理を参照してください。
STA リソースモニターサービスは、STA サーバーリソース (データベーステーブル領域、ディスクボリューム領域、ロギングボリュームディスク領域、物理メモリーの使用率など) に関するモニターとレポート作成を行います。
各リソースに使用率の高水位標 (HWM) を設定できます。高水位標とは、警告が発行されるときのしきい値です。しきい値に到達するか、しきい値を上回ると、標準日次リソースレポートに警告が記録され、警告を 1 人以上の指定受信者に電子メールで送信する (オプション) ことも可能です。
たとえばデータベーステーブル領域の HWM を 60% に設定した場合、許可されている最大データベーステーブル領域の 60 パーセント以上を STA アプリケーションが使用すると、STA リソースモニターがこれを検知し、テーブル領域警告を有効にして、指定受信者に電子メールを送信します。また、永続モードを有効にした場合、リソースモニターは、システムのスキャンを行うたびに警告の電子メールを送信します。
STA リソースモニターサービスは、/Oracle_storage_home/StorageTek_Tape_Analytics/common/bin にある staresmonadm という管理ユーティリティーを使用して構成します。STA リソースモニターサービスを構成するには、『STA インストールおよび構成ガイド』を参照してください。
現在のプリファレンス設定の状態を問い合わせるには、次のコマンドを入力します。
# ./staresmonadm –Q
Configured フィールドに「no」が表示されている場合、リソースモニターサービスは「アイドル」モードで実行されているため、リソースのモニタリングもレポートの送信も実行されていません。サーバーを構成する必要があります。詳細については、『STA インストールおよび構成ガイド』を参照してください。
構成済 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
リソースモニターサービスが未構成の状態になり、アイドル状態に戻ります。新しい設定を指定できます。詳細については、『STA インストールおよび構成ガイド』を参照してください。例:
# ./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]
第3章 パスワード管理を参照してください。
リソースモニターレポートは、staresmonadm という 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 とシステム実行レベルのシンボリックリンクは次のディレクトリにあります。このスクリプトと関連するシンボリックリンクは STA インストーラによって作成されます。
/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 - システム停止のシンボリックリンク
Perl スクリプトである STA バックアップサービス管理ユーティリティー staservadm は、oracle.tbi.serveradm.jar ファイルに含まれている ServerAdm という Java クライアントアプリケーションを呼び出します。詳細については、STA バックアップサービスを参照してください。
Perl スクリプトである STA リソースモニター管理ユーティリティー staresmonadm は、oracle.tbi.resmonadm.jar ファイルに含まれている StaResMonAdm という Java クライアントアプリケーションを呼び出します。StaResMonAdm は、STA サービスデーモンと通信して実行時プリファレンスの設定とリセットを行う RMI クライアントです。詳細については、STA リソースモニターサービスを参照してください。
表2-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_storage_home/StorageTek_Tape_Analytics
STA データベースのバックアップには次の種類のファイルが含まれます。
これらは 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 のログは次のディレクトリにあります。
/STA_logs/db/backups
STA_logs のデフォルトの場所は /var/log/tbi です。
ログの場所と内部形式 (単純 ASCII テキストまたは XML マークアップ) は、次の場所にあるロギングプロパティーファイル staservd.log.props および staservadm.log.props によって決まります。
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staservadm.log.props
ここでは:
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
MySQL データベースダンプファイルは、データベーススキーマとデータ内容の瞬間のスナップショットです。STA バックアップサービスは次のアクションを実行します。
24 時間に 1 回、このセクションで説明するファイルタイプの高速ダンプ (ホットバックアップとも呼ばれています) を実行します。
指定されたバックアップホストに最新のダンプファイルを転送します。
前日の完全ダンプファイルをローカルバックアップディレクトリから削除します。
現在日のダンプファイルのコピーをローカルバックアップディレクトリに書き込みます。
デフォルトで STA バックアップサービスは、ローカルダンプファイルと増分 binlog ファイルを /sta_db_backup/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 で定義されます。これは現在次のように設定されています。
/STA_logs/db
バックアップ binlog ファイルのローカルコピーは次の場所にあります。
/sta_db_backup/local
バックアップサーバーに正常に転送されたすべての binlog (最新の binlog を除く) は、MySQL コマンド PURGE BINARY LOGS BEFORE NOW() を使用してパージできます。そのため、現行の binlog と現在日の完全バックアップファイルはサーバー上に残ります。
注意:
binlog ファイルは絶対に手動で削除しないでください。STA アプリケーションデータベースの復元に必要なファイルに加え、STA バックアップサービスは自身の STA サービスデーモン構成ファイルと、STA の WebLogic 構成ファイルもバックアップします。このバックアップでは、それぞれの構成ディレクトリ内のすべてのファイルとディレクトリが繰り返しバックアップされます。
構成ファイルのバックアップは 24 時間ごとに 1 回、完全 STA データベースダンプが実行されたときに実行されます。バックアップファイルの名前形式は、YYYYMMDD_HHMMSS.filename.zip.gz です。
これらのバックアップのソースとターゲットの場所は、表2-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_storage_home/StorageTek_Tape_Analytics
$WLHOME = /Oracle_storage_home/Middleware/user_projects/domains/TBI
$BACKUPS =/dbdata/mysql/backups
$RHOST = バックアップサーバーの IP アドレスまたは名前
$RDIR = バックアップサーバー上のディレクトリ
モニタリング操作に関連する 2 種類のファイルがあります。
これらは STA サービスデーモンとリソースモニター管理ユーティリティーである staresmonadm のアクティビティーのロギングを行います。これらのログは最大 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 が開始します。デフォルトでは STA サービス、STA ResMon、および STA ResMonAdm のログはすべて次の場所にあります。
/STA_logs/db/backups
ログの場所と内部形式 (単純 ASCII テキストまたは XML マークアップ) は、次の場所にあるロギングプロパティーファイル staservd.log.props および staresmonadm.log.props によって決まります。
$STAHOME/common/conf/staservd.log.props
$STAHOME/common/conf/staresmonadm.log.props
ここでは:
$STAHOME =/Oracle_storage_home/StorageTek_Tape_Analytics
ResMon はシステムをスキャンするたびに収集した値をカンマ区切り値 (CSV) ファイルとして、デフォルトの次の場所に書き込みます。
/STA_logs/db/staresmon.csv
このデータファイルは Excel や MySQL などのプログラムにロードできるので、時間ベースの値を元に各種の分析を行なったり、グラフを作成したりできます (リソースの減少傾向の分析など)。
注:
ResMon CSV ファイルを STA バックアップサービスを使用してパージ、ロール、またはバックアップすることはできません。staresmon.csv 内の各レコードはシステムの 1 回のスキャンを表しています。21 列レコードの形式を、表2-3 に示します。
| 列 |
ヘッダー |
説明 |
形式 |
|---|---|---|---|
|
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
ここで、$STA_HOME は STA のインストール時に指定された STA のホーム位置です。詳細については、『STA インストールおよび構成ガイド』を参照してください。
ロギングファイルの内容と形式は、これらのファイル内の Java Log Manage プロパティーによって制御されます。表2-4 に、これらのプロパティーの概要を示します。詳細については、次のサイトにある Oracle Java SE ドキュメントを参照してください。
http://docs.oracle.com/en/java/
| プロパティー |
説明 |
STA の設定 |
|---|---|---|
|
java.util.logging.FileHandler.append |
ファイルハンドラが既存のファイルに付加するかどうかを指定します。デフォルトは 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.logging.XMLFormatter はコメント化されており、使用可能です |
|
java.util.logging.FileHandler.level |
ハンドラのデフォルトレベルを指定します。デフォルトは Level.ALL です。 |
CONFIG |
|
java.util.logging.FileHandler.limit |
1 つのファイルに書き込むおおよその最大バイト数を指定します。これがゼロの場合は、制限がないことを示します。デフォルトは制限なしです。 |
500000 (.5M バイト) |
|
java.util.logging.FileHandler.pattern |
出力ファイル名のパターンを指定します。デフォルトは "%h/java%u.log" です。 |
/STA_logs/db/backups/staservd.log.%g /STA_logs/db/backups/staservadm.log.%g ここで、STA_logs は Linux のインストール時に確立されたログの場所です。詳細については、『STA インストールおよび構成ガイド』を参照してください。 |
ログレベルは、これらのファイル内の STA ロギングプロパティーによって制御されます。表2-5 に、これらのプロパティーの概要を示します。
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 です。同じ日付のタグが付いたバイナリログはすべて、完全ダンプのロード後にデータベースで再生されます。
ここでは、次の管理タスクについて説明します。
バックアップファイルを STA サーバーにコピーするには、この手順を使用します。
1 日分のファイルをすべてコピーして STA サーバーに戻します。
Oracle では、/tmp ディレクトリにすべてをコピーすることをお勧めしています。たとえば、STA がサーバー sta.server.com にインストールされていて、現在バックアップサーバーにログオンしているとします。
# scp 20130723*.* sta.server.com:/tmp/.
Password:
STA サーバーに root としてログインします。
*.gz ファイルを解凍します。例:
# cd /tmp
# gunzip 20130723*.*.gz
構成ディレクトリファイルを復元するには、この手順を使用します。
すべての STA プロセスを停止します。次に、MySQL サーバーのみを再起動します。
# STA stop all
# STA start mysql
STAServer および STA サービスデーモンの構成ディレクトリを解凍します。
zip ファイルは完全ディレクトリパスで作成されており、既存ファイルの復元または上書きが可能です。unzip コマンドでは、–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_storage_home/Middleware/user_projects/domains/TBI/config
$STAHOME =/Oracle_storage_home/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 データベースをログ番号の範囲から復元するには、この手順を使用します。
すべての 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 のドキュメントを参照してください。