GridDB^® トラブルシューティングガイド

本書は、GridDB のトラブルシューティングに関して説明したものです。 GridDBを用いたシステムの構築時やシステムの使用時に問題が発生した場合の対処方法を記載しています。

本書は、GridDBの運用管理を行う管理者および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"コマンドを実行します。

アプリケーションプログラム等のクライアントプログラムでエラーを検出した場合、発生したエラーの内容を確認します。

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クラスの項を参照ください。

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)

       ・・・

}

運用ツール(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.

【メモ】

• 運用コマンドの情報と併せてサーバのイベントログ情報も確認することをお勧めします。

想定される問題点を以下のように発生状況で分類し、問題解決の対策をまとめました。

• クラスタ構成に関する問題点
• クラスタ拡張、縮小に関する問題点
• クライアントフェイルオーバーに関する問題点
• クラスタ障害に関する問題点
• リカバリ処理に関する問題点
• コンテナ操作に関する問題点
• TQLに関する問題点