1. 管理者ガイド
  2. 構成
  3. 単一のリージョン・データ・ストアの構成
  4. トラブルシューティング

トラブルシューティング

データ・ストアを表示する際の一般的なエラーは、入力および構成ミスです。特にデプロイメントに失敗してやり直す場合、ネットワーク・ポートの競合が発生する可能性もあります。データ・ストアに関連付けられたプロセスは、jps -mコマンドによってレポートされます。次に例を示します。

  • kvstore.jar start -root $KVROOT (SNAプロセス)

  • ManagedService

SNAプロセスを強制終了すると、その管理対象プロセスも強制終了されます。

$KVROOT/storename/logにある詳細なログ・ファイル、および$KVROOT/*.logのブートストラップ・プロセスのログがあります。ブートストラップ・ログは、初期起動の問題を診断する際に最も便利です。データ・ストアが構成されると、storename/log内のログが表示されます。管理プロセスに対して選択されたストレージ・ノード上のログが最も詳細なログであり、ストア全体の統合ログ・ファイル($KVROOT/storename/log/storename_*.log)が含まれています。

ログ・ファイルの各行の先頭には、メッセージの日付、重大度および発生元のコンポーネントの名前が付きます。たとえば: 

2023-05-24 14:28:26.982 UTC INFO [admin1] 
Initializing Admin for store: mystore

特定の時間のイベントの詳細な状況について検索する場合、タイムスタンプとコンポーネント名を使用して、詳細を確認するログのセクションを絞り込みます。

ログ内のエラー・メッセージにはSEVEREと付けられているため、トラブルシューティングの際はこれに対応できます。SEVEREエラー・メッセージは、CLIのshow eventsコマンドおよびpingコマンドを使用した場合にも表示されます。

ログ・ディレクトリには、ログ・ファイル以外に、レプリケーション・ノードのパフォーマンス・ファイルである*.perfファイルも含まれています。

一般的に、verify configurationはデータ・ストアの状態を理解するためのツールです。データ・ストア・コンポーネントに接続する以外に、各コンポーネントのパラメータを管理データベースと比較してチェックします。たとえば、verify configurationではレプリケーション・ノードのhelperHostsパラメータが管理と一致しないことがレポートされます。この場合は、レプリケーション・ノードを起動できない理由を表していると考えられます。Verify configurationツールでは管理についてもチェックされます。また、トポロジ内のアービタ・ノードの構成も検証します。

また、構成エラーを早期に捕捉するために、データ・ストアのトラブルシューティングで診断ツールを使用できます。また、このツールを使用して、Oracleサポートに送信できるように、重要情報およびファイルをパッケージ化できます。詳細は、診断ユーティリティを参照してください。

エラー情報の場所

データ・ストアの稼働時、プラン履歴およびエラー・ログを確認すると、発生している問題に関する情報を確認できます。

プラン履歴には、ストアに対して試行された構成または操作アクションで問題が発生したかどうかが示されます。プランが実行されて終了すると、この情報が使用可能になります。プランを実行しようとして失敗すると、そのたびにエラーがプラン履歴にレポートされます。プラン履歴は、CLIのshow planコマンドを使用して表示できます。

他の問題は非同期に起こります。不測の障害、サービスのダウンタイムおよびパフォーマンスの問題は、CLIのshow eventsコマンドを使用して確認できます。イベントはタイムスタンプとともに表示され、問題を診断するのに十分な情報が説明に含まれていることがあります。詳細な状況が必要で、管理者がその時間に他に何が発生したのかを確認する場合もあります。

ストア全体のログには、すべてのサービスからのログ出力が統合されます。このファイルを参照すると、問題の期間のアクティビティについてより包括的に把握できることがあります。CLIのlogtailコマンドを使用して参照するか、$KVHOME/<storename>/logディレクトリの<storename>_N.logファイルを直接参照します。

サービスの状態

Oracle NoSQL Databaseでは4つのタイプのサービスを使用します。ストアが正常な状態であるためには、すべてのサービスが正しく実行されている必要があります。この4つのサービス・タイプとは、管理、ストレージ・ノード、レプリケーション・ノードおよびアービタ・ノードです。ストア全体にわたって、これらのサービスのインスタンスが複数実行されている必要があります。

各サービスにはステータスがあり、次のいずれを使用しても表示できます。

  • 管理CLIのshow topologyコマンド。

  • pingコマンドの使用。

ステータス値は次のいずれかです。

名前 説明
ERROR_NO_RESTART サービスはエラー状態で、自動的に再起動されません。管理介入が必要です。
ERROR_RESTARTING サービスはエラー状態です。Oracle NoSQL Databaseでサービスの再起動が試行されます。
RUNNING サービスは正常に実行されています。
STARTING サービスを起動中です。
STOPPED サービスが意図的に、問題なく停止されました。
STOPPING サービスを停止中です。停止が指示されたときに時間のかかるアクティビティを実行しているサービスもあるため、これは時間がかかる場合があります。
SUCCEEDED プランは正常に完了しました。
UNREACHABLE サービスが管理者からアクセスできません。このステータスが、管理者によって発行されたコマンドで表示された場合、この状態によってSTOPPEDまたはERRORの状態が隠されている場合があります。SNがUNREACHABLEであるか、またはRNに問題があってそのSNがUNREACHABLEである場合、管理とSNの間のネットワーク接続を最初に確認する必要があります。ただし、管理しているSNAがアクセス可能で、管理対象のレプリケーション・ノードがアクセス不可の場合、ネットワークには問題がないと考えられ、問題は他にあることになります。
WAITING_FOR_DEPLOY サービスは起動処理中で、コマンドまたは他のサービスからの受信確認を待っています。ストレージ・ノードの場合、最初のdeploy-SNコマンドを待っています。他のサービスは、ユーザーが管理介入をしなくても、このフェーズから移行します。

健全なサービスは、STARTINGから始まります。RUNNINGに移る前に少しの間WAITING_FOR_DEPLOYになる場合があります。

ERROR_RESTARTINGおよびERROR_NO_RESTARTは、詳細を確認する必要のある問題があったことを示します。UNREACHABLEなサービスは、一時的にその状態になる場合がありますが、その状態が続く場合、実際はERROR_RESTARTINGまたはERROR_NO_RESTARTの状態である可能性があります。

有用なコマンド

KVStoreをトラブルシューティングする際、次のコマンドが有用です。 

  • java -Xmx64m -Xms64m \
-jar kvstore.tmp/kvstore.jar ping -host node01 -port 5000 \
-security USER/security/admin.security
    指定されたホストとポートで実行されているストアのステータスをレポートします。このコマンドは、ストレージ・ノードに使用されているどのホストとポートのペアに対しても使用できます。

    ノート:

    「ユーザーの作成とリモート・アクセスによるセキュリティの構成」のステップを完了していることが前提です。

  • jps -m

    マシンで実行されているJavaプロセスをレポートします。Oracle NoSQL Databaseプロセスが実行されている場合、このコマンドでレポートされます。

  • ps -eaf | grep kv

    実行中のkvstoreプロセスのリストを表示できます。