1. 管理者ガイド
  2. 管理手順
  3. ストレージ・ディレクトリ・サイズの管理

ストレージ・ディレクトリ・サイズの管理

ストア内のすべてのストレージ・ノードのレプリケーション・ノードごとに、ストレージ・ディレクトリ・サイズを常に指定することをお薦めします。そうすると、ストアに様々なディスク容量のハードウェアが存在する場合でも、各レプリケーション・ノードのディスクしきい値レベルが設定されます。この項では、このトピックなどについて説明します。

ディスクしきい値の管理

各ストレージ・ディレクトリの構成では使用可能なディスク領域の容量を指定することが非常に重要です。Oracle NoSQL Databaseでは、構成済のストレージ・ディレクトリ・サイズに基づいてディスク領域制限が適用されます。使用可能なディスク領域を構成しないと、使用可能なすべての領域がストアによって便宜的に使用され、空きディスク領域が5GB未満になります。システムでは、ストレージ・ノードが構成済のディスク制限を超えた場合に手動でリカバリできるように、5GBの空き領域が確保されます。ディスク使用量の監視の説明に従い、提供された統計に基づいてディスク使用率を定期的に監視してください。

ストレージ・ノードでは、使用可能なディスク領域が次の2つの目的で使用されます。

  • データの格納。

  • 予約ファイルの保存。

予約ファイルは、アクティブなレプリカ・ノードにすでにレプリケートされているデータで構成されます。このデータのコピーを格納する目的は、マスター・ノードとの接続が失われたレプリカ・ノード用に使用することです。接続が失われる一般的な理由は、レプリカ・ノードのシャットダウン、ネットワーク・パーティション・イベントの発生または別の一時的な問題の発生です。ストレージ・ノードは、主に、割り当てたディスク領域の容量を消費し、残りのディスク領域を使用して予約ファイルを保存するように設計されています。各ストレージ・ノードでは、使用可能なディスク領域が管理され、リカバリ用として5GBの空き領域が確保されます。通常は、ストレージ・ノードが使用可能なディスク容量を超えないかぎり、このディスク管理プロセスでユーザーの介入は必要ありません。

ノート:

5GBの空き領域の確保を含め、storagedirsizeで割り当てた分を超える容量をストレージ・ノード(SN)が消費している場合は、5GBを超える領域が使用可能になるまで、予約ファイル(データ・ファイルではない)を削除することによって自動的にディスク領域の解放が試みられます。ストレージ・ノードで十分な領域を解放できない場合は、ノードに対する書込み操作が一時停止されます。読取り操作は通常どおり継続されます。ノードで十分な空きディスク領域が確保された時点で、書込み操作が自動的に再開されます。

ストレージ・ノードごとにストレージ・ディレクトリ・サイズを明示的に指定することによって、ストアで消費されるディスク領域をノード単位で制限できます(ストレージ・ディレクトリ・サイズの指定を参照)。この場合、ストレージ・ノードは、必須の5GBの空き領域を残して、必要な分として構成されたすべてのディスク領域を消費します。一方、ストレージ・ディレクトリ・サイズを指定しなかった場合は、ストレージ・ノードによって、手動リカバリ用の必須の5GBを除いて完全にディスクを使い果たすまでディスク領域が使用されます。

200GBのディスクを使用したストレージ・ノードについて考えます。このディスクに対してstoragedirsizeを構成しないと、ストアは(手動リカバリ用の5GBのみを残して) 195GBまでディスク領域を消費し続けます。各ディスクに最小20GBの領域を残すことが標準ポリシーで求められる場合は、ストア・リカバリ用の5GBとは別に20GBを残し、storagedirsizeを175GBとしてストレージ・ノードを構成する必要があります。

ノードのストレージ・ディレクトリが一杯になる最も一般的な理由は、予約ファイルです。ストレージ・ノードがそのディスクしきい値を超えた場合、しきい値を下回るまで予約ファイルが削除されます。

ストレージ・ディレクトリ・サイズの指定

