Library Version 12.1.3.0

Upgrade from NoSQL DB Release 1.0 to NoSQL DB Release 2.0
Prev | Chapter 6. Upgrading an Existing Oracle NoSQL Database Deployment | Next

## Upgrade from NoSQL DB Release 1.0 to NoSQL DB Release 2.0

NoSQL DB release 2.0 changes the internal protocols by which the components of a store communicate with one other. Limited cross-version compatibility has been implemented. Components (including applications that use the embedded client library) running NoSQL DB release 1.0 and components running NoSQL DB release 2.0 can communicate with one another, so that a store can remain running and available to clients during the upgrade. However, operations that change the configuration of the store should not be attempted while the upgrade is in progress.

Similarly, NoSQL DB release 2.0 changes the persistent meta-data that is kept by the components of the store. When a component, such as the Admin or the Replication Node, first starts on the new software, it will automatically convert its meta-data to the new format. Therefore it is not possible to downgrade to the older NoSQL DB release without restoring the store from a previous backup.

### Note

Online upgrade is not supported for a store with a NoSQL DB release 1.0 topology that contains multiple zones. If your store has such a topology, please contact technical support before attempting to upgrade.

### Note

The NoSQL DB release 1.0 administrative CLI program is not compatible with a NoSQL DB release 2.0 Admin service, nor vice-versa. Make sure that you are using the compatible library when running the CLI. It may be necessary to clear the cache of your web browser when you first connect to the NoSQL DB release 2. Admin Console.

To upgrade your release 1.0 installation to release 2.0, perform the following steps for each node (machine) in your store:

1. Place the 2.0 software in a new KVHOME directory — referred to here as NEW_KVHOME. If nodes share this directory using NFS, this only needs to be done once for each shared directory.

2. If you have configured the node to automatically start the Storage Node Agent on reboot using /etc/init.d, Upstart, or some other mechanism for example, using the command:

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

   First modify that script to point to NEW_KVHOME.

3. For each KVROOT (usually, once per node):

   1. Stop the Storage Node using the old code:

          java -Xmx256m -Xms256m \
          -jar OLD_KVHOME/lib/kvstore.jar stop -root <kvroot> \
          [-config <configfile>]

   2. Restart the Storage Node using the new code:

          nohup java -Xmx256m -Xms256m \
          -jar NEW_KVHOME/lib/kvstore.jar start -root <kvroot> \
          [-config <configfile>] &

      If the system is configured to automatically restart the Storage Node Agent, this step may not be necessary.

4. Make sure that any administrative scripts or other files that reference OLD_KVHOME have been changed.

Once you are done, OLD_KVHOME can be removed.

Prev | Up | Next
Upgrade from Release 2.0 to Release 3.0 | Home | Chapter 7. Administrative Procedures