よくある質問 - Oracle NoSQL Database


更新日時：2017年2月

一般

API


トラブルシューティング

 

一般


BE/CEとEEの違いは何ですか。


Oracle NoSQL Database Enterprise Editionには、Community EditionとBasic Editionで使用できるすべての機能と、以下の追加機能が含まれています。

  • Oracle Databaseと外部表との統合。SQLクエリを使用してOracle NoSQLデータをOracle Databaseに読み込むことができます。
  • Oracle Enterprise Manager（OEM）との統合。デプロイされたOracle NoSQL Databaseストアを監視するグラフィカル・インタフェースが提供されます。
  • NoSQLデータベース・カートリッジを使用した、Oracle Event Processing（OEP）エンジンとの統合。CQLクエリを使用してデータにアクセスできます。
  • Oracle Coherenceとの統合。Oracle NoSQL DatabaseをOracle Coherenceアプリケーションのキャッシュとして使用できるほか、アプリケーションでは、Oracle NoSQL Databaseからキャッシュされたデータに直接アクセスできます。
  • Oracle Big data Spatial and Graphとの統合。Oracle NoSQL Databaseをプロパティ・グラフと空間ベクター・データのリポジトリとして使用できます。
  • Enterprise Edition（EE）ではエンタープライズ・クラスのサポート（24時間365日体制）、Community Edition（CE）ではコミュニティ・フォーラムを使用したサポートの提供。
  • Kerberos統合のサポート。

Oracle NoSQL Database Basic Edition（BE） – このバージョンはクローズド・ソースです。Oracle Database Enterprise Editionのライセンスを購入されたすべてのお客様は、Oracle NoSQL Database Basic Editionをご使用いただけます。Oracle Database Enterprise Edition向けのOracle Supportが購入されたものとみなされるため、この製品では、すべてのサポート問題にOracle Supportが使用されます。

Oracle NoSQL Database Enterprise Edition（EE） – このバージョンはクローズド・ソースであり、オラクルから購入できます。永続ライセンス（プロセッサベース）、または名前付きユーザーに基づき、価格が設定されています。サポートは追加で購入できます。

Oracle NoSQL Database Community Edition（CE） – このバージョンはオープン・ソースであり、コミュニティ・フォーラムを使用したサポートのみが提供されます。CEは無料であり、Oracle OTN NoSQLのWebページからダウンロードできます。

  
詳しくは、Overviewページにあるデータ・シートを参照してください。
 

トップへ戻る

 

それぞれのポートはどのような状況で使用すればよいですか。


ストアのデプロイは多くのコンポーネントから成ります。各コンポーネントは独自のプロセスで実行され、プロセスは相互に通信し合っています。システム管理者は、各ストレージ・ノード（SN）上のそれぞれのプロセスの種類に対して、以下のTCP/IPポートを定義する必要があります。

  • 各SNのメイン・ポートは、ストレージ・ノード・エージェント（SNA）によって所有される"レジストリ・ポート"です。レジストリ・ポートの名前は、java -jar kvstore.jar makebootconfigコマンドの"-port"引数によって設定されます。このポートは、構成中にdeploy-sn計画でも使用されます。ドキュメントの例では、レジストリ・ポートに5000が使用されています。また、java -jar kvstore.jar kvliteコマンドでは、デフォルト値として5000が使用されます。
  •  各管理者プロセスには、HTTP接続をリスニングするポート（"管理コンソール・ポート"）が必要です（4.3以前）。管理コンソール・ポートは、java -jar kvstore.jar makebootconfigコマンドの"-admin"引数で指定され、構成中のdeploy-admin計画で使用されます（4.3以前）。

    ドキュメントの例では5001が使用されています。

  •  各SNには、永続データのレプリケーション用にSN内でホストされるレプリケーション・ノードと管理サービスが使用するポートの範囲（"HA範囲"）を割り当てる必要があります。この割り当てはSNAによって管理されます。ポートの1つが管理サービス用に予約され、残りのポートは各RNに1つずつ割り当てられます。HA範囲は、そのSNがホストするRNの最大数+1になるように設定される必要があります。
  • レジストリ・ポートは、

以下の場合に使用します。

  • ストアの初期構成時など、管理用コマンドライン・インタフェース（ java -jar kvstore.jar runadminコマンド）を使用する場合。最終的には管理プロセスと通信することになりますが、この状況で使用するポートは管理コンソール・ポート（4.3以前）ではなく、レジストリ・ポートであることに注意してください。
  • ストアに対する読取り/書込み処理を行うアプリケーション・コードにおいて、KVStoreConfigコンストラクタのhelperHostPort引数の一部に指定する場合。
  • コマンドラインでLoad、Ping、KVLiteなどのユーティリティを呼び出す際に、"-port"引数の値として指定する場合。
  • JMXサービスのポート番号としてJMXの監視が有効化されている場合。

HelloBigDataWorldやSchemaExampleなどのサンプル・プログラムと同様です。

 以下の管理Web UIのターゲットURLでは、管理コンソール・ポート（4.3以前）を使用する必要があります。

    http://node1.example.com:5001/


通常は、アクセスしようとしている種類のコンポーネントをホストしている任意のSN上のポートを指定でき、リクエストは必要に応じて、自動的かつ透過的にリダイレクトされます。管理コンソールWeb UI（4.3以前）やjava -jar kvstore.jar runadminコマンドでは、管理プロセスをホストしているSNを指定していれば、このリダイレクト処理が機能します。

SNの構成時以外は、通常はHA範囲のポートを直接参照する必要はありません。ただし、Pingの結果を調査する際や、システム・ログ・ファイルを精査する際に、HA範囲を把握していれば確実に役に立ちます。

トップへ戻る

 

NoSQL Databaseによって使用されるポートをどのように制限すればよいですか。


デプロイでは、通常はセキュリティやデータセンター・ポリシーのために、ストアを限定されたポートに制限しなければならない場合があります。限定されたポートを使用するためにストレージ・ノードで指定できるポート範囲は次の2つです。

  • -harange <start,end>を使用してmakebootconfigで指定されるhaPortRangeパラメータ。このパラメータは、レプリケーション係数が1を超える場合にレプリケーションで使用され、ストレージ・ノードの容量を十分満たすことができるポート数+1が必要です。
  • -servicerange <start,end>を使用してmakebootconfigで指定されるservicePortRangeパラメータ。この範囲は、内部（管理）サーバー間の低帯域幅通信で使用され、ストレージ・ノード・エージェント・プロセスそのものを含むストレージ・ノードによってホストされる各プロセスのサービス数に基づきます。このパラメータは任意であり、指定されない場合は匿名ポートが使用されます。 