最初にストアをインストールする際には、makebootconfig storagedirsizeパラメータを使用して、ストレージ・ノード(SN)の容量を指定します。詳細は、KVStoreインストールの構成およびmakebootconfigを参照してください。また、SNの容量で複数のレプリケーション・ノードをサポートする場合は、該当するレプリケーション・ノードごとにストレージ・ディレクトリの場所およびストレージ・ディレクトリ・サイズを指定します。

ストアをインストールした後にストレージ容量を指定または変更するには、plan change-storagedirを使用します。plan change-storagedirを使用する場合は、新しいストレージ・ディレクトリの大きさを-storagedirsizeパラメータで指定してください。

ノート:

-storagedirパラメータを指定し、-storagedirsizeを指定しない場合、makebootconfigによって警告が表示されます。制御と追跡の両方のパラメータを常に指定します。

storagedirsizeパラメータにはlong型の値を指定する必要があり、その後にオプションで単位文字列を指定できます。使用可能な単位文字列は、KB、MB、GBおよびTBです(それぞれ1024、1024^2、1024^3、1024^4に対応)。指定可能な文字列では大/小文字は区別されません。long値と単位文字列の間の有効なデリミタは、「 」、「-」または「_」です。

次に例を示します。 

kv-> verbose
Verbose mode is now on
kv-> show topology
store=mystore  numPartitions=300 sequence=308
  zn: id=zn1 name=Manhattan repFactor=3 type=PRIMARY 
allowArbiters=false

  sn=[sn1] zn:[id=zn1 name=Manhattan] node1:9000 capacity=1 RUNNING
    [rg1-rn1] RUNNING  /storage-dir/sn1 0
              No performance info available
  sn=[sn2] zn:[id=zn1 name=Manhattan] node2:9000 capacity=1 RUNNING
    [rg1-rn2] RUNNING  /storage-dir/sn2 0
            single-op avg latency=0.0 ms   multi-op avg latency=0.0 ms
  sn=[sn3] zn:[id=zn1 name=Manhattan] node3:9000 capacity=1 RUNNING
    [rg1-rn3] RUNNING  /storage-dir/sn3 0
              No performance info available

  shard=[rg1] num partitions=300
    [rg1-rn1] sn=sn1 haPort=node1:9010
    [rg1-rn2] sn=sn2 haPort=node2:9010
    [rg1-rn3] sn=sn3 haPort=node3:9010
    partitions=1-300

kv-> plan change-storagedir -sn sn1 -storagedir /storage-dir/sn1 \
-storagedirsize "200 gb" -add -wait
Executed plan 7, waiting for completion...
Plan 7 ended successfully
kv-> plan change-storagedir -sn sn2 -storagedir /storage-dir/sn2 \
-storagedirsize "300 gb" -add -wait
Executed plan 8, waiting for completion...
Plan 8 ended successfully
kv-> plan change-storagedir -sn sn3 -storagedir /storage-dir/sn3 \
-storagedirsize "400 gb" -add -wait
Executed plan 9, waiting for completion...
Plan 9 ended successfully
kv-> show topology
store=mystore  numPartitions=300 sequence=308
  zn: id=zn1 name=Manhattan repFactor=3 type=PRIMARY 
allowArbiters=false

  sn=[sn1] zn:[id=zn1 name=Manhattan] node1:9000 capacity=1 RUNNING
    [rg1-rn1] RUNNING  /storage-dir/sn1 214748364800
              No performance info available
  sn=[sn2] zn:[id=zn1 name=Manhattan] node2:9000 capacity=1 RUNNING
    [rg1-rn2] RUNNING  /storage-dir/sn2 322122547200
            single-op avg latency=0.0 ms   multi-op avg latency=0.0 ms
  sn=[sn3] zn:[id=zn1 name=Manhattan] node3:9000 capacity=1 RUNNING
    [rg1-rn3] RUNNING  /storage-dir/sn3 429496729600
            single-op avg latency=0.0 ms   multi-op avg latency=0.0 ms

  shard=[rg1] num partitions=300
    [rg1-rn1] sn=sn1 haPort=node1:9010
    [rg1-rn2] sn=sn2 haPort=node2:9010
    [rg1-rn3] sn=sn3 haPort=node3:9010
    partitions=1-300

ノート:

ストレージ・ノードのデータがルート・ディレクトリに格納されている場合(非推奨)、plan change-storagedirのかわりに、rootDirSizeパラメータを設定します。次に例を示します。 

