The following changes were made in Oracle NoSQL Database 12cR184.108.40.206.
This release includes support for upgrading the NoSQL DB software (client or server) without taking the store offline or without significant impact to ongoing operations. In addition, upgrades can be made incrementally, that is, it should not be necessary to update the software on every component at the same time. This support includes client and server code changes and new command line interface (CLI) commands. [#22421]
The new CLI commands provide the administrator tools to help with the upgrade process. Using these commands, the general upgrade procedure is:
Install the new software on a Storage Node running an admin service1.
Install the new client and connect to the store.
verify prerequisitecommand to verify that the entire store is at the proper software version to be upgraded (All 2.0 versions of NoSQL DB will qualify as prerequisites).
show upgrade-orderto get an ordered list of nodes to upgrade.
Install the new software on the Storage Nodes (individually or in groups based on the ordered list).
verify upgradeto monitor progress and verify that the upgrade was successful.
1 In future releases this step will not be necessary
If the upgrade procedure is interrupted steps 4-6 can be repeated as necessary to complete the upgrade.
Bug and Performance Fixes
Unless configured specifically by the application, NoSQL DB specifies the -XX:ParallelGCThread jvm flag for each Replication Node process to indicate the number of garbage collector threads that the process should use. In the past, the algorithm in use generated a minimum value of 1 thread. After more testing, the minimum value has been raised to the min(4, <the number of cores on the node>). [#22475]
The admin command line interface (CLI) provides the following new commands [#22422]:
verify prerequisite [-silent] [-sn snX]*
This command will verify that a set of storage nodes in the store meets the required prerequisites for upgrading to the current version and display the components which do not meet prerequisites or cannot be contacted. It will also check and report an illegal downgrade situation where the installed software is of a newer minor release than the current version. In this command the current version is the version of the software running the command line interface. If no storage nodes are specified, all of the nodes in the store will be checked.
verify upgrade [-silent] [-sn snX]*
This command will verify that a set of storage nodes in the store has been successfully upgraded to the current version and display the components which have not yet been upgraded or cannot be contacted. In this command the current version is the version of the software running the command line interface. If no storage nodes are specified, all of the nodes in the store will be checked.
This command will display the list of storage nodes in the order that they should be upgraded to maintain the store's availability. This command will display one or more storage nodes on a line. Multiple storage nodes on a line are separated by a space. If multiple storage nodes appear on a single line, then those nodes can be safely upgraded at the same time. When multiple nodes are upgraded at the same time, the upgrade must be completed on all nodes before the nodes next on the list can be upgraded.
verify [-silent]command has been deprecated and is replaced by
verify configuration [-silent].The
verify [-silent]command will continue to work in this release.
Utility and Documentation Changes
In this release, the sample code provided by the utility class
WriteOperations(located in the
examplesdirectory) now includes methods that perform write operations for large objects (or LOB, see KVLargeObject). The new utility methods added in this release will properly retry the associated LOB operation when a FaultException is encountered. Prior to this release, the
WriteOperationsutility only provided retry methods for objects that are not large objects. [#21966]
The number of JE lock tables used by Replication Nodes (controlled via the je.lock.nLockTables JE configuration parameter) has been increased from 1 to 97. This change helps improve performance of applications characterized by very high levels of concurrent updates, by reducing lock contention. [#22373]
The Administration CLI now permits the creation of multiple Datacenters. By choosing Datacenter replication factors so that each Datacenter holds less than a quorum of replicas, this change makes it possible to create store layouts where the failure of a single Datacenter does not result in the loss of write availability for any shards in the store. In the current release, nodes in any Datacenter can participate in master elections and contribute to durability acknowledgments. As a consequence, master failover and durability acknowledgments will take longer if they involve datacenters that are separated by large distances. Future releases will provide greater flexibility in this area. [#20905]