上記の範囲は包括的なものです。

haPortRangeのサイズは上記の説明のとおりです。servicePortRangeのサイズは下記のように設定されます。

  • ストレージ・ノード・プロセスに対して3ポート
  • レプリケーション・ノードの容量 x 3（各レプリケーション・ノードが3つのポートを消費）
  • ストレージ・ノードが管理プロセスをホストしている場合は2

上記の情報を使用すると、容量が2で管理プロセスをホストするストレージ・ノードには、3 + (2 * 3) + 2 = 11のサイズ範囲が必要です。ストレージ・ノードは、この公式に基づき最小サイズが制限されます。範囲は若干大きめに設定することが推奨されます。

トップへ戻る 


NoSQL Databaseで使用されるネットワーク・インタフェースはどのように指定しますか。


makebootconfigの-hostnameパラメータは、各ストレージ・ノードによって使用されるネットワーク・インタフェースに影響を及ぼします。makebootconfigのオプション・フラグ、-hahostを使用すれば、ストレージ・ノード・パラメータのhaHostnameを設定することが可能です。このフラグは、最も多いトラフィックを抱えるサーバー間の通信チャネルに対して、追加のネットワーク・インタフェースを指定するために使用されます。-hahostのデフォルト値は-hostnameと同じ値です。

NoSQL Databaseでは、メモリはどのように割り当てられますか。


NoSQL Databaseストアのデータはレプリケーション・ノードによって管理され、メモリは主にレプリケーション・ノードによって消費されます。レプリケーション・ノードによって使用されるJavaヒープとキャッシュ・サイズは、重要なパフォーマンス要因です。デフォルトでは、レプリケーション・ノードのヒープとキャッシュは、ストレージ・ノードで使用できるメモリの量に基づき、NoSQL Databaseによって算出されます。

makebootconfigの-memory_mbフラグ、またはストレージ・ノード・パラメータのmemory_mbを使用して、ストレージ・ノードで使用できるメモリを指定することが推奨されます。memory_mbは定義しない場合は、ノードで使用できるメモリにデフォルトで設定されます。するとNoSQL Databaseでは、そのストレージ・ノードがホストするレプリケーション・ノード・プロセスのヒープとして、memory_mbの85%が使用されます。ストレージ・ノードが複数のレプリケーション・ノードをホストしている場合、メモリはすべてのレプリケーション・ノードに均等に分割されます。ストレージ・ノードがホストするレプリケーション・ノードの数が変更された場合、レプリケーション・ノードごとのメモリは動的に再計算されます。ヒープに使用される割合は、rnHeapPercentストレージ・ノード・パラメータによって制御されます。デフォルト値の85%は上書きすることもできます。

各レプリケーション・ノードではキャッシュが使用され、キャッシュ・サイズはデフォルトで、レプリケーション・ノードのヒープの70%に設定されています。デフォルト値の70%は、レプリケーション・ノード・パラメータのrnCachePercentを設定すれば上書きできます。

レプリケーション・ノードのヒープは、レプリケーション・ノード・パラメータのjavaMiscParamsで-Xmxを設定して、直接指定することもできます。同様に、レプリケーション・ノードのキャッシュは、レプリケーション・ノード・パラメータのcacheSizeを使用して直接設定できます。ただし、ストレージ・ノードのmemory_mbの設定を使用することが推奨されます。

例として、memory_mbに3000を設定することで、ストレージ・ノードが3000MBのメモリを使用するように指定しているとします。ストレージ・ノードが2つのレプリケーション・ノードをホストしている場合、各レプリケーション・ノードのヒープは(3000 * .85) / 2 = 1275MBとなります。各レプリケーション・ノードのキャッシュは(1275 * .70) = 892MBとなります。

トップへ戻る

 

管理サービスはいくつデプロイすべきですか。


NoSQL Databaseの管理プロセスは、信頼性を高めるためにレプリケートされます。ノードに障害が発生した場合でも、管理機能を継続的に使用できることが重要です。そうすることで、引き続きモニタリングやトラブルシューティング、問題の修復が可能になります。

各管理サービスは、deploy-admin計画によって作成され、NoSQL Databaseに追加されます。管理サービスにより、メタデータはレプリケートされたストアに残るため、管理ガイドの"Identify your Replication Factor"セクションで提供される情報も、デプロイすべき管理サービスの数に反映されます。永続性と可用性のために、少なくとも3つの管理サービスをデプロイすることを強く推奨します。1つまたは2つの管理サービスのみをデプロイしている場合に1つの管理サービスに障害が発生すると、多くの種類の管理コマンドを実行できなくなります。

少なくとも3つの管理サービスを実行している場合、4つ目の管理サービスをターゲットのストレージ・ノードにデプロイし、次にremove-admin計画を使用して元々ある管理サービス3つのうちの1つを削除することで、1つの管理サービスをあるストレージ・ノードから別のストレージ・ノードに容易に移行できます。 

トップへ戻る

 

同じノードに複数のストレージ・ノードを作成すべきですか。


ストレージ・ノード（SN）は、可用性とパフォーマンスのために、クラスタ内のノードごとに1つ割り当てることを強く推奨します。あるノードに複数のレプリケーション・ノード（RN）をホストするI/OおよびCPUリソースがあることを確信している場合は、ストレージ・ノードの容量パラメータを1より大きい値に設定すれば、システムはこのSNで複数のRNがホストされていることを把握します。この方法により、以下が可能になります。

  • シャードの各レプリケーション・ノードが異なるストレージ・ノードでホストされるため、シャードが障害の影響を受けにくくなる
  • レプリケーション・ノードでメモリと他のハードウェア・リソースを動的に分割する
  • ストアでの書込み操作を行うマスター・レプリケーション・ノードが、起動時、およびフェイルオーバー後にストレージ・ノード間で均等に分散されるようにする

同じノードに複数のSNがホストされている場合、そのノードに障害が発生すると複数のSNが消失し、データにアクセスできなくなる可能性があります。

ストレージ・ノードの容量パラメータは、以下の方法で設定できます。

  • makebootconfigコマンドを使用して
  • change-policyコマンドを使用して
  • plan change-paramsコマンドを使用して

同じノードに複数のSNを作成することが有用なのは、初期のプロトタイピングや実験的な導入など、極めて限定的な状況に限られます。

単一のマシンでは、ストレージ・ノードはそのルート・ディレクトリ（KVROOT）と構成ファイル名（デフォルトは"config.xml"）によって一意に認識されます。つまり、複数のSNは次の方法で作成できます。

