18.1.13での変更点

Oracle NoSQL Databaseリリース18.1.13 Enterprise Editionで次の変更が行われました。

トピック

新機能

ストアの健全性を確認するようCLIコマンドplan stop-serviceの動作を変更しました。この変更後、プランを使用してサービスを停止するとストアが異常な状態になる場合、プランは失敗し、次のような詳細なヘルス・チェック情報が出力されます。

One of the groups is not healthy enough for the operation: [rg1] Only 1 primary nodes are running such that a simple majority cannot be formed which requires 2 primary nodes. The shard is vulnerable and will not be able to elect a new master. Nodes not running: [rg1-rn1]. Nodes to stop: {rg1=[rg1-rn2]} ... ...

サービスは、 -forceフラグを追加することによって強制的に停止できます。

例外が1つあることに注意してください。plan stop-service -all-rnの場合は常にストアに異常が生じるため、このようなプランではヘルス・チェックがスキップされ、-forceフラグは必要ありません。[#22425]
Oracle NoSQLのSQLでgroup-by句とseq_transform式を実装しました。

group-byは標準SQLのgroup-byと似ています。ただし、Oracle NoSQLでグループ化が可能なのは、group-by式で行をソートする索引がある場合のみです。

group-byと一緒に集計関数count(*)、count(expr)、sum(expr)、avg(expr)、min(expr)およびmax(expr)が実装されました。

seq_transform式は、入力として「ソース」式と「マッパー」式を使用します。これは、ソース式を評価してゼロ個以上のアイテムのシーケンスを生成し、ソース・シーケンスの各アイテムでマッパー式を評価してその評価の結果を連結することによってこのソース・シーケンスを「変換」します。現在のソース・アイテムには、$変数を介してマッパー式からアクセスできます。

group-byとseq_transformの両方を示す例を次に示します。

次のような行を持つsales表があるとします。
```
{
  "id":1,
  "sale":
  {
    "acctno" : 349,
    "year" : 2000, "month" : 10, "day" : 23,
    "state" : "CA", "city" : "San Jose", "storeid" : 76,
    "prodcat" : "vegies",

    "items" : [ { "prod" : "tomatoes", "qty" : 3, "price" : 10.0 },
                { "prod" : "carrots",  "qty" : 1, "price" :  5.0 },
                { "prod" : "pepers",   "qty" : 1, "price" : 15.0 }
              ]
  }
}
```
salesに次の索引があるとします。
```
create index on sales (sale.acctno as integer,
                       sale.year as integer,
                       sale.prodcat as string)
```
この場合、次の問合せを記述できます。これにより、acctnoおよびyear当たりのsales合計が返されます。[#26427]
```
select t.sale.acctno,
       t.sale.year,
       sum(seq_transform(t.sale.items[], $.price * $.qty)) as sales
from sales t
group by t.sale.acctno, t.sale.year
```
SQLで親子結合を実装しました。

より一般的には、この機能を使用すると、同じ表階層内の表間で結合を実行できます。構文的には、これは、SQL問合せのFROM句に出現する可能性のある新しいNESTED TABLES句によって行われます。NESTED TABLES句は、ターゲット表およびターゲット表の多数の祖先および/または子孫表を指定します。これは、TableAPIのtableIteratorおよびtableKeysIteratorメソッドに対するパラメータとしてMultiRowOptionsオブジェクトを使用する場合と似ています。しかし、NESTED TABLESは、これらのプログラム的なAPIの機能を大幅に拡張し、より標準的なセマンティクスとより優れたパフォーマンスを提供します。具体的には、NESTED TABLESには次の機能があります。
- 標準SQLによって定義されるため、多数のLEFT OUTER JOINSおよびUNION操作と等価です。
- 予測を可能にします。問合せの残りの部分で、関連する表の列のサブセットを選択できます。
- 標準SQLのON句を使用して祖先表および子孫表で述語を指定できます。
- 子孫表が指定されている場合でも、セカンダリ索引を介してターゲット表にアクセスできるようにします。
例として、usersの母集団と、それらのユーザーが送受信したemailsを追跡するアプリケーションを考えてみます。Oracle NoSQLのSQLが汎用結合を現在サポートしていない場合、emailsはusersの子として作成された表に格納されるため、NESTED TABLES句を使用して両方の表の情報を結合する問合せを作成できます。2つの表に対するcreate table文を次に示します。
```
create table users(
    uid integer,
    name string,
    email_address string,
    salary integer,
    address json,
    primary key(id))

create table users.emails(
    eid integer,
    sender_address string,   // sender email address
    receiver_address string, // receiver email address
    time timastamp(3),
    size integer,
    content string,
    primary key(eid))
```
usersおよびemails表に関して作成できる2つの問合せを次に示します。users.emailsがusersの子表であるならば、users.emailsには、create table定義には含まれていない追加の列があります。この暗黙的な列は、uidという名前になり、型は整数になります。通常、その値は、users表に表示されるユーザーidになりますが、これは必須ではありません。
```
#
# Count the number of emails sent in 2017 by all users whose salary is greater
# than 200K
#
select count(eid)
from NESTED TABLES(
       users
       descendants(users.emails ON email_address = sender_address and
                                   year(time) = 2017)
     )
where salary > 200
```
前述のNESTED TABLES句は、次のleft outer joinと等価です。
```
users u left outer join users.emails e on u.uid = e.uid and
                                          email_address = sender_address and
                                          year(time) = 2017
#
# For each email whose size is greater than 100KB and was sent by a user in the
# the users table, return the name and address of that user.
#
select name, address
from NESTED TABLES(users.emails ancestors(users))
where size > 100 and sender_address == email_address
```
前述のNESTED TABLES句は、次のleft outer joinと等価です。[#26670]
```
users.emails e left outer join users u on u.uid = e.uid
```
管理CLIコマンドの新しいJSON出力形式を導入します。-jsonフラグのあるrunadmin CLIコマンドが新しいJSON出力形式で表示されます。互換性のために、以前の管理CLIのJSON出力も引き続きサポートされており、ユーザーは-json-v1を使用して、以前のJSON v1出力形式を表示できます。[#25917]
データの整合性のためにプライマリ表およびセカンダリ索引を検証する新しいプランplan verify-dataを導入します。ユーザーは、このプランを管理ノードおよび/またはレプリケーション・ノードで実行し、データ・レコードのチェックサムまたはデータベースのBツリー、あるいはその両方を検証することを選択できます。

次に例を示します。
```
plan verify-data -all-rns
```
この場合、すべてのレプリケーション・ノードのプライマリ表とセカンダリ索引のデータ・レコードの整合性とBツリーの整合性の両方を検証します。

および:
```
plan verify-data -verify-log disable -verify-btree enable -index disable -all-rns
```
この場合、すべてのレプリケーション・ノードについてプライマリ表のBツリーの整合性を検証します。[#26284]
複数のヘルパー・ホストをサポートするように、管理CLIコマンドを変更します。ユーザーは、-helper-hostsまたは-host/-portを使用してマスター管理に接続できるようになりました。このコマンドは、指定のホスト/ポートで任意のサービスに接続できるかぎり管理ノードを検索できるため、特定のホスト/ポートに管理ノードを設定する必要はありません。2つのフラグ、-admin-hostおよび-admin-portが削除されます。これらに依存するスクリプトは、-helper-hostsまたは-host/-portの特定のホスト/ポートがストア内のSNに接続できるかぎり、単にこれら2つのフラグを削除できます。[#26633]
現在の年の最後の2桁をメジャー・バージョン番号として使用するようリリース採番規則を変更し、各リリースの連番をマイナー・バージョン番号として増分しました。この採番方式は、他のOracle製品に対する同様の変更と一致するため、Oracleのメジャーおよびマイナー・リリース番号(KVVersion.getOracleMajor()およびgetOracleMinor())は、通常のリリース番号(KVVersion.getMajor()およびgetMinor())と同じになりました。また、リリース文字列には独立したOracleバージョン番号が含まれなくなりました。アプリケーションは、KVVersionメソッドを使用して個々のバージョン番号フィールドにアクセスする必要があります。アプリケーションでバージョン文字列を解析する場合、Oracleバージョン番号の削除に対応するようにバージョン文字列を更新する必要があります。[#26756]
RepNodeMXBeanにJMXを通じて使用可能な2つの新しい属性が追加されました。
- RepNodeMXBean.getOpMetricは、操作関連のメトリックのバンドルを含むJSON文字列を返します。
- RepNodeMXBean.getEnvMetricは、環境関連のメトリックのバンドルを含むJSON文字列を返します。
これらのJSONオブジェクトは、JMX通知oracle.kv.repnode.opmetricおよびoracle.kv.repnode.envmetricとしてこれまで使用可能であり、そのまま使用可能です。これらについては、ランブックを参照してください。[#26760]
キー分散統計ユーティリティ(『管理ガイド』の付録Gを参照)が変更され、(rnStatisticsEnabledパラメータを介して)有効になっている場合、レプリケーション・ノードの負荷が軽い場合に自動的にスケジュールされるようになりました。その結果、パラメータrnStatisticsLowActivePeriodおよびrnStatisticsRequestThresholdは廃止され、サポートされなくなりました。廃止されたこれらの古いパラメータを使用しないように、これらのパラメータを設定する管理CLIスクリプトを更新する必要があります。[#26635]
統計収集が(rnStatisticsEnabledパラメータを介して)無効になるか、表または索引が削除されたときに、キー分散統計ユーティリティによって収集されるデータがシステム表に保持される期間を制御する新しいパラメータrnStatisticsTTLが追加されました。デフォルトの存続期間(TTL)は60日です。指定する時間単位は日数または時間数である必要があります。[#26796]
リリース・バージョン文字列により、使用中のエディションが識別されるようになりました。KVVersion.CURRENT_VERSION.toString()を呼び出した結果には、kvclient.jarファイルの使用時のクライアントが記述されます。次に例を示します。
```
18.1.1 2018-01-24 09:06:12 UTC  Build id: 3eef91c0eaf6 Edition: Client
```
kvstore.jarファイルを使用する場合、バージョン文字列により、リリースのサーバー・エディションが識別されます。[#24136]
makebootconfigコマンドで管理ディレクトリ、管理ディレクトリ・サイズおよびRNログ・ディレクトリを指定するためのサポートを実装しました。
- -admindir <directory path>
  
  管理ノードに関連付けられた環境を含むディレクトリへのパスです。明示的なディレクトリ引数がない場合、環境ファイルはKVROOT/KVSTORE/SN'ID'/Admin'Id'/ディレクトリに配置されます。この引数はmakebootconfigではオプションですが、推奨されます。
- -admindirsize <directory size>
  
  管理ストレージ・ディレクトリのサイズ。この引数はmakebootconfigではオプションですが、推奨されます。
- -rnlogdir <directory path>
  
  レプリケーション・ノードに関連付けられたログ・ファイルを含むディレクトリへのパスです。容量の値が1を超える場合は、複数のrnlogdirパラメータを、ストレージ・ノードでホストされるレプリケーション・ノードごとにmakebootconfigで指定する必要があります。rnlogdirが指定されていない場合、デフォルトではログはKVROOT/KVSTORE/logディレクトリの下に配置されます。この引数はmakebootconfigではオプションですが、推奨されます。
-rnlogdirが指定されている場合、特定のレプリケーション・ノードのje.info、je.configおよびje.statファイルがrnlogdirに格納されます。すべての場合において、管理ノードのje.info、je.statおよびje.configファイルはkvrootログ・ディレクトリに格納されます。[#26444]
全文検索では、ElasticsearchへのHTTPS接続をサポートする内部HTTPクライアントが使用されるようになりました。

FTSはElasticsearchトランスポート・クライアントを使用しなくなりました。Apacheのhttpasyncclientライブラリを介して構築された独自のHttpClientを使用するようになりました。これは、Elasticsearchクラスタの登録中に使用されたポートが、以前のリビジョンで使用されていたトランスポート・ポートではなく、HTTPポートに変更されることを意味します。

次に示すコマンドでは:
```
plan register-es -clustername <es_cluster_name> -host <host_name>
                 -port <http_port> -secure true
```
指定したポートはESクラスタのHTTPポートである必要があります。これは、以前のリリースではトランスポート・ポートでした。

前述のコマンドで確認できるように、デフォルト値がtrueである新しいsecureフラグが追加されています。つまり、FTSはデフォルトではセキュア・モードで実行されるようになっており、そのためには、FTSドキュメントで説明されているように、追加の証明書設定が必要です。

既存のKVStoreにすでにElasticsearchが登録されている場合は、アップグレード後、plan register-esコマンドを使用して再登録する必要があります。登録されていたポートがトランスポート・ポートからHTTPポートに変更されたため、追加の登録が必要です。[#26059]
FTSセキュリティはEnterprise Editionでのみ使用可能です。

基本エディションおよびコミュニティ・エディションでは、-secureフラグを明示的にfalseに設定する必要があります。[#26781]
```
plan register-es -clustername <es_cluster_name> -host <host_name>
                 -port <http_port> -secure false
```

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

plan switchover管理CLIコマンドで一時的な障害の原因となる可能性があるバグが修正されました。このバグが原因で、プラン・タスクUpdateRepNodeParamsが失敗していました。この失敗は、次のようなプラン・ステータス出力によって識別できます。

Failures: Task 72 ERROR at 2018-01-01 01:01:01 UTC: UpdateRepNodeParams rg1-rn1: 72/UpdateRepNodeParams rg1-rn1 failed.: null,

これには、次のような管理ログ内のメッセージも伴います。

2018-01-01 01:01:01.001 UTC INFO [admin1] Couldn't update parameters for rg1-rn1 because unexpected exception: com.sleepycat.je.rep.ReplicaStateException: (JE 7.3.6) (JE 7.3.6) GroupService operation can only be performed at master. [#26776]
バグが修正され、レプリケーション・ノードがディスク制限に達したときの読取り可用性が改善しました。このバグが原因で、レプリケーション・ノードがディスク制限に達した後に障害が発生し、レプリケーション・ノード・ログに次のようなメッセージが表示されていました。

2018-01-01 01:01:01.001 UTC SEVERE [rg1-rn1] Process exiting com.sleepycat.je.DiskLimitException: (JE 7.6.3) Disk usage is not within je.maxDisk or je.freeDisk limits and write operations are prohibited: ... ...

また、この修正により、レプリケーション・ノードがディスク制限に達した後に読取り要求に対応し続けることができるようになりました。[#26701]
パス・フィルタ処理ステップ内部の述語を索引フィルタ処理述語として使用できるようにします。

たとえば、次の問合せを考えてみます。
```
select id
from Foo f
where exists f.info.address.phones[$element.areacode > 408 and
                                   $element.kind = "home"]
```
(info.address.phones.areacode, info.address.phones.kind)上に索引があるとします。

areacode述語は、索引スキャンの開始/停止述語として使用されます。kind述語は、索引フィルタ処理述語として使用できますが、この修正の前は、そのようには使用できませんでした。kind述語が索引にプッシュされない場合は、この問合せの「カバリング・インデックス」の最適化も緩和します。[#26162]
セカンダリ・カバリング・インデックスの場合、表の行にロックがかけられていました。つまり、このようなロックすべてに対してプライマリ索引が検索されていました。この場合、かわりに修飾索引エントリのみをロックする必要があります。アクセスされるすべてのデータがサーバーのメイン・メモリーにある場合、この修正によってパフォーマンスが大幅に向上する可能性があります。たとえば、準備された単純な問合せの場合、この修正ではエンドツーエンド問合せのレイテンシで20%の改善が示されました。[#26451]
UPDATE問合せ文では、データのクローニングを回避します。以前のリリースでは、新しい値(SET、ADDまたはPUT句で計算されたもの)は、ターゲット・アイテムの更新に使用する前にクローニングされていました。これは、アイテム間で循環性を生じさせることが可能なためであり、その結果、そのような循環データ構造がシリアライズされるときにスタック・オーバーフローが発生していました。この修正では、循環が不可能であるコンパイル時に検出することで、ほとんどの事例でこのようなクローニングが回避されるようになります。
問合せでマルチキー索引を使用する場合、多くの場合、重複した結果を消去する必要があります。これは主キー値に基づいて行われます。主キー列の型が数値またはタイムスタンプである場合に例外がスローされる原因となるバグが修正されました。[#26460]
更新文で外部変数を使用できなくなるというバグが修正されました。[#26504]
SELECT句にAS句のない単一の式が含まれていたときに発生するバグが修正されました。この場合、この式で返される値は単一フィールド・レコードでラップされる必要があります(レコードではない可能性があり、問合せでは常に同じレコード・タイプを持つレコードを返す必要があるため)。しかし、このラップが常に実行されるわけではありませんでした。[#26767]
key-only表の問合せ時にorder-by問合せが表示される問合せのバグが修正されました。この場合はコンパイル時にQueryStateEceptionがスローされました。これは、表の列ではなく索引フィールドにアクセスするようorder-by式が再作成されていなかったためです。[#26632]
(a)key-only表を問い合せ、(b)すべての表の列を索引付けするセカンダリ索引を使用するselect-star問合せのバグが修正されました。このバグが原因で、表の行ではなく索引エントリが返されていました。この場合、索引エントリには表の行と同じ情報が含まれますが、列および/またはその名前の順序が異なることがあります。この修正の一環として、すべての表の列を索引付けする索引は常にカバリング・インデックスとして認識されますが、以前はそうではありませんでした。[#26838]
次のような例で問合せに表示されるバグが修正されました。
```
declare $ext6 string;
select f.str
from foo f
where f.str >= $ext and f.str <= "ab"
```
$ext変数がabに設定されている場合、問合せでは、str列がabと等価ではなくabで始まるすべての行が返されます。外部変数が使用されなかった場合、コンパイラがWHERE条件をf.str = "ab"に変換するため、このバグは発生しません。[#26671]
検証対象のトポロジ候補に、現在のストアに存在しないストレージ・ノードが含まれている場合に、topology validateコマンドがnullを返す問題が修正されました。[#26294]
管理サービスによって格納されるプランの数に制限が課されるようになりました。IDが最新のプランより1000小さいプランは、管理サービスの永続ストアから自動的に削除されます。終端状態(SUCCEEDEDまたはCANCELED)にあるプランのみが削除されます。[#22963]
SYS$から始まる名前を持つ新規プランの作成を阻止する制限がプラン名に課されました。この接頭辞は、管理サービスが独自の管理操作を実行するために内部で作成するプラン用として予約されています。SYS$から始まる既存のプランは影響を受けません。[#26279]
特に定数をチェックしてJEトランザクション・タイムアウトを指定する場合に、指定された要求タイムアウト内での要求の完了が妨げられる問題が修正されました。また、RequestTimeoutExceptionよりConsistencyExceptionの方が要求障害の原因に関するより詳細な情報を提供できるため、ConsistencyExceptionを優先するよう要求処理を変更します。[#22849]
Direction.FORWARDおよびDirection.REVERSEが指定されている場合に、TableAPIインタフェース上の次のメソッドによって返される行の順序が正しくなくなる表スキャンの問題が修正されました。このバグのため、表を作成するには主キー・フィールドをDDL文の先頭で順序正しく宣言する必要がありました。これは今後は当てはまりません。問題のあるメソッドは次のとおりです。

TableIterator<Row> tableIterator(...) [#26769]
コードを変更し、一部の外部ライブラリでJava 9をサポートするようアップグレードしました。これらの変更はまだ暫定的なものであることに注意してください。完全なテストは将来のリリースで最新のJavaバージョンに移行します。[#25278]
-noadminフラグで構成されたストレージ・ノードでブートストラップ管理の起動が抑制されない問題が修正されました。[#26840]
SQLシェルでのexecute update文の実行時に「Unknown statement」が返される問題が修正されました。[#26357]
デフォルトのパターンを使用したZ (UTC用のレプリケーション)または+HH:MM/-HH:MM形式のゾーン・オフセットを持つタイムスタンプ文字列の解析をサポートします。[#25808]
存在しないプール名を指定する際のshow pool -nameコマンドの出力メッセージが修正されました。以前は、スタック・トレースとともに「Unknown Exception」が表示されていました。[#26639]
pingコマンドの出力が修正され、コマンド終了コードが0である場合にstdoutに送信されるようになりました。以前は、pingのすべての出力がstderrに送信されていました。[#26693]
pingコマンドにオプション引数-shardが追加され、特定のシャードに固有のサービス・ステータスがチェックされるようになりました。これらの変更は、管理レベルと最上位レベルのpingバージョンの両方で行われ、ping - shardIdにより、特定のシャードに関連付けられたSN、RNおよびアービタのステータスが表示されます。numShard=Xを使用したshow topologyの出力に、トポロジ内のシャードの数に関する情報が追加されました。[#25348]
makebootconfigコマンドで-storagedirおよび-storagedirsizeフラグを指定したストレージ・ディレクトリに関する情報がgenerateconfigコマンドの出力に含まれることを妨げていた問題が修正されしました。[#26353]

ストレージ・エンジンの変更点(JE 18.1)

マスターからレプリカへのRN遷移の後で時々、NullPointerExceptionが発生し、次のような典型的なスタック・トレースが表示されるバグが修正されました。[#26495]

   2017-08-08 06:59:15.498 UTC SEVERE [rg3-rn1] JE: Uncaught exception in feeder
   thread Thread[Feeder Output for rg1-rn1,5,main] nulljava.lang.NullPointerException
    at com.sleepycat.je.rep.vlsn.VLSNIndex.getLatestAllocatedVal(VLSNIndex.java:488)
    at com.sleepycat.je.rep.impl.node.Feeder$OutputThread.writeAvailableEntries(Feeder.java:1337)
    at com.sleepycat.je.rep.impl.node.Feeder$OutputThread.run(Feeder.java:1163)

JEのデータベースごと(パーティションごと)のディスク使用率メタデータは、大量のパーティションをさらに効率的にサポートする必要があるため、保持されなくなりました。RN当たり20,000個のパーティションがあり、レコードが1,000個を超えるデータ・ファイルに分散している例を考えてみます。以前は、使用率メタデータが約2GBのメモリーおよび100GBを超えるディスクを占有していました。このメタデータは削除されました。メタデータが削除されたため、dataAdminBytesのキャッシュ統計も削除されました。[#26597]
JEのリカバリ時間(クラッシュ後のRNおよび管理サービスの起動時間)が短縮されました。この最適化にあわせて、NoSQL DBではデフォルトのJEチェックポイント間隔が増え、書込みが減少し、ディスク使用率が向上しました。[#26179]
次のように、RNまたは管理サービスでのデッドロック検出中のNullPointerExceptionが修正されました。
```
java.lang.NullPointerException:
  at com.sleepycat.je.txn.LockManager$DeadlockChecker.hasCycleInternal(LockManager.java:1942)
...
```
これはNoSQL DBでは一切報告されませんでしたが、発生していた場合はRNまたは管理サービスが再起動する原因となりました。これは、永続的破損の原因にはなりませんでした。[#26570]
JE操作統計に内部操作が含まれる原因となることがあった2つのバグ(priSearchOpsなど)が修正されました。[#26694]
- Bツリー・ベリファイアが操作統計に誤って関与していました。
- 削除操作にはタイミングに応じて検索や位置統計が誤って含まれる場合がありました。
内部的な破損の原因となるタイミング関連の非常にまれなバグが修正されました。このバグは常にJE HAに存在しており、ストレス・テストで1回のみ検出されました。[#26706]
JE EnvironmentConfig.TREE_COMPACT_MAX_KEY_LENGTHのデフォルトは、16バイトから42バイトに変更されました。これにより、使用されるキー・サイズに応じて、Bツリーの内部ノードのキャッシュ使用率が5%減少して25%に削減されます(キー・サイズが小さいほど、大きく節約できます)。[ANDC-203]
TTLをレコードの削除と同時に使用するときに、レプリカ・ノードで次の例外を引き起こす可能性のあるバグが修正されました。
```
  2018-02-10 12:00:00.006 UTC INFO [rg1-rn1] JE: Replay thread exiting
  with exception:Environment invalid because of previous exception: ...
  Replicated operation could not be applied. DEL_LN_TX/14
  vlsn=1,711,027,333 isReplicated="1" txn=-834602813 LOG_INCOMPLETE:
  Transaction logging is incomplete, replica is invalid. Environment is
  invalid and must be closed. Problem seen replaying entry DEL_LN_TX/14
  vlsn=1,711,027,333 isReplicated="1" txn=-834602813
```
この問題は次の状況で発生する可能性があります。
- TTL機能が使用されている。
- レプリカが遅延しているか停止している(一般的ではありません)。
- TTLを持つレコードも、レコードの有効期限が切れる頃に明示的に削除される場合がある。
このバグが修正される前は、レプリカでネットワーク・リストアを実行することによってのみこの問題を修正できました。[#26851]

ユーティリティの変更点

スナップショット・ユーティリティにより、デフォルトで構成のスナップショットとサービス・データが作成されます。startコマンドラインに新しい引数-restore-from-snapshotが導入され、SNの起動時にユーザーが前のスナップショットから直接リストアできるようになりました。[#26119]
ストア全体または特定のシャードに対して有効化されるクライアント要求のタイプを制限するために新しいCLIコマンドが追加されました。
```
plan enable-requests -request-type {ALL|READONLY|NONE}
     {-shard <shardId[,shardId]*> | -store}
```
このコマンドでは3つの要求タイプを構成できます。ALLを設定すると、ストアまたはシャードが読取り要求と書込みリ要求の両方を処理できます。READONLYの場合、ストアまたはシャードが読取り要求にのみ応答します。NONEの場合、ストアまたはシャードが要求を処理しないことを意味します。[#25422]

versionとpingコマンド、および管理CLIのshow versions、pingおよびverify configurationコマンドの出力で提供されるリリース・バージョン情報で、使用されているリリースのエディションが識別されるようになりました。versionの場合、コマンドに使用されるJARファイルのエディションが出力で識別されます。show versionsの場合、サーバー情報で管理サービスのエディションが識別されます。その他のコマンドの場合、各ストレージ・ノードのバージョン情報で、そのストレージ・ノードの実行に使用されるJARファイルのエディションが識別されます。次に例を示します。[#24136]

  java -jar kvstore.jar version
  18.1.1 2018-01-24 09:06:12 UTC  Build id: 3eef91c0eaf6 Edition: Community

および:

  java -jar dist/lib/kvstore.jar ping -host localhost -port 5000 \
       -security /tmp/kvroot/security/user.security
  Pinging components of store kvstore based upon topology sequence #14
  10 partitions and 1 storage nodes
  Time: 2018-01-24 21:35:59 UTC   Version: 18.1.1
  Shard Status: healthy:1 writable-degraded:0 read-only:0 offline:0 total:1
  Admin Status: healthy
  Zone [name=KVLite id=zn1 type=PRIMARY allowArbiters=false
      masterAffinity=false]   RN Status: online:1 offline:0
  Storage Node [sn1] on localhost:5000    Zone: [name=KVLite id=zn1
      type=PRIMARY allowArbiters=false masterAffinity=false]
      Status: RUNNING   Ver: 18.1.1 2018-01-24 06:34:44 UTC
      Build id: 3eef91c0eaf6 Edition: Community
	Admin [admin1]		Status: RUNNING,MASTER
	Rep Node [rg1-rn1]	Status: RUNNING,MASTER sequenceNumber:50
            haPort:5006

KVStoreに対して新機能のマスター・アフィニティ・ゾーンを実装しました。この機能により、ユーザーはゾーンのデプロイ時にゾーンに対してマスター・アフィニティ/非マスター・アフィニティを設定できるようになります。マスター・アフィニティ・プロパティを持つゾーンの方が、ホスト・マスターRNより優先されます。さらに、この機能では、デプロイされたゾーンのマスター・アフィニティをユーザーが変更できるようにするコマンドも提供されます。[#25157]

この機能は、既存のコマンドdeploy-zoneに新しいフラグ-master-affinity/-no-master-affinityを追加し、新しいコマンドtopology change-zone-master-affinityを追加します。新しいコマンドの使用方法は次のとおりです。
```
    Usage: topology change-zone-master-affinity -name <name>
    {-zn <id> | -znname <name>}
    {-master-affinity | -no-master-affinity}
    Modifies the topology to change the master affinity of the specified
    zone.
```