GridDB® トラブルシューティングガイド
Revision: 1309
Table of Contents
1 はじめに
1.1 本書の目的と構成
本書は、GridDB のトラブルシューティングに関して説明したものです。 GridDBを用いたシステムの構築時やシステムの使用時に問題が発生した場合の対処方法を記載しています。
本書は、GridDBの運用管理を行う管理者およびGridDBを用いたシステムの開発者や利用者の方を対象としています。
本書は、以下のような構成となっています。
- はじめに
- 問題発生状況の確認 : 詳細な状況(ログファイル)を確認する方法を説明します。
- 問題発生時の対策 : 想定される問題点とその対策の一覧を記載します。
2 問題発生状況の確認
どのような問題がどのような状況で発生したか、処理(動作)やエラーコードなどから確認します。状況確認後、「対策(対処方法)」を検討/実行します。
状況の確認方法としては、大きく処理(動作)から確認する方法とエラーコードから確認する方法があります。
- 問題発生時に実行していた処理(動作)や通知されたエラーから、問題発生時の対策の「原因」より適切なものを選択し、対策を検討します。
- 通知されたエラーコードから、問題発生時の対策の「症状」より適切なものを選し、【内容】や「原因」を確認、対策を検討します。
通知されたエラーや実行していた処理(動作)から状況が絞り込めない場合は、ログファイルよりGridDBの状況を確認します。イベントログやクライアントログなどのログファイルについては、以下を参照ください。
2.1 GridDBサーバのイベントログファイルの確認
サーバのイベントログファイルより、エラー発生の有無およびその内容を確認します。
最新のイベントログは、"gs_logs"コマンドで内容を確認することができます。
【例】
$ gs_logs -u admin/admin 2015-03-20T10:07:47.219+0900 host01 22962 INFO CHECKPOINT_SERVICE [30902:CP_STATUS] [CP_START] mode=NORMAL_CHECKPOINT, backupPath=
イベントログファイルの形式は、以下のようになっています。時刻データ等からエラー発生時のサーバの状況を確認します。
(日付時刻) (ホスト名) (スレッド番号) (ログレベル) (カテゴリ) [(エラー・トレース番号):(エラー・トレース番号名)] (メッセージ) <(詳細情報: ソースコード位置など。エラーの場合のみ)>
以前のイベントログファイルは、イベントログ格納ディレクトリ(デフォルト:"/var/lib/gridstore/log")に出力されています。ファイル名はgridstore-ログ採取日(YYYYMMDD).logです。ログ採取日が重複する場合は、シーケンシャル番号が付加されます。
【メモ】
- イベントログの出力レベルを確認する場合や変更する場合は、"gs_logconf"コマンドを実行します。
2.2 クライアントのログファイルの確認
アプリケーションプログラム等のクライアントプログラムでエラーを検出した場合、発生したエラーの内容を確認します。
Java APIを用いたクライアントプログラムでは、実行環境のクラスパスにロギングライブラリを含め、ログ出力を設定することでクライアントログをファイル出力することができます。
例えば、下記のようなログが記録されます。
【例】
15/03/25 13:07:56 INFO GridStoreLogger.Transaction: Repairing session (context=7c469c48, statement=PUT_MULTIPLE_ROWS, partition=11, statementId=1, containerId=0, sessionId=1, trialCount=0, transactionStarted=false) com.toshiba.mwcloud.gs.common.GSStatementException: [110016:TM_SESSION_UUID_UNMATCHED] Failed to operate session or transaction status (pId=11, clientId=87a89588-b6e1-4dac-bf42-92fa596b7efb:1, sessionMode=1, txnMode=1, reason=) (address=/192.168.10.10:10001, partitionId=11) ...
クライアントログにエラーが記録された時刻のサーバのイベントログを参照し、周辺のログを確認することでエラー発生時のサーバの状況を確認します。
【メモ】
- 通知時にエラーが発生した場合やトリガ処理に失敗した場合、イベントログにエラーメッセージが記録されることがあります。
- クライアントロギングの設定については、『GridDB APIリファレンス』(GridDB_API_Reference.html)のGridStoreFactoryクラスの項を参照ください。
2.3 JDBCドライバのログファイルの確認
SQLの実行など、GridDB Advanced Edition NewSQLインターフェースでエラーが発生した場合、発生したエラーの内容を確認します。
アプリケーションの実行ディレクトリの下、もしくは、アプリケーションで指定しているログ出力ディレクトリの下に、以下のログファイルが作成されます。
- JDBCドライバのログファイルは、"/NewSQLJDBC.log"です。
- エンジンのログファイルは、"/newsql-ログ採取日時(YYYYMMDDHHMMSS).log"です
デフォルトではログは出力されません。ログファイルが作成されていない場合、ログの出力レベルや出力先を設定してください。
ログの出力レベルや出力先の設定は、gs.util.Debugより行います。
①gs.util.Debugをimportします。
②setLogLevel()を用いてログの出力レベルを変更します。
setLogLevel(int ログレベル)
ログの出力レベルには以下の4つがあります。
- 3:ERROR(エラー)
- 2:WARNING(警告)
- 1:INFO(情報)
- 0:DEBUG(デバッグ)
低いレベルを設定した場合、そのレベルよりも高いレベルのログもすべて出力されます。
③setLogFilePath()を用いてログの出力先を設定します。 デフォルトは、カレントディレクトリです。
Debug.setLogFilePath(String 出力ディレクトリ)
【例】ログの出力レベルがデバッグで、ログの出力先がカレントディレクトリのjdbcLogフォルダの下の場合
import java.sql.*; import gs.util.Debug; // usage: java SampleJDBC (multicastAddress) (port) (clusterName) public class Sample { public static void main(String[] args) { Debug.setLogFilePath("jdbcLog"); Debug.setLevel(0) ・・・ }
2.4 運用コマンドのログファイルの確認
運用ツール(gs_admin)でエラーが発生した場合、運用コマンドのログファイルより発生したエラーの内容を確認します。
運用コマンドのログファイルは、"<ログ情報出力先(デフォルトは"/var/lib/gridstore/log")> /運用コマンド名.log"です。
例) "運用コマンド名.log"は、gs_startnode.logやgs_stopcluster.log、gs_stat.logなどです。
【例】gs_startnodeコマンドのログファイル ファイル名:gs_startnode.log
2014-10-20 15:25:16,876 [25444] [INFO] <module>(56) /usr/bin/gs_startnode start. 2014-10-20 15:25:16,877 [25444] [DEBUG] <module>(105) command: ['/usr/bin/gsserver', '--conf', '/var/lib/gridstore/conf'] 2014-10-20 15:25:17,889 [25444] [INFO] <module>(156) wait for starting node. (node=127.0.0.1:10040 waitTime=0) 2014-10-20 15:25:18,905 [25444] [INFO] <module>(192) /usr/bin/gs_startnode end.
【メモ】
- 運用コマンドの情報と併せてサーバのイベントログ情報も確認することをお勧めします。
3 問題発生時の対策
サーバやアプリケーションから通知されたエラーや実行していた処理(動作)等から状況を把握し、 問題点と対策一覧より適切なものを選択、対策を検討します。
3.1 発生状況毎の問題点と対策
想定される問題点を以下のように発生状況で分類し、問題解決の対策をまとめました。
- クラスタ構成に関する問題点
- クラスタ拡張、縮小に関する問題点
- クライアントフェイルオーバーに関する問題点
- クラスタ障害に関する問題点
- リカバリ処理に関する問題点
- コンテナ操作に関する問題点
- TQLに関する問題点