各SNに対して一意のKVROOTを作成します。通常は、異なるノードで作成しますが、単一ノードに作成することも可能です。たとえば、すべてのSNをディレクトリ、/var/kv/storesに配置することにした場合、次の方法で複数のSNを作成して起動します。

mkdir /var/kv/stores/root1
mkdir /var/kv/stores/root2
mkdir /var/kv/stores/root3
java -jar kvstore.jar makebootconfig -root /var/kv/stores/root1 -host fooHost 
  -port 5000 -admin 5001 -harange 5005,5010 -capacity 1
java -jar kvstore.jar makebootconfig -root /var/kv/stores/root2 -host fooHost 
  -port 5020 -harange 5025,5030 -capacity 1
java -jar kvstore.jar makebootconfig -root /var/kv/stores/root3 -host fooHost 
  -port 5040 -harange 5045,5050 -capacity 1
java -jar kvstore.jar start -root /var/kv/stores/root1
java -jar kvstore.jar start -root /var/kv/stores/root2
java -jar kvstore.jar start -root /var/kv/stores/root3
 
トップへ戻る 


Oracle NoSQL Databaseの構成スクリプトはどのように記述すればよいですか。


テストの目的で、同じNoSQL Database構成を繰り返し構築したい場合があるかもしれません。管理CLIコマンドのスクリプトは、いくつかの方法で記述できます。

管理CLIでは、多くの場合、ストレージ・ノードの初期構成に使用される上述のjava -jar kvstore.jar makebootconfigなど、簡単なコマンドが使用されます。管理CLIコマンドのスクリプトは、他のUNIXコマンドと同じく容易に記述できるため、詳細な説明は割愛します。

計画の作成および実行に使用されるコマンドのうち、java -jar kvstore.jar runadminで使用される対話型コマンドのスクリプトは、2つの方法で記述できます。実行したいコマンド・シーケンスを含むファイルを作成し、そのファイルをjava -jar kvstore.jar runadmin load -file <スクリプト>を使用して、バッチで実行します。

たとえば、deploy.kvsという名前のスクリプト・ファイルには、次のようなコマンドを記述できます。

  configure -name mystore
  plan deploy-zone -name boston -rf 3
  plan deploy-sn -dcname boston -host localhost -port 5000 -wait
  plan deploy-admin -sn sn1 -port 5001 -wait（ポート引数は4.3以前にのみ適用可能）

次のコマンドにより、このスクリプトを実行します。

  java -jar kvstore.jar runadmin -host localhost -port 5000 load -file 
    deploy.kvs

コマンドのスクリプトを記述するもう1つの方法は、個々のCLIコマンドを別々のシェル・コマンド・ラインとして実行することです。このコマンドラインの後に続く引数は、単一のCLIコマンドとみなされます。

この方法では、UNIXシェルをはじめとするより有用なスクリプト言語の機能を使用できるため、NoSQL Databaseコマンドと、インタラクティブなjava -jar kvstore.jar runadmin環境では使用できない他のコマンドを柔軟に組み合わせることができます。

上記の例と同じコマンド・シーケンスは、次のシェル・スクリプトで表すことができます。

  #!/bin/sh
 
  HOST=localhost
  PORT=5000
  HTTPPORT=5001
  KVADMIN="java -jar lib/kvstore.jar runadmin -host $HOST -port $PORT"
 
  # "$KVADMIN"に続く各CLIコマンドは、runAdminの新たな呼び出しで実行されます

  $KVADMIN configure -name mystore
  $KVADMIN plan deploy-datacenter -name boston -rf 3 -wait
  $KVADMIN plan deploy-sn -dcname boston -host localhost -port $PORT -wait
  $KVADMIN plan deploy-admin -sn sn1 -port $HTTPPORT -wait


 トップへ戻る 

NoSQL DatabaseはOracle Databaseとデータをやり取りしますか。


NoSQL Databaseでは、Oracle Databaseの外部表機能を使用したレコードの取得がサポートされています。この機能により、Oracle Databaseからクエリを実行して、NoSQL Databaseからレコードを取得することが可能です。詳細については、『Accessing Oracle NoSQL Database with Oracle External Tables Cookbook』（http://docs.oracle.com/cd/NOSQL/html/examples/externaltables/cookbook.html）、oracle.kv.exttabパッケージのJavadoc、およびサンプル・プログラムを参照してください。

 

Oracle Big Data Spatial and GraphとOracle NoSQL Databaseはどのように統合されますか。


Oracle Big Data Spatial and Graphには、2つの主要コンポーネントが搭載されています。1つは、高パフォーマンスでパラレルな40ものインメモリ分析機能（PGX）を使用した分散型プロパティ・グラフ・データベースです。もう1つは、相互の距離や、境界内や地域内に存在するかどうかに基づきデータを評価し、地理空間地図データやイメージを処理および視覚化するさまざまな空間分析機能とサービスです。Oracle NoSQL Databaseは、プロパティ・グラフと空間ベクター・データのリポジトリとして使用できます。Big Data Spatial and Graphは、分散アーキテクチャのほか、2次索引、パラレル・スキャン、カスタマイズされたスキャン、親/子表、セキュアなデプロイ構成など、Oracle NoSQL Databaseのパフォーマンスとセキュリティ機能の利点を享受します。


API

 

どのように複数の主要鍵を使用して鍵のサブツリーを効率的に削除できますか。

 

KVStore.multiDelete()メソッドにより、サブツリー全体を削除できますが、1度に指定できる（完全な）主要鍵は1つのみです。

階層の主要鍵の上位部分を含むより大規模なサブツリーを削除するには、storeKeysIteratorを使用して削除すべき完全な各主要鍵を見つけ、それぞれに対してmultiDelete()を呼び出します。

ここで、仮にそのstoreKeysIteratorで処理が最後まで実行されるとすると、各主要鍵内の補助鍵を含め、必要なサブツリーの範囲内のすべての鍵に対して処理が繰り返されてしまいます。そのため、イテレータから最初の結果鍵のみを取得し、multiDelete()を呼び出すための主要キーの部分を抽出し、そのイテレータを破棄して新たなイテレータでこの処理を開始するのが秘訣です。1つのイテレータを使用して最後まで処理しないようにします。

以下のサンプル・コードでこの処理を説明します。

Key partialKey = ...;     // 主要鍵プリフィックス

/*
* 1つのイテレータで複数の鍵を取得することはないため、
* バッチ・サイズを大きくすると無駄になります。
*/
final int batchSize = 1;
for (;;) {
    Iterator<Key> i = kv.storeKeysIterator
        (Direction.UNORDERED, batchSize, partialKey,
         null, Depth.DESCENDANTS_ONLY);
    if (!i.hasNext()) {
        break;
    }
    Key descendant = Key.createKey(i.next().getMajorPath());
    kv.multiDelete(descendant, null,
                   Depth.PARENT_AND_DESCENDANTS);
}
 
