ストアのバックアップ
KVStoreのバックアップを作成するには、CLI snapshotコマンドを使用してストア内のノードをコピーします。整合性を保持するために、スナップショットを作成するときにトポロジが変更中でないようにしてください。スナップショットのリストアでは、システム構成のトポロジが、スナップショットを作成したときに有効であったトポロジと正確に同じである必要があります。 
                  
スナップショットを作成すると、そのスナップショットはSNのサブディレクトリに格納されます。ただし、これらのスナップショットは、個別のストレージにコピーされないかぎり、永続バックアップにはなりません。ユーザーは、データの安全性を確保するために、各スナップショットを別の場所(できれば別のマシン上)にコピーする必要があります。
Oracle NoSQL Databaseの分散型であるという特徴とスケーリングにより、ストア全体のスナップショットを含むリソースが単一のマシンに置かれる可能性は低くなります。このドキュメントでは、スナップショットの格納場所と格納方法については説明しません。
スナップショットの作成
ノート:
スナップショットが不整合または使用不可になることを防ぐために、構成の(トポロジ的な)変更が行われているときにスナップショットを作成しないでください。スナップショットの作成時に、pingコマンドを使用し、後でロードまたはリストア中に使用できるよう、マスターを識別する出力情報を保存します。詳細は、スナップショットの管理を参照してください。
                     管理CLIでスナップショットを作成するには、snapshot createコマンドを使用します。 
                     
kv-> snapshot create -name <snapshot name>スナップショットは、現在のトポロジ内のデータ・ファイル、具体的には同じシャード内のすべてのパーティション・レコードに対する一連のハード・リンクで構成されます。スナップショットには、個別のシャード内のパーティションは含まれません。潜在的な不整合を最小限にするために、スナップショット・ユーティリティの操作は可能なかぎり並列で実行されます。
snapshot create –name <name>を使用します。kv-> snapshot create -name ThursdayCreated snapshot named 110915-153514-Thursday on all 3 nodes
Successfully backup configurations on sn1, sn2, sn3
スナップショット・アクティビティ
- データ・ファイルのバックアップ
- リストア・アクティビティに必要な構成ファイルおよび環境ファイルのバックアップ
スナップショット・ファイルをすべて揃えるために、snapshotコマンドでは、ストレージ・ノード・データ・ファイル、構成ファイルをバックアップし、その他の必要なファイルを追加しようとします。次に、snapshotコマンドによって作成またはコピーされる様々なファイルとディレクトリの説明を示します。 
                     
| envディレクトリのピアとしてsnapshotsディレクトリを作成します。各snapshotsディレクトリには、作成したスナップショットごとに1つのサブディレクトリが含まれます。そのサブディレクトリには、*.jdbファイルが含まれます。 
                                 date-time-name接頭辞が付いたスナップショット名のサブディレクトリには、–nameパラメータで指定した名前が付けられます。date-time接頭辞は、YYMMDD形式の6桁の年、月、日の値と、HHMMSS形式の6桁の時間、分、秒のタイムスタンプで構成されます。日付と時間の値はダッシュ(-)で区切られ、スナップショット名の前にダッシュ(-)の接尾辞が付いています。 |  | 