kv-> plan change-parameters -service sn1 -params rootDirSize=200_gb

異なるディスク容量の指定

デフォルトでは、Oracle NoSQL Databaseでは、ストア内のすべてのストレージ・ノード間でデータが均等に分散されます。事前のチェックは行われません。ストアでは、ストア内のすべてのハードウェアが同種であると想定され、すべてのストレージ・ノードに同じディスク容量が割り当てられます。

ただし、一部のストレージ・ノードに他のノードより多くのディスク容量が割り当てられた環境でストアを実行するような場合もよくあります。この場合、各ストレージ・ノードに適切なディスク容量を指定する必要があります。その結果、Oracle NoSQL Databaseでは、容量の大きいストレージ・ノードにより多くのデータが追加されるようになります。ストレージ・ノードのディスク容量を大きくすると、ワークロードが増加する可能性があることに注意してください。容量が他のストレージ・ノードよりも多いノードでは、より多くの読取りまたは書込み(あるいはその両方)のアクティビティを処理できます。追加のワークロードがあれば、それに応じてストレージ・ノードのサイズを設定してください。

ディスク使用量の監視

ストレージ・ノードがディスク使用量のしきい値(storagedirsize - 5GB)を超えた場合は、十分なディスク領域が使用可能になるまで、そのノードに対するすべての書込みアクティビティが一時停止されます。ストアでは、しきい値要件を満たすために、予約ファイルを削除することによってディスク領域が確保されます。データ・ファイルは削除されません。予約データが削除されている間も読取りアクティビティは継続されます。

ストレージ・ノードが書込みリクエストの処理を継続できるように、availableLogSize JMX統計を監視してください。これは、書込み操作に使用できる領域の量を表します。availableLogSize統計に含まれていない予約ファイルがディスク領域を大量に消費したり、その可能性があるため、この値は、必ずしも現在使用されているディスク領域の容量を表しているとはかぎりません。

予約ファイルとは、すでにレプリケートされているデータ・ファイルのうち、マスター・ノードに接続されていないノードへのレプリケーションが保留になっているファイルのことです。Oracle NoSQL Databaseではファイルが大量に予約されるため、使用可能なすべての記憶域が予約データによって頻繁に消費されます。ただし、ストレージ・ノードで書込み操作を継続できるように、必要に応じて予約データが自動的に削除されます。このため、実際のディスク使用量の監視は意味がありません。

availableLogSizeがゼロに達すると、ストレージ・ノードに対する書込みが一時停止されます。その前に、availableLogSizeがゼロに近づくのに伴い、予約データ・ファイル用の領域が徐々に減少します。その結果、長期にわたるノードの一時停止が発生した場合に、ストアのリジリエンスが著しく低下します。これは、履歴ログ・ファイルの数が減りすぎて、ノードが再び使用可能になったときに最新の情報を提供できないことが原因です。

次の表は、ディスク使用量に関するその他の役立つ統計を示しています。これらの統計は統計ファイルに格納されるか、JMX oracle.kv.repnode.envmetricタイプを使用して監視できます。(Xref)
統計 説明
availableLogSize 書込み操作に使用できるディスク領域(バイト数)。この値は、書込み操作の実行に領域が必要になるたびに自動的に削除される予約データ・ファイルを考慮して計算されます。 
free space + reservedLogSize - protectedLogSize
自動的に削除される予約ファイルが存在するため、通常、ファイル・システム内のディスク使用量の監視は意味がありません。
activeLogSize すべてのアクティブ・データ・ファイル(基本的な操作に必要なファイル)で使用されているバイト数。
reservedLogSize すべての予約データ・ファイル(クリーニング済の、保護されていない場合は削除可能なファイル)で使用されているバイト数。
protectedLogSize 保護されたすべてのデータ・ファイル(一時的に保護されていて削除できない予約ファイルのサブセット)で使用されているバイト数。
ProtectedLogSizeMap protectedLogSizeの内訳。保護エンティティの名前と保護されたサイズ(バイト数)のマップとして示されます。
TotalLogSize ディスク上のデータ・ファイルで使用されている合計バイト数(activeLogSize + reservedLogSize)。