トップへ戻る 

シーケンス値を生成するベスト・プラクティスはどのようなものですか。

 

NoSQL Databaseアプリケーションでは、ストアのレコードをシーケンスに指定することで、極めて単純な方法でシーケンスを実装できます。シーケンスを特定する鍵を1つ用意するだけです。この鍵は、アプリケーションで自由に設定できます（"app-sequence-1"など）。このレコードの値は、シーケンスで次に利用できる値であり、Long型整数です。

read-modify-write操作を使用して、次に利用できるシーケンスを読み取り、値を増加させます。値の読取りにはKVStore.get()を、書込みにはputIfVersion()を使用します。他のread-modify-write操作と同じく、putIfVersion()が失敗に終わった場合は、別のクライアントがその値を更新したということです。そのような場合は、read-modify-write操作を再度実行する必要があります。

シーケンスは1ずつ増加させるのではなく、たとえば500など、より大きな値で増加させます。そうすることで、シーケンス値のブロック（範囲）がクライアントに効果的に割り当てられます。次にクライアントは、シーケンス値のこの範囲を"キャッシュ"し、この範囲のレコード鍵を割り当てる必要があります。キャッシュされた値がすべて割り当てられたら、別のread-modify-write操作を実行します。

単一のシーケンス・レコードは、複数のクライアント間の単一の競合ポイントとなりますが、この潜在的なパフォーマンス問題は、上記で説明したように、より大規模なブロックでシーケンスを割り当てることで対処できます。レコードの種類ごと、鍵の範囲ごとなど、さまざまな目的で複数の独立したシーケンスを割り当てることもできます。
 

トップへ戻る

 

どのようにAvro共用体を使用してオプションのフィールドをエンコードできますか。

 

Avroでオプションのフィールドを宣言するには、Avro共用体を使用します。次に例を示します。

{
     "name":"data",
     "type":["null","string"],
     "default":"null"
}

上記の例では、"data"フィールドのタイプは、"文字列"と"null"のどちらでも構いません。タイプを"null"にすると、オプションのフィールドになります。

この方法で共用体を使用する場合は、共用体は次の2つのうちのいずれかの方法により、JSONでエンコードされることに注意してください。

  • タイプが"null"の場合、フィールドはJSONのnullとしてエンコードされます。

  • "null"でない場合、名前/値のペアを1つ持ち、名前がタイプ名、値が再帰的にエンコードされた値であるJSONオブジェクトとしてエンコードされます。Avroの名前付きタイプ（レコード、固定、またはenum）には、ユーザー指定の名前が使用されます。その他のタイプには、タイプ名が使用されます。

たとえば、次の共用体スキーマ、

["null", "string", "Foo"]

（"Foo"はレコード名）を使用するには、次のようにエンコードします。

  • "null"は"null"

  • 文字列"a"は{"string" : "a"}

  • Fooインスタンスは{"Foo" : {...}}（{...}は、Fooレコード・インスタンスのJSONエンコーディングを表します）

つまり、先ほど触れた"data"タイプを文字列としてエンコードするには、以下を使用します。

{"data":{"string":"My Data String"}}

同じフィールドをFooレコード・インスタンスとしてエンコードするには、以下を使用します。

