ストアに関して発生する一般的なエラーは、入力ミスと不適切な構成です。特にデプロイメントに失敗してやり直す場合、ネットワーク・ポートの競合が発生する可能性もあります。そのような場合は、必ず不完全なストア・データと構成をすべて削除してから、残りのプロセスを強制終了します。"jps -m"によってレポートされる、ストアに関連付けられたプロセスは、次のいずれかです。
StorageNodeAgentImpl |
ManagedService |
StorageNodeAgentImplを強制終了すると、その管理対象プロセスも強制終了されます。
管理コンソールの監視タブを使用して様々なログ・ファイルを確認できます。
KVROOT/storename/log
にある詳細なログ・ファイル、およびKVROOT/*.log
のブートストラップ・プロセスのログがあります。ブートストラップ・ログは、初期起動の問題を診断する際に最も便利です。storename/log
内のログは、ストアが構成された時点で表示されます。管理プロセスに対して選択されたホスト上のログが最も詳細なログであり、ストア全体の統合ログ・ファイル(KVROOT/storename/log/storename_*.log
)が含まれています。
ログ・ファイルの各行の先頭には、メッセージの日付、重大度および発生元のコンポーネントの名前が付きます。次に例を示します。
2012-10-25 14:28:26.982 UTC INFO [admin1] Initializing Admin for store: kvstore
特定の時間のイベントの詳細な状況について検索する場合、タイムスタンプとコンポーネント名を使用して、詳細を確認するログのセクションを絞り込みます。
ログ内のエラー・メッセージには"SEVERE"と付けられているため、トラブルシューティングの際はこれを検索できます。SEVEREエラー・メッセージは、管理の「Topology」タブ、CLIのshow events
コマンド、およびping
コマンドを使用した場合にも表示されます。
これらのディレクトリには、ログ・ファイル以外に、レプリケーション・ノードのパフォーマンス・ファイルである*.perfファイルも含まれています。
一般的に、クラスタの状態を把握するためにはverify configuration
ツールを使用します。コンポーネントに接続したうえで、各コンポーネントのパラメータを管理データベースと比較してチェックします。たとえば、verify configuration
ではレプリケーション・ノードのhelperHostsパラメータが管理と一致しないことがレポートされます。この場合は、レプリケーション・ノードを起動できない理由を表していると考えられます。Verify configuration
は管理についてもチェックします。
また、構成エラーを早期に捕捉するために、KVStoreのトラブルシューティングで診断ツールを使用できます。また、このツールを使用して、たとえばOracle Supportに送信するために重要情報およびファイルをパッケージ化できます。詳細は、診断ユーティリティを参照してください。
ストアの稼働時、プラン履歴およびエラー・ログを確認すると、発生している可能性のある問題に関する情報を確認できます。
プラン履歴には、ストアに対して試行された構成または操作アクションで問題が発生したかどうかが示されます。プランが実行されて終了すると、この情報が使用可能になります。プランを実行しようとして失敗すると、そのたびにエラーがプラン履歴にレポートされます。プラン履歴は、CLIのshow plan
コマンドまたは管理の「Plan History」
タブを使用して確認できます。
他の問題は非同期に起こります。不測の障害、サービスのダウンタイムおよびパフォーマンスの問題は、管理の「Logs」タブのクリティカルなイベントの表示またはCLIのshow events
コマンドを使用して確認できます。イベントはタイムスタンプとともに表示され、問題を診断するのに十分な情報が説明に含まれていることがあります。詳細な状況が必要で、管理者がその時間に他に何が発生したのかを確認する場合もあります。
ストア全体のログには、すべてのサービスからのログ出力が統合されます。このファイルを参照すると、問題の期間のアクティビティについてより包括的に把握できることがあります。管理の「Logs」タブやCLIのlogtail
コマンドを使用して参照するか、<KVHOME>/<storename>/logディレクトリの<storename>_N.logファイルを直接参照します。管理の「Logs」タブを使用してストア全体のログ・ファイルをダウンロードすることもできます。
Oracle NoSQL Databaseでは3つのタイプのサービスを使用します。ストアが正常な状態であるためには、すべてのサービスが正しく実行されている必要があります。この3つのサービス・タイプとは、管理、ストレージ・ノードおよびレプリケーション・ノードです。ストア全体にわたって、これらのサービスのインスタンスが複数実行されている必要があります。
各サービスにはステータスがあり、次のいずれを使用しても表示できます。
管理コンソールの「Topology」タブ
管理CLIのshow topology
コマンド。
ping
コマンドの使用。
ステータス値は次のいずれかです。
STARTING
サービスを起動中です。
RUNNING
サービスは正常に実行されています。
STOPPING
サービスを停止中です。停止が指示されたときに時間のかかるアクティビティを実行しているサービスもあるため、これは時間がかかる場合があります。
WAITING_FOR_DEPLOY
サービスは起動処理中で、コマンドまたは他のサービスからの受信確認を待っています。ストレージ・ノードの場合、最初のdeploy-SNコマンドを待っています。他のサービスは、ユーザーが管理介入をしなくても、このフェーズから移行します。
STOPPED
サービスが意図的に、問題なく停止されました。
ERROR_RESTARTING
サービスはエラー状態です。Oracle NoSQL Databaseでサービスの再起動が試行されます。
ERROR_NO_RESTART
サービスはエラー状態で、自動的に再起動されません。管理介入が必要です。
UNREACHABLE
サービスが管理者からアクセスできません。このステータスが、管理者によって発行されたコマンドで表示された場合、この状態によってSTOPPEDまたはERRORの状態が隠されている場合があります。
SNがUNREACHABLEであるか、またはRNに問題があってそのSNがUNREACHABLEである場合、管理とSNの間のネットワーク接続を最初に確認する必要があります。ただし、管理しているSNAがアクセス可能で、管理対象のレプリケーション・ノードがアクセス不可の場合、ネットワークには問題がないと考えられ、問題は他にあることになります。
健全なサービスは、STARTING
から始まります。RUNNING
に移る前に少しの間WAITING_FOR_DEPLOY
になる場合があります。
ERROR_RESTARTING
およびERROR_NO_RESTART
は、詳細を確認する必要のある問題があったことを示します。UNREACHABLE
なサービスは、一時的にその状態になる場合がありますが、その状態が続く場合、実際はERROR_RESTARTING
またはERROR_NO_RESTART
の状態である可能性があります。
管理の「Topology」タブには、サービスの異常な状態のみ表示されます。RUNNING
のサービスは、その状態がタブに表示されません。
KVStoreをトラブルシューティングする際、次のコマンドが有用です。
java -Xmx256m -Xms256m -jar KVHOME/lib/kvstore.jar ping -host <host> -port <registryport>
指定されたホストとポートで実行されているストアのステータスをレポートします。このコマンドは、ストレージ・ノードに使用されているどのホストとポートのペアに対しても使用できます。
jps -m
マシンで実行されているJavaプロセスをレポートします。Oracle NoSQL Databaseプロセスが実行されている場合、このコマンドでレポートされます。
また、管理コンソールを使用してKVStoreの状態を確認できます。管理ホストで選択されている管理ポートをブラウザに指定します。