| ルート config.xmlファイルをdate-time-nameディレクトリにコピーします。 |  | 
| date-time-nameサブディレクトリにステータス・ファイルを作成します。このファイル( snapshot.stat)の内容は、スナップショットの作成が成功したかどうかを示します。ユーザーがスナップショットにリストアすると、最初にステータス・ファイルの内容が検証され、このファイルにSNAPSHOT=COMPLETEDという文字列が含まれている場合にのみ続行されます。 |  | 
| date-time-nameサブディレクトリにロック・ファイルを作成します。ロック・ファイル( snapshot.lck)は、同じルート・ディレクトリ内の異なるSN管理が同時に変更を行わないようにするために使用されます。 |  | 
| date-time-nameサブディレクトリのサブディレクトリである securityを作成します。このサブディレクトリには、kvroot/securityからコピーされたセキュリティ情報のコピーが含まれます。 |  | 
| ルート・セキュリティ・ポリシーを kvroot/security.policyからdate-time-nameサブディレクトリにコピーします。 |  | 
| ストア・セキュリティ・ポリシーをdate-time-nameサブディレクトリから、別のサブディレクトリの mystoreにコピーします。 |  | 
| ストレージ・ノード構成ファイル config.xmlを、kvroot/mystore/sn1/config.xmlからdate-time-nameディレクトリの対応するSNサブディレクトリにコピーします。 |  | 
スナップショットのコピー
スナップショットを短期間保持して、アップグレード後にストアをロールバックするために使用できるようにすることは、合理的な方法です。このようなシナリオでは、アップグレードが比較的短時間で検証でき、スナップショットが必要でなくなった場合はスナップショットをコピーせずに削除するだけで十分なことがあります。
ディスクまたはハードウェア障害時のデータの安全性を確保するために、これらのスナップショットを永続バックアップに変換することをお薦めします。そうしないと、マシンでディスクまたはその他のハードウェア障害が発生した場合、またはストア・ファイルが削除または上書きされた場合、スナップショットはそのマシン上で保持されているストアのライブ・データとともに失われます。
スナップショットを永続バックアップに変換するには、スナップショットを別のマシン上の別の場所にコピーする必要があります。後で、永続バックアップを使用して、ディスクまたはハードウェアの障害後にストアをリストアできます。
スナップショットの削除
snapshot remove <name>を使用します。kv-> snapshot remove -name 110915-153514-Thursday
Removed snapshot 110915-153514-Thursdaysnapshot remove –allを使用します。kv-> snapshot create -name Thursday
Created snapshot named 110915-153700-Thursday on all 3 nodes
kv-> snapshot create -name later
Created snapshot named 110915-153710-later on all 3 nodes
kv-> snapshot remove -all
Removed all snapshotsスナップショットの管理
スナップショットを作成すると、ユーティリティによって、システムの各レプリケーション・ノード(マスターとレプリカを含む)からデータが収集されます。この操作がシャード内のいずれかのノードで成功しなかった場合、スナップショット全体が失敗します。
スナップショットの作成を準備するとき、pingコマンドを使用して、現在マスターとして稼働しているノードを識別できます。各シャードには、MASTERキーワードによって識別されるマスターがあります。たとえば、サンプル出力では、ストレージ・ノードsn1上で稼働しているレプリケーション・ノードrg1-rn1が現在のマスターです。 
                  