{"data":{"Foo":{...}}   

（'{...}'には実際のFooレコードのエンコーディングを入力します）

同じフィールドをnullフィールドとしてエンコードするには、以下を使用します。

{"data":null}
 
トップへ戻る 

実行時例外と確認済みの例外について説明してください。

 

クライアントAPIで定義されているほとんどの例外は、実行時例外です。確認済みの例外を使用しない設計上の方針や理由があるのでしょうか。

確認済みの例外は、ある意味、異なる種類の戻り値であるため、常に直接のコール元によって処理される必要がある場合に限って適切です。これらは、"コンティンジェンシ"と呼ばれます。たとえば、oracle.kv.OperationExecutionExceptionには、複数操作のリクエストにおける操作の戻り値に関する情報が含まれます。コンティンジェンシ例外は確認済みの例外です。戻り値を処理するように、コール元がコンティンジェンシ例外を明示的に処理することが要求されるためです。

"障害"と呼ばれる他の例外は、コール元が直接処理できない問題の結果であることが一般的であり、通常は異常なイベントによって発生します。操作が再試行される場合もありますが、たいていは（直接のコール元ではなく）より上層で対処されます。直接のコール元によって対処されないため、これらは実行時例外です。クライアント・アプリケーションのすべてのメソッドの混乱は、これらのメソッドとは関係のない例外のスロー宣言によって回避されます。

現在のところ、NoSQL Databaseの唯一のコンティンジェンシ（確認済みの）例外はOperationExecutionExceptionであり、それ以外の例外は、障害（実行時）例外です。各例外は、oracle.kv.FaultExceptionまたはoracle.kv.ContingencyExceptionのいずれかを拡張し、この特性を明確にします。

コンティンジェンシ例外および障害例外に関する一般的な情報については、こちらに記載されています。

近年（過去数年）、大半のプログラマーの間では実行時例外が好まれており、最近設計されたほとんどのプログラミング言語には、確認済みの例外機能がないことに注意してください。ですから、実行時例外が現在の傾向です。もちろん、すべてのプログラマーやプログラミング言語の設計者がこのトピックに同意するわけではありません。NoSQL Databaseでは、必要に応じてさらなるコンティンジェンシ例外を追加する選択肢を残しています。

 

トップへ戻る

 

どのように数値の鍵を実装し、適切にソートすることができますか。

 

Oracle NoSQL Databaseでは、すべての鍵は文字列として扱われるため、文字列としてソートされます。このことは、数値の鍵を持ち、その鍵を適切にソートしたいアプリケーションにとって問題となる可能性があります。数値（integer、long、doubleなど）を単純に文字列で表記しても、適切にソートされません。たとえば、次の整数値を考えてみましょう。

{1, 2, 10, 12, 1000}

上記は、これらの値を適切に昇順にソートしたものですが、単純な文字列表記でソートすると次のようになります。

{"1", "10", "1000", "12", "2"}

この問題を解決する1つの簡単な方法は、左側に文字列を埋め込み、すべての値を同じ長さにすることです。たとえば次のとおりです。

{"0001", "0002", "0010", "0012", "1000"}

こうすることで適切にソートされますが、一部のアプリケーションでは、次のような問題が発生します。

  1. あまりコンパクトではありません。コンパクトであることは、鍵の重要な属性です

  1. 負の値を扱うことができません

  1. 浮動小数点数を扱うことができません

負の値と浮動小数点数が不要な場合に使用できるもう1つの方法は、base32hexでエンコードすることです。base32hexでエンコードすれば、適切にソートされ、手作業で値を埋め込むよりも鍵は幾らかコンパクトになります。標準的な実装はありませんので、解決方法を見つける必要があります。Base64では、鍵はコンパクトになりますが、適切にソートされないため、適切にソートする必要がある場合は、エンコーディングに使用すべきでないことを言及しておきます。

幾分コンパクトで負数と浮動小数点に対応するより一般的な実装方法は、少なくとも数種類存在します。1つは、以下に示すLuceneに構築されています。

http://lucene.apache.org/core/3_0_3/api/core/index.html?org/apache/lucene/util/NumericUtils.html

別の方法は以下で説明されており、

http://jasonfager.com/770-lexi-sortable-number-strings/

以下に実装されています。

https://gist.github.com/jfager/490993#file_lexi_sortable.java

説明では、さらにコンパクトな表記も使用できるものの、その場合はアプリケーションでコーディングする必要があることに触れています。

 

トップへ戻る

 

トラブルシューティング

 

どのようにJava SE Development Kit 8, Update 121（JDK 8u121）を使用してjava.io.ObjectInputStream filterCheckエラーを修正できますか。


このトピックに関しては、Oracle Support Noteが存在します。 以下を参照してください。 http://support.oracle.com/rs?type=doc&id=2227233.1 

JavaScriptドライバを使用しているときに発生する、ポートでプロキシに接続できないというエラーはどのように解決できますか。


- CEおよびBEディストリビューションでは、プロキシを手動で起動する際にuser.securityファイルを指定します。たとえば次のとおりです。
java -cp <path>/kvclient.jar:<path>/kvproxy.jar:<path>oraclepki.jar oracle.kv.proxy.KVProxy -helper-hosts <hostname>:<port>
-store <storename> -username admin -security <path>/user.security
- EEディストリビューションではウォレットを使用しているため、クラス・パスにoraclepki.jarを設定し、さらに手動でプロキシを起動する際にuser.security
ファイルを指定します。たとえば次のとおりです。
java -cp <path>/kvclient.jar:<path>/kvproxy.jar:<path>oraclepki.jar oracle.kv.proxy.KVProxy -helper-hosts <hostname>:<port>
-store <storename> -username admin -security <path>/user.security

どのJVMを使用してOracle NoSQL Databaseを実行すればよいですか。

 

Oracle NoSQL DatabaseサーバーはJava SE 8（64ビット）以降、クライアントはJava SE 6以降と互換性があります。どちらも、Oracle Java SE 8 Update 73に対してテスト済みかつ認証済みです。バグが修正され、パフォーマンスが向上した最新のJavaリリースにアップグレードし、その利点を活用することをお勧めします。本リリースを、必要なバージョン以前のJavaとともに使用しようとすると、次のようなエラー・メッセージが表示されます。Exception in thread "main" java.lang.UnsupportedClassVersionError: oracle/kv/impl/util/KVStoreMain :Unsupported major.minor version 52.0

UnsupportedClassVersionErrorの例外が発生するのはなぜですか。

Oracle NoSQL Database Release 1および2には、Java SE 6以降のJavaランタイムが必要です。Oracle NoSQL Database Release 3にはJava SE 7以降、Oracle NoSQL Datatabase Release 4にはJava SE 8以降が必要です。 次のようなエラー・メッセージが表示された場合は、おそらく必要なバージョン以前のJavaとともに実行しようとしています。

Exception in thread "main" java.lang.UnsupportedClassVersionError:Bad version number in .class file

または

Exception in thread "main" java.lang.UnsupportedClassVersionError:
  oracle/kv/impl/util/KVStoreMain :Unsupported major.minor version 51.0 

 

トップへ戻る

 

管理計画の実行中にフィードバックを得る方法を教えてください。

管理コマンドの進捗を追跡するには、いくつかの方法があります。

  • show plan -id <id>により、コマンドの最新ステータスが表示されます。

  • show topologyコマンドにより、ストアの現在のレイアウトと、現在存在するNoSQL Databaseサービスが表示されます。

  • NoSQL Databaseサービスが作成されてオンラインになると、管理コンソールのTopologyタブ（4.3以前）がリフレッシュされます。

  • 計画が実行されている間に、Topologyタブ（4.3以前）または管理CLIからverifyコマンドを実行できます。サービスの起動中にverifyコマンドを実行すると、サービスのステータス情報が表示されます。

  • 管理コンソールのLogsタブ（4.3以前）またはCLIのlogtailコマンドを使用して、ストア全体のログを追跡できます。

 

トップへ戻る

 

エラー情報はどこで参照できますか。

 

管理計画のエラー情報は、計画の実行中と終了時に参照できます。計画の実行が失敗に終わるたびに、エラーが計画履歴に記録されます。計画履歴は、コマンドライン・インタフェース、KVAdmin（"java -jar kvstore.jar runadmin"または単に"CLI"とも呼ばれます）のshow plan -id <id>コマンド、または管理コンソールのPlans And Configurationタブ（4.3以前）で参照できます。-verboseフラグを追加すると、さらなる詳細が表示されます。

他の問題が非同期式に発生する場合があります。予期せぬ障害、サービス停止時間、パフォーマンス問題についての情報は、管理コンソールのLogsタブ（4.3以前）のcritical events displayで、またはCLIのshow eventsコマンドを使用して参照できます。タイムスタンプのあるイベントとその説明には、問題を診断するための十分な情報が含まれている場合があります。そうでない場合は、さらなるコンテキストが必要な可能性があります。管理者は、その頃に他にどのようなことが起きていたかを把握した方がいいかもしれません。

ストア全体のログは、すべてのサービスのロギング出力を統合したものです。このファイルを確認すれば、管理者は問題が発生している間のアクティビティの全体像を把握できるでしょう。このログは、管理コンソールのLogsタブ（4.3以前）から、CLIのlogtailコマンドを使用して、または直接<storename>_N.log file in the <KVHOME>/<storename>/logディレクトリで参照できます。管理コンソールのLogsタブからストア全体のログ・ファイルをダウンロードすることもできます。

 

トップへ戻る

 

.logファイルはどのようなフォーマットですか。

 

KVROOT/<store_name>/logディレクトリの.logファイルには、各NoSQL Databaseコンポーネントからのトレース・メッセージが含まれます。各行の先頭には、メッセージの日付、重大度、発行元のコンポーネント名が付加されます。たとえば次のとおりです。

10-01-11 08:39:43:548 UTC INFO [admin1] Initializing Admin for store: kvstore

行のフォーマットは、MM-dd-yy HH:mm:ss:SSS <java.util.logging.Level> [コンポーネント名] メッセージ、となります。ある時間のイベントのコンテキストをさらに参照する場合は、タイムスタンプとコンポーネント名を使用して、精査するログの範囲を絞り込みます。深刻な例外は、SEVEREログ・レベルでログに記録され、管理コンソールやCLI（java -jar kvstore.jar runadmin）の show eventsコマンドを使用して参照できます。

 

トップへ戻る

 

.perfファイルはどのようなフォーマットですか。

 

管理サービスでは、レプリケーション・ノードごとのサーバー側スループットと待機時間の統計データが収集されます。これらの統計データは、管理コンソールのTopologyタブ（4.3以前）、コマンドライン・インタフェース（CLI）のshow perfコマンド、およびマスター管理サービスのKVROOTログ・ディレクトリにある<storename>.perfファイルで参照できます。.perfファイルは、管理コンソールから検索してダウンロードすることもできます。

スループットと待機時間は、レプリケーション・ノード・パラメータのstatsIntervalによって定義された時間隔に対して算出されます。この時間隔のデフォルトは60秒です。.perfファイルの各行は、1つのレプリケーション・ノードの1つの統計時間隔に対するデータを表示します。また各行は、単一のoptypeカテゴリーにも適用されます。

SingleとMultiという2つのoptypeは、さまざまなデータ・オペレーションのパフォーマンス特性を把握するために使用されます。一部のクライアントAPIデータ・オペレーションは単一のデータ・レコードに関連し、それ以外は1つまたは複数のレコードに関連します。たとえば、KVStore.get()メソッドは単一のデータ・レコードをフェッチし、KVStore.multiGet()は1つまたは複数のレコードをフェッチします。すべてのシングル・レコード・オペレーションは集約され、Singleのoptypeとして記録されます。一方、すべてのマルチ・レコード・オペレーションは、Multiのoptypeとして記録されます。

NoSQL 2.0.25の時点では、待機時間情報はリクエストごとに算出されます。マルチ・レコード・オペレーションでは、レコードごとのオーバーヘッドを多数のレコードに分配できるため、シングル・レコード・オペレーションよりも大幅に効率性が高い可能性があります。optypeごとに統計データを保持することで、その違いを明らかにすることができます。

たとえば、アプリケーションで1つの時間隔にKVStore.get()、KVStore.put()、KVStore.putIfVersion()、およびKVStore.multiGet()のオペレーションが実行された場合、すべてのmultiGetsが1行のMulti統計として記録され、それ以外のオペレーションは、1行のSingle統計として一緒に記録されます。

各行には、以下の列が表示されます。

Resource：レプリケーション・ノードの名前
Time：統計時間隔の開始時間（フォーマットはMM/HH/YY hh:mm:ss）
OpType：SingleまたはMulti

時間隔パフォーマンス統計データ：

Total Ops：統計時間隔に実行されたそのoptypeのデータ・レコード数
PerSec：その時間隔における1秒あたりのデータ・レコード数
Total Req：Singleのoptypeでは、各時間隔のオペレーション数とリクエスト数は同じです。Multiのoptypeでは、各リクエストが複数のレコードを返す場合があるため、オペレーション数はリクエスト数と同じか、リクエスト数よりも大きくなります。
Min：その時間隔における最小のリクエスト待機時間をミリ秒で表したもの
Max：その時間隔における最大のリクエスト待機時間をミリ秒で表したもの
Avg：その時間隔における平均リクエスト待機時間をミリ秒で表したもの
95th：その時間隔におけるリクエスト待機時間を95パーセンタイルで表したもの
99th：その時間隔におけるリクエスト待機時間を99パーセンタイルで表したもの

累積パフォーマンス統計データ：

Total Ops：レプリケーション・ノード・プロセスのライフタイム中に実行されたそのoptypeのオペレーション数。レプリケーション・ノードが再起動されるごとに、累積値はリセットされます
PerSec：レプリケーション・ノード・プロセスのライフタイムにおける1秒あたりのオペレーション数
Total Req：Singleのoptypeでは、オペレーション数とリクエスト数は同じです。Multiのoptypeでは、各リクエストが複数のレコードを返す場合があるため、オペレーション数はリクエスト数と同じか、リクエスト数よりも大きくなります。
Min：レプリケーション・ノード・プロセスのライフタイムにおける最小の待機時間をミリ秒で表したもの
Max：レプリケーション・ノード・プロセスのライフタイムにおける最大の待機時間をミリ秒で表したもの
Avg：レプリケーション・ノード・プロセスのライフタイムにおける平均待機時間をミリ秒で表したもの
95th：レプリケーション・ノード・プロセスのライフタイムにおけるオペレーションの待機時間を95パーセンタイルで表したもの
99th：レプリケーション・ノード・プロセスのライフタイムにおけるオペレーションの待機時間を99パーセンタイルで表したもの

 

トップへ戻る

 

NoSQL Databaseサービスのステータスにはどのようなものがありますか。

 

NoSQL Databaseサービスは、管理、ストレージ・ノード、レプリケーション・ノードの3種類です。各サービスにはステータスがあり、それぞれのステータスは管理コンソールのTopologyタブ（4.3以前）、CLI（java -jar kvstore.jar runadmin）のshow topologyコマンド、または java -jar kvstore.jar pingで参照できます。

ステータスの値は以下のとおりです。

STARTING

サービスは起動中です

RUNNING

サービスは正常に実行されています

STOPPING

サービスは停止しています。停止には少し時間がかかる場合があります。たとえば、レプリケーション・ノードでチェックポイントが実行されている場合や、ストレージ・ノードで管理サービスがシャットダウンされている場合があります

WAITING_FOR_DEPLOY

サービスは、起動処理中にコマンドまたは他のサービスからの確認を待っています。ストレージ・ノードの場合は、最初のdeploy-SNコマンドを待っています。その他のサービスは、ユーザーの管理的な介入なしに、このフェーズから移行できるはずです

STOPPED

意図したとおりに正しく停止されました

ERROR_RESTARTING

サービスはエラーの状態であり、再起動が試みられます

ERROR_NO_RESTART

サービスはエラーの状態であり、自動的に再起動されません。ユーザーの管理的な介入が必要です

UNREACHABLE

管理者がサービスにアクセスできません。管理者が発行したコマンドでステータスを参照できる場合は、このステータスの背後にSTOPPEDまたはERRORのステータスが隠れている可能性があります

.

健全なサービスはSTARTINGで始まります。RUNNINGになる前に、短時間の間WAITING_FOR_DEPLOYに移行する場合があります。ERROR_RESTARTINGとERROR_NO_RESTARTは、調査すべき問題が存在することを表しています。サービスがUNREACHABLEのステータスになるのは一時的なものですが、このステータスが存続する場合、サービスの本来のステータスはERROR_RESTARTINGまたはERROR_NO_RESTARTである可能性があります。

Topologyタブには、異常なサービスのステータスのみが表示されることに注意してください。ステータスがRUNNINGである健全なコンポーネントのサービス・ステータスは、空白のままです。
 

トップへ戻る

 

エラーが報告された後も計画が実行されているのはなぜですか。

 

管理計画によって、非同期式に実行される複数のリモート・サービスが起動される場合があります。各計画のステップ、すなわちタスクは、task_timeoutパラメータ（デフォルトは5分）で構成された最大時間、実行される可能性があります。タスクは、結果が成功またはエラーであると確定したとき、またはタイムアウト期間が超過した場合に終了します。

非同期のリモート・サービスでエラーが発生した場合、タスクが結果を確定する前にそのエラーが直接管理コンソールに報告され、エラー・ダイアログに表示されることがあります。そのため、管理サービスではまだその計画のステータスはRUNNINGであり、計画はアクティブであるとみなされていても、ユーザーがエラーを検知する場合があります。最終的にはエラーは計画で認識され、ステータスはERRORに移行します。 

トップへ戻る

 

ストレージ・ノードのレジストリ・ポートを誤って構成しました。

 

ストレージ・ノード（SN）のレジストリ・ポートに無効な値を指定した場合、ストレージ・ノード・エージェント（SNA）は正常に起動されません。jps -mコマンドを使用してSNAを確認できず、SNAはjava -jar kvstore.jar pingコマンドに応答しません。SNのルート・ディレクトリにあるsnaboot_0.logファイルに、エラー情報が表示されます。たとえば、レジストリ・ポートが既に使用中である場合、ログには以下が表示されます。

10-03-11 22:47:59:525 EDT SEVERE [snaService] Failed to start SNA:
    Port already in use:1000; nested exception is:
java.net.BindException:Permission denied

KVROOTディレクトリを削除し、makebootconfigインストール手順を再度実行する必要があります。

 

トップへ戻る

 

ストレージ・ノードのHAポート範囲を誤って構成しました。

 

HAポート範囲（よくある質問の前半で説明しています）に無効な値を指定した場合、レプリケーション・ノード（RN）またはセカンダリ管理プロセス（Admin）をこのSNにデプロイできなくなります。この問題は、ストアまたは管理レプリカをその欠陥のあるSNに最初にデプロイしようと試みたときに発見されます。次のような状態により、RNがこのSNで起動されなかったことが分かります。

  • 管理コンソール（4.3以前）に、このRNのステータスがERROR_RESTARTINGであることを警告するエラー・ダイアログが表示されます。Topologyタブにも、このステータスが赤字で表示され、何度も再試行を行った後、RNのステータスがERROR_NO_RESTARTであることが表示されます。

  • 計画のステータスはERRORとなります。管理コンソールのPlans and Configurationタブ（4.3以前）をクリックして、またはjava -jar kvstore.jar runadminの"show plan <planId>"コマンドを使用して参照できる詳細履歴には、次のようなエラー・メッセージが表示されます。

       Attempt 1
            state:ERROR
            start time:10-03-11 22:06:12
            end time:10-03-11 22:08:12
            DeployOneRepNode of rg1-rn3 on sn3/farley:5200 [RUNNING] failed.
           ....  Failed to attach to RepNodeService for rg1-rn3, see log,
             /KVRT3/<storename>/log/rg1-rn3*.log, on host farley for more
             information.

  • 管理コンソール（4.3以前） またはCLIで参照できるクリティカル・イベント・メカニズムに、計画履歴と同じエラー情報を含む警告が表示されます。

  • 指定された.logファイル、または管理コンソールのLogsタブ（4.3以前）に表示されるストア全体のログには、次のような特定のエラー・メッセージが表示されます。

    [rg1-rn3] Process exiting
    java.lang.IllegalArgumentException:Port number 1 is invalid because the
      port must be outside the range of "well known" ports

誤った構成は次の手順で修正できます。一部の手順は、NoSQL Databaseストレージ・ノードをホストする物理的なノードで実行する必要がありますが、それ以外の手順は、管理コンソールまたは管理CLIにアクセスできる任意のノードから実行できます。

  1. 管理コンソールまたは管理CLIを使用して、誤った構成と衝突するdeploy-storeまたはdeploy-admin計画を取り消します。

  2. SNノードで、誤って構成された既存のStorageNodeAgentImplプロセスと、そのすべてのManagedProcessesを削除します。これらのプロセスには、"-root <KVROOT>"パラメータが設定されているため、他のプロセスと区別できます。

  3. SNノードで、KVROOTディレクトリのすべてのファイルを削除します。

  4. java -jar kvstore.jar makebootconfigコマンドを使用して、SNノードのKVROOTディレクトリにストレージ・ノードのブートストラップ構成ファイルを再作成します。

  5. SNノードで、java -jar kvstore.jar startを使用してストレージ・ノードを再起動します。

  6. 管理コンソールまたは管理CLIにて、deploy-sn計画を使用してストレージ・ノードを再度デプロイします。

これで、エラーが発生した時点に戻るため、当初と同じパラメータを使用してdeploy-storeまたはdeploy-admin計画を作成し、実行できます。

 

 

トップへ戻る

 


構成中にjava.net.NoRouteToHostExceptionがスローされました。

 

一部のユーザーは、構成中にjava.net.NoRouteToHostExceptionを経験しています。ターゲットのマシンに対してping（Oracle NoSQL Databaseの"ping"コマンドではなく、UnixまたはWindows CLIのpingコマンドを使用）やsshを実行することは可能であるものの、Oracle NoSQL Databaseの構成が失敗に終わる場合があります。典型的な例外は次のとおりです。

[nosql@nosql0 kv-1.2.123]$ java -jar ./lib/kvstore-1.2.123.jar ping -port 5000
  -host nosql1.example.com
Exception in thread "main" java.rmi.ConnectIOException:Exception creating
connection to: nosql1.example.com; nested exception is:
        java.net.NoRouteToHostException:No route to host
        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:632)
        at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
        at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
        at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:340)
        at sun.rmi.registry.RegistryImpl_Stub.list(Unknown Source)
        at oracle.kv.util.Ping.getTopology(Ping.java:332)
        at oracle.kv.util.Ping.main(Ping.java:104)
        at oracle.kv.impl.util.KVStoreMain$8.run(KVStoreMain.java:218)
        at oracle.kv.impl.util.KVStoreMain.main(KVStoreMain.java:319)
