12cR1.2.1.19での変更点

Oracle NoSQL Database 12cR1.2.1.19で次の変更が行われました。

トピック

ドキュメントの変更点

このリリースには、新しいドキュメント『Oracle NoSQL Database可用性およびフェイルオーバー』が含まれます。ここでは、Oracle NoSQL Databaseを使用する際のデータの可用性に関する一般的な概念と問題を説明しています。このドキュメントの対象読者は、システム・アーキテクトと開発者です。ドキュメントの索引ページにある開発者向けの項に、新情報が記載されています。
<KVHOME>/examples/avroにあるAvroバインディングを例にした、.avscファイルをクラスパスに追加する手順を明確化しました。.avscファイルが適切に使用可能になっていない場合のエラー・メッセージを改善しました。

バグとパフォーマンスの修正

ロック・タイムアウトの内部パラメータを500ミリ秒から10秒に増やしました。NoSQL DBではデータ・アクセスにデッドロックが発生しないため、小さい値のタイムアウト値は必要ありません。これによって一時的なネットワーク障害の際に疑似エラーが発生することがありました。[#22583]
一時的なネットワーク障害が発生している場合、またはレプリケーション・ノードの移動に数秒以上かかる場合にplan deploy-topologyコマンドを使用してストアのトポロジを変更すると、次のエラーが発生することがあります。ストア状態の整合性が失われておらず、コマンドを手動で再試行できるとしても、コマンドは通信の不調からより速やかに回復できる必要があります。
```
... [admin1] Task 2/RelocateRN ended in state ERROR with
java.lang.RuntimeException: Time out while waiting for rg4-rn1 to come
up on sn1 and become consistent with the master of the shard before
deleting the RepNode from its old home on sn4 2/RelocateRN failed.

java.lang.RuntimeException: Time out while waiting for rg4-rn1 to come
up on sn1 and become consistent with the master of the shard before
deleting the RepNode from its old home
```
コマンドの待機時間が調整され、再試行が適切に行われるようになり、レプリケーション・ノードの移動が完了したかどうかを確認できるようになりました。[#22596]
データ・ファイルを持つディレクトリが削除された場合、またはデータ・ファイルが破損した後に修復された場合に、レプリケーション・ノードが自動的に再起動しないバグを修正しました。[#22626]
セグメント化されたネットワークのスプリット・ブレイン・シナリオにおいて、クライアントの書込みリクエストが権限のあるマスターに向かうという従来の正しい動作を補強するため、さらにテストを追加しました。[#22636]
java -jar kvstore.jar pingコマンドを使用すると、ストア内で有効ではなくなったコンポーネントに関する疑似メッセージが生成される場合がありました。
```
Failed to connect to service commandService

Connection refused to host: 10.32.17.12; nested exception is:
  java.net.ConnectException: Connection refused
        SNA at hostname:localhost registry port: 6000 has no available
        Admins or RNs registered.
```
これらのメッセージは特に、デプロイされた管理サービスをホストしていないストレージ・ノードのブートストラップ管理に対して発生します。ストアの整合性はとれているため、混乱をまねくエラー・メッセージは削除されました。[#22639]
レプリケーション・ノードのマスター移動時に表示される小さなタイミング・ウィンドウを修正しました。アプリケーションの負荷が高い状態でマスターの移動が発生した場合、移動トランザクションのキャッチ・アップ・ポイントの後戻りがこのウィンドウによって誤って引き起こされる可能性がありました。その結果、シャード・マスターの移動にかかる時間が長すぎることや短すぎることがありました。移動時間が短すぎると、ターゲット・マスターの最適なキャッチ・アップが行われない可能性があります。シャードの第3のメンバーによってこれが検知されると、例外がスローされます。[#22658]
ノードがマスターからレプリカに遷移する際に、レプリケーション・ノードの停止と再起動を優先的に行います。これにより、データベース環境の更新の際のGCコストが軽減されます。[#22658]
元のターゲットが使用可能でないことが検知された場合に、データ・リクエストがすぐに再試行または転送されるよう、NoSQLクライアント・ライブラリを変更しました。これによって、レプリケーション・ノードの障害により速やかに適応できるようになりました。[#22661]

トポロジ変更の実行中に、NoSQLデプロイメントで一時的なエラーが表示される場合がありました。ストアの整合性はとれていましたが、このエラー・メッセージによって混乱が生じ、plan deploy-topologyコマンドが誤って失敗する可能性がありました。これは修正されました。[#22678]

 ... INFO [rg1-rn1] Failed pushing entire topology push to rg1-rn3
updating from topo seq#: 0 to 1001 Problem:Update to topology seq#
1001 failed ... oracle.kv.impl.fault.OperationFaultException:
  Update to topology seq# 1001 failed
    at oracle.kv.impl.rep.admin.RepNodeAdminImpl$6.execute(RepNodeAdminImpl.java:261)
    at oracle.kv.impl.fault.ProcessFaultHandler.execute(ProcessFaultHandler.java:169)
    at oracle.kv.impl.rep.admin.RepNodeAdminFaultHandler.execute(RepNodeAdminFaultHandler.java:117)

 ...INFO [rg1-rn3] Topology update skipped. Current seq #: 1001 Update seq #: 1001

メモリー不足エラーが発生したレプリケーション・ノードが自動的に再起動しないバグを修正しました。[#22679]
ストレージ・ノードがブートストラップのmemory_mbパラメータの値なしで構成されている場合に行われる、ストレージ・ノードの使用可能メモリーのデフォルトの計算を修正しました。以前は、MBではなく10進法のメガバイト単位を使用して計算していたため、レプリケーション・ノードの適正なヒープ・サイズを高く見積りすぎていました。このデフォルトの計算は、ストアがmemory_mbプロパティのブートストラップ値なしで構成されていて、memory_mbストレージ・ノード・パラメータが設定されたことがない場合にのみ使用されます。[#22687]
ストレージ・ノードがホストするレプリケーション・ノードのレプリカ/マスター状態を、より速やかに更新します。この修正は、1より大きい容量値を持ち、複数のレプリケーション・ノードをホストできるストレージ・ノードが含まれるストアでplan deploy-topologyコマンドを実行する場合に適用されます。ストレージ・ノードに対するレプリケーション・ノードの状態の通知が遅れると、マスター職責の最適な配分が保てなくなります。[#22689]
plan deploy-topologyコマンドを実行すると管理サービスが応答しなくなるバグを修正しました。この間、管理サービスのプロセスはアイドル状態になり、時折1～2秒のCPU時間を消費するだけで、管理CLIを使用して新しい接続を試みても応答しませんでした。この問題は、数百コンポーネントが含まれるような大規模なクラスタでのみ発生すると考えられます。[#22694]
plan deploy-topologyでトポロジが変更されると、レプリケーション・ノードが別のストレージ・ノードに移動します。この際に一時的なネットワーク障害が発生した場合の回復方法が改善されました。移動に関連するシャードとストレージ・ノードが使用可能で変更を受け入れる準備ができていることを確認するための事前チェック追加されました。移動の途中でネットワーク障害が発生した場合に、再試行のためにシステム管理者が発行するコマンドが使いやすくなりました。[#22722]
ストアにおいてトポロジの変更が実行されており、これに高負荷状態でのパーティション移行が必要とされている場合に、アプリケーション要求の処理が失敗するバグを修正しました。[#22778]
レプリケーション・ノードのガベージ・コレクションのデフォルト・パラメータを調整してさらに最適化しました。これにより、CPUの使用率が軽減される場合があります。[#22779]
ダウンタイムまたはネットワークの通信障害によってレプリカのレプリケーション・ノードが大幅に古くなった場合に、これを最新にしてアプリケーションのリクエストを処理できるようにするまでにかかる時間を短縮しました。以前はキャッチ・アップ・ステージを開始する前にプロセスを終了して再起動していましたが、現在は再起動をスキップするようになりました。[#22783]
リソースを使用できない場合などにレプリケーション・ノードの再起動が繰返し失敗し、ストレージ・ノードの内部キューがいっぱいになってしいまうバグを修正しました。この場合はストレージ・ノードでレプリケーション・ノードを自動的に再起動できなくなるため、リブートを行う必要があります。[#22786]
リソースの不足などによるエラーの繰返しで停止したレプリケーション・ノードが、plan start-serviceコマンドで再度有効化されても再起動しないバグを修正しました。[#22828]

再起動中のレプリケーション・ノードで次のnullポインタ例外が発生するバグを修正しました。これは一時的に発生した問題です。[#22830]

INFO [sn1] rg2-rn2: ProcessMonitor: startProcess
   INFO [sn1] rg2-rn2: ProcessMonitor: stopProcess
   SEVERE [sn1] rg2-rn2: ProcessMonitor: Unexpected exception in
MonitorThread:
        java.lang.NullPointerExceptionjava.lang.NullPointerException
        at oracle.kv.impl.sna.ProcessMonitor$MonitorThread.run(ProcessMonitor.java:404)

クライアント・ライブラリのUnknownHostExceptionとConnectIOExceptionの解析を改善したことで、より速やかにネットワークの問題を検出し、使用できないレプリケーション・ノードのセットを更新できるようになりました。[#22841]