次のリストは、一部のJMX出力の抜粋であり、各統計がどのように表示されるかを例示しています。これらの統計名にはすべて接頭辞Cleaning_が付いています。これは、これらの統計がログ・クリーニングの統計グループ(ガベージ・コレクション用)に属するものであることを示しています。 

.
.
.
"Cleaning_nRepeatIteratorReads": 0,
"Cleaning_nLNsExpired": 0,
"Cleaning_nCleanerRuns": 0,
"Cleaning_nBINDeltasDead": 0,
"Cleaning_nCleanerDisksReads": 0,
"Cleaning_protectedLogSizeMap": "",
"Cleaning_nCleanerDeletions": 0,
"Cleaning_nCleanerEntriesRead": 0,
"Cleaning_availableLogSize": 48942137344,
"Cleaning_nLNsDead": 0,
"Cleaning_nINsObsolete": 0,
"Cleaning_activeLogSize": 112716,
"Cleaning_nINsDead": 0,
"Cleaning_nINsMigrated": 0,
"Cleaning_totalLogSize": 112716,
"Cleaning_nBINDeltasCleaned": 0,
"Cleaning_nLNsObsolete": 0,
"Cleaning_nLNsCleaned": 0,
"Cleaning_nLNQueueHits": 0,
"Cleaning_reservedLogSize": 0,
"Cleaning_protectedLogSize": 0,
"Cleaning_nClusterLNsProcessed": 0,
"Node Compression_processedBins": 0,
.
.
.

CLIからpingコマンドを使用して、ストレージ・ノードに対する書込みが一時停止されているかどうかを確認できます。次の出力例では、Shard Statusはread-only:1を示しています。これは、ストレージ・ノードの1つが読取り専用モードであることを示しています。考えられる理由は、ディスクしきい値を超えたことです。 

kv-> ping
Pinging components of store istore based upon topology sequence #11
3 partitions and 3 storage nodes
Time: 2018-09-28 06:57:10 UTC   Version: 18.3.2
Shard Status: healthy:0 writable-degraded:0 read-only:1 offline:0
Admin Status: healthy
Zone [name=dc1 id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false] 
RN Status: online:1 offline:2
Storage Node [sn1] on sn1.example.com:5000 Zone: [name=dc1 
id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false] Status: RUNNING
Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
Admin [admin1] Status: RUNNING,MASTER
Rep Node [rg1-rn1] Status: RUNNING,MASTER (non-authoritative) 
sequenceNumber:39,177,477 haPort:5011 available storage size:6 GB
Storage Node [sn2] on sn2.example.com:5000 Zone: 
[name=dc1 id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false] Status: RUNNING 
Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
Rep Node [rg1-rn2] Status: RUNNING,UNKNOWN sequenceNumber:39,176,478
haPort:5010 available storage size:NOT AVAILABLE delayMillis:? catchupTimeSecs:?
Storage Node [sn3] on sn3.example.com:5000 Zone: [name=dc1 
id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false] Status: RUNNING
Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
Rep Node [rg1-rn3] Status: RUNNING,UNKNOWN sequenceNumber:39,166,804
haPort:5010 available storage size:NOT AVAILABLE delayMillis:? catchupTimeSecs:?

ストアのJMX監視の詳細は、Java Management Extensions (JMX)通知を参照してください。

ディスク制限例外の処理

ストレージ・ノードがディスク使用量のしきい値(<storagedirsize> - 5 GB)を超えた場合は、十分なデータを削除してしきい値要件を満たすようになるまで、そのノードに対するすべての書込みアクティビティが一時停止されます。このような状況では、ユーザー・データを削除せずにストアを読取りおよび書込み可能に戻す方法が2つあります。

  • 使用可能なディスク領域がある場合は、1つ以上のレプリケーション・ノードでstoragedirsizeを大きくする

  • 新しいシャードを追加することによるストアの拡張

ディスクに十分な領域が残っているか、storagedirsizeのサイズとしてディスク全体のサイズを設定していない場合は、1つ以上のレプリケーション・ノードのストレージ・ディレクトリ・サイズを単に大きくすることで、(ハードウェアを追加する必要なく)書込み可能に戻すことができます。