Caused by: java.net.NoRouteToHostException:No route to host
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.AbstractPlainSocketImpl.doConnect
         (AbstractPlainSocketImpl.java:327)
        at java.net.AbstractPlainSocketImpl.connectToAddress
         (AbstractPlainSocketImpl.java:193)
        at java.net.AbstractPlainSocketImpl.connect
         (AbstractPlainSocketImpl.java:180)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:384)
        at java.net.Socket.connect(Socket.java:546)
        at java.net.Socket.connect(Socket.java:495)
        at java.net.Socket.(Socket.java:392)
        at java.net.Socket.(Socket.java:206)
        at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket
         (RMIDirectSocketFactory.java:40)
        at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket
         (RMIMasterSocketFactory.java:146)
        at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:613)
        ...8 more
[nosql@nosql0 kv-1.2.123]$

通常は、使用されている1つまたは複数のマシンでiptablesが実行されていることが原因です。iptablesの設定を確認するには、iptables -L -nを実行します。次のような出力が表示されます。

[root@nosql1 init.d]# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,
ESTABLISHED
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp
dpt:22
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with
icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with
icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
[root@nosql1 init.d]#

この問題を回避するには、Oracle NoSQL Database用に構成したポートを越えて通信できるようにするルールを作成する必要があります。iptablesが原因かどうかを確かめる簡単な方法は、iptablesを一時的にシャットダウンすることです（ただし、これによりファイアウォール・ルールが無効になるため、セキュリティ問題が発生する可能性があることに注意してください）。

