Changes in 12cR1.2.1.8

The following changes were made in Oracle NoSQL Database 12cR1.2.1.8.

New Features

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:

  1. Install the new software on a Storage Node running an admin service1.

  2. Install the new client and connect to the store.

  3. Use the verify prerequisite command 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).

  4. Use show upgrade-order to get an ordered list of nodes to upgrade.

  5. Install the new software on the Storage Nodes (individually or in groups based on the ordered list).

  6. Use the verify upgrade to 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

  1. 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]

API Changes

  1. 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.

    show upgrade-order
    

    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.

    The 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

  1. In this release, the sample code provided by the utility class WriteOperations (located in the examples directory) 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 WriteOperations utility only provided retry methods for objects that are not large objects. [#21966]

  2. 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]

  3. 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]