ディスクに十分な領域が残っていないか、ストレージ・ディレクトリのサイズとしてディスク全体のサイズを設定している場合は、ストア拡張手順に従ってハードウェアを追加し、シャードの数を1つ増やす必要があります。

ノート:

ストア拡張手順に従う場合は、minUtilization統計を監視することで、パフォーマンス・ファイルをチェックしてクリーナが正常に機能しているかどうかを確認することが重要です。minUtilization統計が30%未満の場合は、クリーナが機能していない可能性があります。この場合、ストア拡張を実行できません。

ストア拡張は、minUtilization統計のパーセンテージが30%以上である場合にのみ実行できます。

次に例を示します。

2018-03-07 16:07:12.499 UTC INFO [rg1-rn1] JE: Clean file 0x2b: 
predicted min util is below minUtilization, current util min: 39 max: 39, 
predicted util min: 39 max: 39, chose file with util min: 30 max: 30 avg: 30

2018-03-07 16:07:04.029 UTC INFO [rg1-rn2] JE: Clean file 0x27: 
predicted min util is below minUtilization, current util min: 39 max: 39, 
predicted util min: 39 max: 39, chose file with util min: 30 max: 30 avg: 30

2018-03-07 16:05:44.960 UTC INFO [rg1-rn3] JE: Clean file 0x27: 
predicted min util is below minUtilization, current util min: 39 max: 39, 
predicted util min: 39 max: 39, chose file with util min: 30 max: 30 avg: 30

ストレージ・ディレクトリ・サイズの増大

1つ以上のレプリケーション・ノードのストレージ・ディレクトリ・サイズを大きくするには、CLIを開いて、次のコマンドを実行します。

  1. ストアまたは障害が発生したシャードに対する書込み操作を無効にします。

    plan enable-requests -request-type READONLY \
{-shard <shardId[,shardId]*> | -store}

    ここで、-request-type READONLYはシャードに対する書込み操作を無効にするオプションです。-shardオプションを使用して1つ以上のシャードに対する書込み操作を無効にすることも、—storeオプションを使用してストア全体に対する書込み操作を無効にすることもできます。

    ノート:

    レプリケーション・ノードは、ディスク不足の制限例外が発生したときにすでに書込み不可モードになっていますが、ユーザーの書込み操作を明示的に無効にすることが重要です。ユーザーの書込み操作を無効にすると、レプリケーション・ノードが適切な方法でバックアップされます。

  2. PINGコマンドを実行して、1つ以上のレプリケーション・ノードの状態を分析します。 

    kv-> ping

    通常、レプリケーション・ノードでディスク不足の制限例外が発生すると、レプリカ・レプリケーション・ノードはRUNNING, UNKNOWN状態になり、マスター・レプリケーション・ノードはRUNNING, MASTER (non-authoritative)状態になります。

  3. 現在デプロイされているトポロジを表示するには、show topology —verboseコマンドを実行します。各レプリケーション・ノードに割り当てられている現在のストレージ・ディレクトリ・サイズをノートにとります。 

    show topology -verbose [-zn] [-rn] [-an] [-sn] [-store] [-status] [-json]

  4. storagedirsizeを大きくしたときにストア内の他のレプリケーション・ノードでディスク制限例外が発生しないように、すべてのレプリケーション・ノードのJE空きディスク領域を2GBまたは3GBに減らします。-all-rnsオプションを使用すると、すべてのレプリケーション・ノードのJE空きディスク領域を一括で減らすことができ、-service -rgx-rgyオプションを使用すると、特定のレプリケーション・ノードの空きディスク領域を減らすことができます。 

    kv-> plan change-parameters [-all-rns|-service -rgx-rgy] \
-params "configProperties=je.freeDisk=XXX"

    いずれかのオプションを指定してこのコマンドを実行すると、レプリケーション・ノードが停止され、パラメータが更新されます。その後、指定したJE空きディスク領域パラメータを使用してレプリケーション・ノードが再起動されます。

  5. 1つ以上のレプリケーション・ノードのストレージ・ディレクトリ・サイズを大きくします。

    kv-> plan change-storagedir -wait -sn snX \