この内容について、 Johan Louwersに感謝します。

 

トップへ戻る

 

java.rmi.ConnectException: Connection refused to hostはどのような意味ですか。

 

show plan -id <id>コマンドを使用すると、計画のステータスと、発生したエラーがすべて表示されます。エラー・セクションにこの例外が表示されている場合、管理サービスはコマンドの実行を試みているものの、NoSQL Databaseコンポーネントの1つにアクセスできない状態にあることを意味します。

最初の手順として、show plan -id <id>コマンドを使用してエラー情報を表示させ、起動できなかったコンポーネントによって表示されているエラーを確認します。この問題は、起動できなかったレプリケーション・ノードが原因である場合がほとんどです。よくある問題として、レプリケーション・ノード・プロセスに十分なメモリがない、カスタムのJVM構成でのタイプミス、既にポートが使用中である、などが挙げられます。

この最初の手順で問題が表示されない場合、次の手順はストアの全体的なステータスを確認することです。これを行うには、show topologyコマンドを実行し、続いてverifyコマンドを実行します。show topologyコマンドによりストアのレイアウトが表示され、verifyにより各コンポーネントのステータスが検証されます。アクセスできないコンポーネントには、UNREACHABLEのステータスが表示されます。

次の手順は、NoSQLのログ・ファイルで、アクセスできないコンポーネントに関するより詳細なエラー情報を確認することです。まず集約されたストア全体のログを確認します。このログは、管理サービスをホストしているノードのKVROOT/<storename>/logs/<storename>*.logです。このログには、ストアのあらゆるコンポーネントの情報が表示されます。