java -Xmx64m -Xms64m \
-jar KVHOME/lib/kvstore.jar ping -port 5000 -host node01 \
-security USER/security/admin/security出力:
Pinging components of store mystore based upon topology sequence #316
300 partitions and 3 storage nodes
Time: 2024-04-05 06:57:10 UTC   Version: 24.1.11
Shard Status: healthy:3 writable-degraded:0 read-only:0 offline:0
Admin Status: healthy
Zone [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
RN Status: online:9 offline:0 maxDelayMillis:1 maxCatchupTimeSecs:0
Storage Node [sn1] on node01:5000
   Zone: [name=Boston id=zn1 type=PRIMARY]
   Status: RUNNING
   Ver: 24.1.11 2024-04-05 09:33:45 UTC  Build id: a72484b8b33c
      Admin [admin1]          Status: RUNNING,MASTER
      Rep Node [rg1-rn1]      Status: RUNNING,REPLICA
        sequenceNumber:231 haPort:5011 available storage size:14 GB delayMillis:1 catchupTimeSecs:0
      Rep Node [rg2-rn1]      Status: RUNNING,REPLICA
        sequenceNumber:231 haPort:5012 available storage size:12 GB delayMillis:1 catchupTimeSecs:0
      Rep Node [rg3-rn1]      Status: RUNNING,MASTER
        sequenceNumber:227 haPort:5013 available storage size:13 GB
Storage Node [sn2] on node02:6000
   Zone: [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
   Status: RUNNING
   Ver: 24.1.11 2024-04-05 09:33:45 UTC  Build id: a72484b8b33c
      Rep Node [rg1-rn2]      Status: RUNNING,MASTER
        sequenceNumber:231 haPort:6010 available storage size:15 GB
      Rep Node [rg2-rn2]      Status: RUNNING,REPLICA
        sequenceNumber:231 haPort:6011 available storage size:18 GB delayMillis:1 catchupTimeSecs:0
      Rep Node [rg3-rn2]      Status: RUNNING,REPLICA
        sequenceNumber:227 haPort:6012 available storage size:12 GB delayMillis:1 catchupTimeSecs:0
Storage Node [sn3] on node03:7000
   Zone: [name=Boston id=zn1 type=PRIMARY allowArbiters=false masterAffinity=false]
   Status: RUNNING
   Ver: 24.1.11 2024-04-05 09:33:45 UTC  Build id: a72484b8b33c
      Rep Node [rg1-rn3]      Status: RUNNING,REPLICA
        sequenceNumber:231 haPort:7010 available storage size:11 GB delayMillis:1 catchupTimeSecs:0
      Rep Node [rg2-rn3]      Status: RUNNING,MASTER
        sequenceNumber:231 haPort:7011 available storage size:11 GB
      Rep Node [rg3-rn3]      Status: RUNNING,REPLICA
        sequenceNumber:227 haPort:7012 available storage size:10 GB delayMillis:1 catchupTimeSecs:0
前述の情報を保存し、後でロードまたはリストア中に使用できるよう、個々のスナップショットに関連付ける必要があります。スナップショットのストア外コピーを作成する場合、シャードごとに1つのノードに対してのみスナップショット・データをコピーします。可能なかぎり、スナップショットの作成時にマスターとして稼働していたノードから取得したスナップショット・データをコピーします。
ノート:
スナップショットには管理データベースが含まれ、このスナップショットからストアをリストアする必要が生じた場合に、管理データベースが必要になることがあります。
ローカル・ストレージ・ノードのスナップショット・データは、KVROOTディレクトリ内のディレクトリに格納されます。ストア内の各ストレージ・ノードに次の名前のディレクトリが作成されます。 
                  
KVROOT/<store>/<SN>/<resource>/snapshots/<snapshot_name>/files説明:
-  
                        <store>は、ストアの名前です。 
-  
                        <SN>は、ストレージ・ノードの名前です。 
-  
                        <resource>は、ストレージ・ノードで実行されているリソースの名前です。通常これは、レプリケーション・ノードの名前です。 
-  
                        <snapshot_name>は、スナップショットの名前です。 
スナップショット・データは、複数のファイルで構成されます。たとえば:
 > ls /var/kvroot/mystore/sn1/rg1-rn1/snapshots/110915-153514-Thursday
00000000.jdb 00000002.jdb 00000004.jdb 00000006.jdb
00000001.jdb 00000003.jdb 00000005.jdb 00000007.jdb ノート:
ストレージを維持するためには、不要になったスナップショットを定期的にパージします。
スナップショットでの消去の影響
スナップショット・ベースのバックアップによって、元のファイルへのハードリンクが作成されます。これらのバックアップがターゲットの場所にコピーされ(ストア外コピー作業の完了)、対応するハードリンクが削除されるまで(スナップショット削除コマンドの実行)、消去しても、これらのファイル内の不要になったデータは処理されません。消去では、これらのファイルへのハードリンクのあるファイルは無視されます。
ディスクの使用違反の回避
ストレージ・エンジンは、ディスク領域使用量に関する情報を収集するときにスナップショットによって消費されるデータを考慮しません。最初は、スナップショット内のファイルはストアのライブ・データの一部とみなされます。ただし、時間の経過とともに古いファイルがクリーン・アップおよび削除されると、スナップショットにファイルが存在することでファイルは保持され、ストレージ・エンジンによって考慮されないディスク領域が使用されることになります。ディスクの使用違反を引き起こす場合があり、ストアへのさらなる書込みが無効になります。この問題を回避するには、スナップショット・ファイルを定期的に削除する必要があります。