-storagedir <storagedirpath> –add -storagedirsize X_GB

    ここで、snXはディレクトリ・サイズを大きくするストレージ・ノードで、Xは新しい記憶域サイズ(GB)です。

  6. plan change-parametersコマンドが正常に実行された後、新しいstoragedirsize値がストア内の1つ以上のレプリケーション・ノードに割り当てられていることを確認します。 

    show topology -verbose [-zn] [-rn] [-an] [-sn] [-store] [-status] [-json]

  7. 最後に、JE空きディスク領域を5GBに戻します。また、ストアまたは特定のシャードに対する書込み操作を再び有効にします。

    kv-> plan change-parameters [-all-rns|-service -rgx-rgy] \
-params "configProperties=je.freeDisk=5368709120"

kv-> plan enable-requests –request-type ALL {-shard <shardId[,shardId]*> | -store}

    ストアまたは特定のシャードに対する書込み操作を再び有効にするには、–request-type ALLオプションを使用します。

例

1x3トポロジのストアでディスク制限例外が発生した場合について考えます。次のステップを実行して、ストア内のすべてのレプリケーション・ノードのストレージ・ディレクトリ・サイズを16GBから25GBに増やします。

  1. ストア・レベルで書込み操作を停止します。

    kv-> plan enable-requests –request-type READONLY –store;

  2. ストアに対してpingを実行して、1つ以上のレプリケーション・ノードの状態を分析します。

    kv-> ping