仮に、ストレージ・ノードsn3で、レプリケーション・ノードrg1-rn3が反応しないとします。<storename>.logで、これらのコンポーネントによって作成されたエントリを確認します。各ログ・エントリの先頭には、ログ・メッセージを発行したコンポーネントの名前が付加されています。場合によっては、集約されたストア全体のログに含まれる情報が多すぎることや、コンポーネントからの情報が管理サービスに送信されなかったために、この集約されたログに含まれないことがあります。そのような場合は、ホストの<KVROOT>/<storename>/logsディレクトリに存在するレプリケーション・ノードやストレージ・ノードのログを直接参照すると有用です。

最初のデプロイで問題が発生した場合に特に有用なのは、ストレージ・ノードのログを参照し、そのノードのストレージ・ノード・エージェントが適切に作成され、プロセスがインストールの指示に従って期待どおりに起動されていることを確認することです。

 

トップへ戻る

 

ログにJVM warning: Failed to reserve shared memoryが表示されています。

 

デフォルトでは、NoSQL DatabaseはJVMのオプション、" -XX:+UseLargePages"を使用してレプリケーション・ノードのプロセスを起動しているため、このプロセスではラージ・ページのOSオプションが有効です。一部のJVMではラージ・ページがサポートされておらず、この警告が発せられます。警告は助言的なものであり、ストアは使用可能です。

jconsoleにNoSQL DatabaseのMBeansが表示されないのはなぜですか。

 

まず、管理ガイドの第8章に記されているように、JMXエージェントを有効化したことを確認してください。

MBeansは、ストレージ・ノードのJMXエージェントによって、ストレージ・ノード・エージェントの主要レジストリ・ポート番号で使用できるようになります。また、ストレージ・ノードの管理する他のあらゆるRMIサービスでも使用されます。jconsoleにMBeansを表示させるには、jconsoleをSNAのレジストリがリスニングしているホストとポートに接続する必要があります。たとえば、次のようにjconsoleを起動できます。

jconsole node1.example.com:5000

または、引数なしでjconsoleを起動し、次に"New Connection"ダイアログで"Remote Process"を選択し、アドレス・ボックスで"node1.example.com:5000"と入力することもできます。

 

トップへ戻る

 

javax.net.ssl.SSLHandshakeExceptionはどのような意味ですか。

 

この例外は、セキュリティが有効化されたデプロイで構成に問題があることを示しています。plan deploy-snコマンドにshow planコマンドを使用した場合に、このようなエラーが発生します。次の例外、

javax.net.ssl.SSLHandshakeException:Remote host closed connection during
handshake 

は、ターゲットのストレージ・ノードがセキュリティが有効になるように構成されておらず、SSLが実行されていないことを示しています。次の例外、

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException:
Certificate signature validation failed

は、SSL証明書に互換性がないことを示しています。

セキュリティを有効化するには、最初にストレージ・ノードを構成する際に、makebootconfigユーティリティで-store-security enableまたは-store-security configureフラグを使用するか、もしくは"security-config add-security"コマンドを使用して、セキュアでないインストールにセキュリティを追加する必要があります。詳細については、セキュリティ・ガイドを参照してください。

 

トップへ戻る