Rolling Upgrade: Databases Remain Available

A rolling upgrade moves a NuoDB domain, which might include multiple databases, to a new NuoDB release without shutting down the databases.

Perform a rolling upgrade when continuous database availability is a requirement. If continuous data availability is not a requirement, see Upgrading With Databases Down.

Maintaining Admin Process Quorum in a Two-Admin Process Domain

It is best practice to keep a NuoDB Admin process in the durable domain configuration while its host is being upgraded. However, in a two-admin process domain, in the unusual event that an admin process does not restart, admin process quorum is lost. Without admin process quorum, operations such as the addition of a new host are not allowed. See About Admin Process Quorum.

In this situation, remove the admin process from domain membership and regain admin process quorum.

Rolling Upgrade Instructions

For continuous data availability during an upgrade, follow the instructions documented here. Continuous data availability requires:

In a rolling upgrade, you upgrade one host in the domain at a time. Ideally, a database's last upgraded host runs a transaction engine and not also a storage manager for that database. Otherwise, you can upgrade hosts in any order.

The rolling upgrade procedure consists of executing the following steps on each host: 1) shutting down NuoDB processes and services, 2) installing the latest release of NuoDB, and 3) restarting the NuoDB processes and services.

Upgrade Instructions per Host

For each host in the domain, execute the following steps:

Note: Repeat the above steps for each host in the domain.

Verifying the Rolling Upgrade

After you upgrade a host, you can follow the steps here to verify the upgrade.

During the rolling upgrade process, you may monitor version information in the SQL System Tables. In particular, the SYSTEM.NODES system table (see ) provides the platform version and release version that were used to start each database process. The following query result shows what the SYSTEM.NODES table might look like during the rolling upgrade process, before it is complete:

SQL> SELECT address,release_ver FROM system.nodes;

ADDRESS          RELEASE_VER
--------------   ------------ 

54.191.244.162   3.2.2-1-a24f664daf
172.31.32.189    3.2.2-1-a24f664daf
54.191.244.162   3.2.2-1-a24f664daf
54.187.192.14    3.2.0-05-2c8c36be7a
54.187.192.14    3.2.0-05-2c8c36be7a

At the end of the rolling upgrade, the SYSTEM.NODES table shows that for all database processes, RELEASE_VER is the latest release version (in this case, 3.3-1-14df3bb390).

SQL> SELECT address,release_ver FROM system.nodes;

ADDRESS         RELEASE_VER        
--------------  ------------- 

54.191.244.162  3.3-1-14df3bb390
172.31.32.189   3.3-1-14df3bb390
54.191.244.162  3.3-1-14df3bb390
54.187.192.14   3.3-1-14df3bb390 
54.187.192.14   3.3-1-14df3bb390

Note: After upgrading the database software, it may be necessary to upgrade the database protocol.
For more information, see Upgrading the Database Protocol .