Pinging components of store istore based upon topology sequence #11
3 partitions and 3 storage nodes
Time: 2018-09-28 06:57:10 UTC   Version: 18.3.2
Shard Status: healthy:0 writable-degraded:0 read-only:1 offline:0 total:1
Admin Status: healthy
Zone [name=dc1 id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
RN Status: online:1 offline:2   Storage Node [sn1] on node21:port1
Zone: [name=dc1 id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
Status: RUNNING   Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
        Admin [admin1]          Status: RUNNING,MASTER
        Rep Node [rg1-rn1]      Status: RUNNING,MASTER (non-authoritative)
        sequenceNumber:27,447,667 haPort:5011 available storage size:12 GB
Storage Node [sn2] on node22:port1    
Zone: [name=dc1 id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
Status: RUNNING   Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
        Rep Node [rg1-rn2]      Status: RUNNING,UNKNOWN 
        sequenceNumber:27,447,667 haPort:5010 available storage size:10 GB delayMillis:? catchupTimeSecs:?
Storage Node [sn3] on node23:port1    
Zone: [name=dc1 id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
Status: RUNNING   Ver: 18.3.2 2018-09-17 09:33:45 UTC  Build id: a72484b8b33c
        Rep Node [rg1-rn3]      Status: RUNNING,UNKNOWN 
        sequenceNumber:27,447,667 haPort:5010 available storage size:9 GB delayMillis:? catchupTimeSecs:?

    この例は、レプリケーション・ノードがRUNNING, UNKNOWN状態であり、マスター・レプリケーション・ノードがRUNNING, MASTER(non-authoritative)状態であることを示しています。

  3. 現在デプロイされているトポロジを表示します。 

    kv-> show topology -verbose
store=istore  numPartitions=3 sequence=11
  zn: id=zn1 name=dc1 repFactor=3 type=PRIMARY allowArbiters=false \
  masterAffinity=false

  sn=[sn1] zn:[id=zn1 name=dc1] node21:port1 capacity=1 RUNNING
    [rg1-rn1] RUNNING  /scratch/kvroot 16 GB
                 single-op avg latency=36.866146 ms   multi-op avg latency=0.0 ms
    [rg1-rn1] RUNNING  /scratch/kvroot 16 GB
                 single-op avg latency=36.866146 ms   multi-op avg latency=0.0 ms
  sn=[sn2] zn:[id=zn1 name=dc1] node22:port1 capacity=1 RUNNING
    [rg1-rn2] RUNNING  /scratch/kvroot 16 GB
                 single-op avg latency=0.0 ms   multi-op avg latency=0.0 ms
    [rg1-rn2] RUNNING  /scratch/kvroot 16 GB
                 single-op avg latency=0.0 ms   multi-op avg latency=0.0 ms
  sn=[sn3] zn:[id=zn1 name=dc1] node23:port1 capacity=1 RUNNING
    [rg1-rn3] RUNNING  /scratch/kvroot 16 GB
                 single-op avg latency=0.0 ms   multi-op avg latency=0.0 ms
    [rg1-rn3] RUNNING  /scratch/kvroot 16 GB
                 single-op avg latency=0.0 ms   multi-op avg latency=0.0 ms

  numShards=1
  shard=[rg1] num partitions=3
    [rg1-rn1] sn=sn1 haPort=node21:port2
    [rg1-rn2] sn=sn2 haPort=node22:port3
    [rg1-rn3] sn=sn3 haPort=node23:port3
    partitions=1-3

    各レプリケーション・ノードのストレージ・ディレクトリ・サイズとして16GBのディスク領域が割り当てられていることがわかります。

  4. ストア内のすべてのレプリケーション・ノードに対し、JE空きディスク領域を5GBから2GBに減らします。

    kv-> plan change-parameters -all-rns -params \
"configProperties=je.freeDisk=2147483648";
Started plan 70. Use show plan -id 70 to check status.
To wait for completion, use plan wait -id 70

  5. 各レプリケーション・ノードについて、ストレージ・ディレクトリ・サイズを25GBに増やします。

    kv-> plan change-storagedir -wait -sn sn1 -storagedir /scratch/kvroot \
-add -storagedirsize 25_GB -wait
Executed plan 72, waiting for completion...
Plan 72 ended successfully
    kv-> plan change-storagedir -wait -sn sn2 -storagedir /scratch/kvroot \
-add -storagedirsize 25_GB -wait
Executed plan 73, waiting for completion...
Plan 73 ended successfully
    kv-> plan change-storagedir -wait -sn sn3 -storagedir /scratch/kvroot \
-add -storagedirsize 25_GB -wait
Executed plan 74, waiting for completion...
Plan 74 ended successfully

  6. トポロジを再度表示して、新しい値がstoragedirsizeに割り当てられていることを確認します。 

    kv-> show topology -verbose
store=istore  numPartitions=3 sequence=11
  zn: id=zn1 name=dc1 repFactor=3 type=PRIMARY allowArbiters=false \
masterAffinity=false

  sn=[sn1] zn:[id=zn1 name=dc1] node21:port1 capacity=1 RUNNING
    [rg1-rn1] RUNNING  /scratch/kvroot 25 GB
                 single-op avg latency=0.0 ms   multi-op avg latency=0.0 ms
  sn=[sn2] zn:[id=zn1 name=dc1] node22:port1 capacity=1 RUNNING
    [rg1-rn2] RUNNING  /scratch/kvroot 25 GB
                 single-op avg latency=552.51996 ms   multi-op avg latency=0.0 ms
  sn=[sn3] zn:[id=zn1 name=dc1] node23:port1 capacity=1 RUNNING
    [rg1-rn3] RUNNING  /scratch/kvroot 25 GB
                 single-op avg latency=14.317171 ms   multi-op avg latency=0.0 ms

  numShards=1
  shard=[rg1] num partitions=3
    [rg1-rn1] sn=sn1 haPort=node21:port2
    [rg1-rn2] sn=sn2 haPort=node22:port3
    [rg1-rn3] sn=sn3 haPort=node23:port3
    partitions=1-3

    この例は、各レプリケーション・ノードのストレージ・ディレクトリ・サイズとして25GBが割り当てられていることを示しています。

  7. JE空きディスク領域を5GBに戻し、ストアに対する書込み操作を再び有効にします。

    kv-> plan change-parameters [-all-rns|-service -rgx-rgy] \
-params "configProperties=je.freeDisk=5368709120"

kv-> plan enable-requests –request-type READONLY –store;

新しいシャードの追加

ストレージ・ディレクトリ・サイズを大きくするのとは別に、新しいシャードを追加してストアを拡張することで、ディスク制限例外を処理することもできます。

次の例は、3つの新しいストレージ・ノード(ストレージ・ノード21、22および23)を追加し、新しいストアをデプロイすることで、ディスク制限例外からリカバリする方法を示しています。

  1. ストアに対する書込み操作を無効にします。

    kv-> plan enable-requests -request-type READONLY -store;

    ここでは、-request-type READONLYを使用して、ストアに対する書込み操作を無効にし、読取り操作のみを許可しています。

  2. すべてのノードでJE空きディスク領域を2GBに減らし、je.cleaner.minUtilization構成パラメータを40 (KVStoreのデフォルト)から60に増やします。 

    kv-> plan change-parameters -all-rns \
-params "configProperties=je.cleaner.minUtilization 60; \
je.freeDisk 2147483648";

    このコマンドを実行すると、ストア拡張用の空き領域がさらに作成されます。レプリケーション・ノードが停止され、パラメータが更新され、その新しいパラメータを使用してレプリケーション・ノードが再起動されます。

  3. ストアを拡張するための新しいノードを作成、起動および構成します。

    • 新しいノードを作成します。makebookconfigユーティリティを実行して、ストア内の各ストレージ・ノードを構成します。 

      java -Xmx256m -Xms256m -jar KVHOME/kvstore.jar makebootconfig \
-root sn1/KVROOT \
-store-security none -capacity 1 \
-port port1 -host node21 \
-harange 5010,5020 \
-storagedir /scratch/sn1/u01 –storagedirsize 20-Gb
      java -Xmx256m -Xms256m -jar KVHOME/kvstore.jar makebootconfig \
-root sn2/KVROOT \
-store-security none -capacity 1 \
-port port1 -host node22 \
-harange 5010,5020 \
-storagedir /scratch/sn2/u01 –storagedirsize 20-Gb
      java -Xmx256m -Xms256m -jar KVHOME/kvstore.jar makebootconfig \
-root sn3/KVROOT \
-store-security none -capacity 1 \
-port port1 -host node23 \
-harange 5010,5020 \
-storagedir /scratch/sn3/u01 –storagedirsize 20-Gb

    • startユーティリティを使用して、各Oracle NoSQL Databaseノードでストレージ・ノード・エージェント(SNA)を再起動します。 

      kv-> nohup java -Xmx256m -Xms256m -jar \
KVHOME/lib/kvstore.jar start -root KVROOT &

    • 新規ストアを構成します。

      java -Xmx256m -Xms256m -jar KVHOME/lib/kvstore.jar runadmin \
-port port1 -host node21 
      java -Xmx256m -Xms256m -jar KVHOME/lib/kvstore.jar runadmin \
-port port1 -host node22
      java -Xmx256m -Xms256m -jar KVHOME/lib/kvstore.jar runadmin \
-port port1 -host node23

  4. 新しい構成に従ってストアを再分散します。

    kv-> java -Xmx256m -Xms256m -jar KVHOME/lib/kvstore.jar runadmin \
-port port1 -host host1
    kv-> plan deploy-sn -zn zn1 -host node21 -port port1 -wait
Executed plan 7, waiting for completion...
Plan 7 ended successfully
kv-> plan deploy-sn -zn zn1 -host node22 -port port1 -wait
Executed plan 8, waiting for completion...
Plan 8 ended successfully
kv-> plan deploy-sn -zn zn1 -host node23 -port port1 -wait
Executed plan 9, waiting for completion...
Plan 9 ended successfully
Plan 11 ended successfully
    kv-> pool join -name ExamplePool -sn sn4
Added Storage Node(s) [sn4] to pool ExamplePool
kv-> pool join -name ExamplePool -sn sn5
Added Storage Node(s) [sn5] to pool ExamplePool
kv-> pool join -name ExamplePool -sn sn6
Added Storage Node(s) [sn6] to pool ExamplePool
    kv-> topology clone -current -name newTopo
Created newTopo

    kv-> topology redistribute -name newTopo -pool ExamplePool
Redistributed: newTopo

    kv-> plan deploy-topology -name newTopo -wait
Executed plan 11, waiting for completion...

  5. レプリケーション・ノードを元の構成にリストアします。

    plan change-parameters -all-rns \
-params "configProperties=je.cleaner.minUtilization 40; \
je.freeDisk 5368709120";

  6. ストアに対する書込み操作を再び有効にします。

    kv-> plan enable-requests -request-type ALL -store;

    ここでは、—request-type ALLを使用して、ストアに対する読取り操作と書込み操作の両方を有効にしています。