1. 変更ログ
  2. 11gR2.2.0.26での変更点

11gR2.2.0.26での変更点

Oracle NoSQL Database 11gR2.2.0.26で次の変更が行われました。

トピック

新機能

  1. このリリースでは、管理サービスのレプリカを削除する機能が追加されます。複数の管理をデプロイしている場合、次のコマンドを使用してその1つを削除できます。

    plan remove-admin -admin <adminId>

    1つの管理インスタンスのみが構成されている場合、その唯一の管理を削除することはできません。

    可用性と永続性の理由から、少なくとも3つの管理インスタンスを常に維持しておくことをお薦めします。そのため、削除の結果として3つを下回るような削除を行おうとした場合、-forceフラグを指定しないかぎりコマンドは失敗します。

    現在マスターである管理を削除しようとすると、マスター権限は別の管理に移動します。プランが中断され、後から新しいマスター管理で再実行できます。中断されたプランを再実行するには、次のコマンドを使用します。

    plan execute -id <planId>

  2. 管理CLIのverifyには、単一のストレージ・ノードにホストされているレプリケーション・ノードでメモリー設定がストレージ・ノードのメモリー容量に適合することを検証するチェックが追加されています。これは、システム管理者がデフォルトをオーバーライドして手動でレプリケーション・ノードのヒープ・サイズを設定している場合に起きうるエラーへの対策です。[#21727]

  3. 管理CLIのverifyコマンドは、検証の問題をすべて違反またはノートと分類します。違反の方が重大度が大きく、システム管理者はその問題に対処するためにシステムの調整方法を決定する必要があります。ノートは、これより重大度が低い警告です。[#21950]

バグ修正

  1. レイテンシの統計について、いくつか修正を実施しました。修正が適用されるのは、管理コンソールにおけるサービス側統計、CLIのshow perfコマンド、.perfファイルと.csvファイル、そしてKVStore..getStatsによって返されるクライアント側統計です。ただし、95%から99%の値に対する修正はクライアント側統計には適用されません。これらの値はクライアント側APIには出現しないからです。[#21763]

    • レイテンシの定義はマルチ操作要求(multiGet、multiDelete、executeなど)に応じて修正されました。これらはOp Type列に「multi」と表記され、そこにレイテンシ情報が表示されます。以前の定義は「操作ごとのミリ秒当たりのレイテンシ」で、新しい定義は「要求ごとのミリ秒当たりのレイテンシ」です。つまり、「マルチ」操作要求の場合、レイテンシは各操作ではなく要求全体に適用されるということです。「単一」操作要求の場合、レイテンシの定義は変わっていません。

    • 前述の変更にあわせて、サンプルでの要求の数を含む新しい列TotalReq.が、すべてのレイテンシ情報表示に追加されていますこれは、クライアント側統計で新しいOperationMetrics.getTotalRequestsメソッドを使用しても利用可能です。「マルチ」操作要求の場合、要求の合計数は通常、操作の合計数(TotalOpscolumn列)より小さくなります。「単一」操作要求の場合、要求の合計数と操作の合計数は等しくなります。

    • 最小レイテンシは常に最大レイテンシより小さくなる、など各サンプルでレポートされる値の一貫性を改善しました。ただし、パフォーマンスへの影響を避けるために統計は同期せずに収集され、サンプル・サイズが小さい場合にはサンプルの値の精度や整合性は常に高いとはかぎりません。

    • 95%と99%の値で、最小である95%や99%が表示されず最大レイテンシ・レコード(1000ミリ秒以下)が表示されるバグを修正しました。このバグが適用されるのは「マルチ」操作要求のみです。

    • 95%と99%の値が誤って-1と表示されることがあるバグを修正しました。これらの値は、レイテンシが1000ミリ秒未満のサンプルに対してのみ-1と表示されるべきでした。

  2. -servicerange引数によってポート範囲がmakebootconfigユーティリティに指定されている場合に、ポート範囲からポートを割り当てるように管理プロセスを変更しました。引数を指定しない場合、管理プロセスは使用可能な任意のポートを使用します。Oracle NoSQL Databaseで使用されるポートの構成の詳細は、ファイアウォールの構成を参照してください。[#21962]

  3. ローカルに格納されるトポロジが欠落するというまれなケースに対処するように、レプリケーション・ノードが変更されました。トポロジが欠落すると、TopologyManagerでjava.lang.NullPointerExceptionがスローされ、レプリケーション・ノードは開始できなくなります。[#22015]

  4. ストレージ・ノードで複数のレプリケーション・ノードをホストしている場合に、レプリケーション・ノードのメモリー計算が堅牢になっています。以前のリリースでは、plan change-paramsコマンドを使用して、複数のレプリケーション・ノードをホストしているストレージ・ノードの容量パラメータを小さくすると、レプリケーション・ノード・ヒープが極端に小さくなり、起動時にレプリケーション・ノードがエラーになっていました。トポロジのバランスを再調整する際にこの問題は修正されますが、そのときまでレプリケーション・ノードは使用できなくなっていました。デフォルトのメモリー・サイズ計算で、ストレージ・ノード上にあるレプリケーション・ノードの数が考慮されるようになり、deploy-topologyコマンドによってレプリケーション・ノードが再割当てされるとき、レプリケーション・ノードのヒープ・サイズが調整されます。[#21942]

  5. レプリケーション・ノードの起動時に、次の例のようにNullPointerExceptionの原因になるバグを修正しました。例外がレプリケーション・ノード・ログに記録され、レプリケーション・ノードは起動に失敗します。この問題が発生する条件としては、複数の異常なレプリケーション・ノードのシャットダウンに伴うシャード間でのパーティション移行などがあります。このバグが発生しても、現在のリリースにアップグレードすれば修正され、データが失われることはありません。[#22052]

    Exception in thread "main" com.sleepycat.je.EnvironmentFailureException: (JE
5.0.XX) ...  last LSN=.../... LOG_INTEGRITY: Log information is incorrect,
problem is likely persistent. Environment is invalid and must be closed.
    at com.sleepycat.je.recovery.RecoveryManager.traceAndThrowException(RecoveryManager.java:2793)
    at com.sleepycat.je.recovery.RecoveryManager.undoLNs(RecoveryManager.java:1097)
    at com.sleepycat.je.recovery.RecoveryManager.buildTree(RecoveryManager.java:587)
    at com.sleepycat.je.recovery.RecoveryManager.recover(RecoveryManager.java:198)
    at com.sleepycat.je.dbi.EnvironmentImpl.finishInit(EnvironmentImpl.java:610)
    at com.sleepycat.je.dbi.DbEnvPool.getEnvironment(DbEnvPool.java:208)
    at com.sleepycat.je.Environment.makeEnvironmentImpl(Environment.java:246)
    at com.sleepycat.je.Environment.<init>(Environment.java:227)
    at com.sleepycat.je.Environment.<init>(Environment.java:170)
    ...
Caused by: java.lang.NullPointerException
    at com.sleepycat.je.log.entry.LNLogEntry.postFetchInit(LNLogEntry.java:406)
    at com.sleepycat.je.txn.TxnChain.<init>(TxnChain.java:133)
    at com.sleepycat.je.txn.TxnChain.<init>(TxnChain.java:84)
    at com.sleepycat.je.recovery.RollbackTracker$RollbackPeriod.getChain(RollbackTracker.java:1004)
    at com.sleepycat.je.recovery.RollbackTracker$Scanner.rollback(RollbackTracker.java:477)
    at com.sleepycat.je.recovery.RecoveryManager.undoLNs(RecoveryManager.java:1026)
    ... 10 more

  6. RN上のストレージ・エンジン・キャッシュで過剰なメモリーが使用され、キャッシュの退去とI/O増加のためにパフォーマンスが低下するバグが修正されました。この問題が発生するのは、KVStore.storeIteratorまたはKVStore.storeKeysIteratorを使用するときのみでした。[#21973]

パフォーマンスその他の一般的な変更点

  1. シャードにおけるレプリカは、JEプロパティRepParams.REPLAY_MAX_OPEN_DB_HANDLESを動的に構成するようになります。これは、レプリケーション中にデータベース・ハンドルの保持に使用されるキャッシュのサイズを制御するプロパティです。キャッシュ・サイズは、現在シャードによってホストされているパーティションの数に基づいて動的に決定されます。このキャッシュ・サイズ改善によって、多数のパーティションをホストするシャードの書込みパフォーマンスが向上する可能性があります。[#21967]

  2. クライアントおよびサーバーJARファイルの名前に、リリース・バージョン番号は含まれなくなります。ファイル名は、次のようになります。

    lib/kvstore.jar
lib/kvclient.jar

    この変更により、JARファイルの名前がリリースごとに変わらなくなるため、新しいリリースへの切替えに要する作業負荷が減ります。インストール・ディレクトリの名前には、引き続きリリース・バージョン番号が含まれます。[#22034]

  3. SEVEREレベルのメッセージがログに記録されるようになり、ストレージ・エンジンの平均的なログ・クリーナ(ディスクの再利用)バックログが一定期間で増加すると、管理警告が生成されます。メッセージ・テキストの例は次のとおりです。

    121215 13:48:57:480 SEVERE [...] Average cleaner backlog has grown from 0.0 to
6.4. If the cleaner continues to be unable to make progress, the JE cache size
and/or number of cleaner threads are probably too small. If this is not
corrected, eventually all available disk space will be used.

    キャッシュ・サイズを適切に設定してこのような問題を回避する方法の詳細は、『管理者ガイド』のノード当たりのキャッシュ・サイズの決定に関する項を参照してください。[#21111]

  4. ストレージ・エンジンのログ・クリーナは、アプリケーションが書込み操作を実行していない場合であっても、ログの後半部分を削除するようになります。以前のバージョンでは、前回のアプリケーション書込みより後ろの部分のログを削除することは禁止されていました。ログ・クリーナ・バックログが存在するとき(たとえば、データ・セット・サイズや書込み速度と比較してキャッシュの構成が小さすぎるときなど)には、クリーナが連続的に動作し、ファイルの削除もそれ以降に進むこともできなくなります。[#21069]

  5. NoSQL DB 2.0.23では、R1.2.23に対するパフォーマンス・リグレッションが発生していました。kvstoreクライアント・ライブラリとレプリケーション・ノードが、システムCPU時間を大量に消費していました。このリグレッションは修正されました。[#22096]