Open topic with navigation
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.
It is best practice to keep a broker in the durable domain configuration while its host is being upgraded. However, in a two-broker domain, in the unusual event that a broker does not restart, broker quorum is lost. Without broker quorum, operations such as the addition of a new host are not allowed. See About Broker Quorum.
In this situation, use the NuoDB Agent Tool to remove the broker from domain membership and regain broker quorum.
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.
For each host in the domain, execute the following steps:
Shut down database processes by invoking the NuoDB Manager
shutdown host command with the
graceful option set to
true, which allows client connections to complete. For example:
anAdminUserPw\ --command 'shutdown host
For details about running this command, see
Shut down the broker by stopping the
nuoagent service. For example, on Linux, the command is:
sudo service nuoagent stop
If the host is running the NuoDB REST service, shut it down. For example, on Linux the command is:
sudo service nuorestsvc stop
On each host in the domain, install the new NuoDB binaries. According to the platform on which you are installing NuoDB, see the instructions in
On most platforms you can install directly over the previous release. One exception is when using the RedHat Package Manager on Linux. In this case it is necessary to run
sudo rpm --upgrade nuodb-
Installation does not overwrite the NuoDB configuration files:
default.properties file or
nuodb-rest-api.yml file. However, if you want to update these files to take advantage of new features or changed features then you should update these files before you restart the broker in the next step.
After installation is complete, NuoDB services on each host. The following example starts a NuoDB service on Linux. See also Starting and Stopping NuoDB Services.
sudo service nuoagent startStarting NuoDB agent [ OK ]
In the unusual event that there is a problem restarting the broker, you might need to remove the broker from the domain membership. This is also referred to as deprovisioning the broker. The result is that the broker is no longer in the durable domain configuration. See NuoDB Agent Tool.
If a host also runs the NuoDB REST service, then start that service. The following example restarts the NuoDB REST service on Linux.
sudo service nuorestsvc start
Note: Repeat the above steps for each host in the domain.
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:
SELECT address,release_ver FROM system.nodes;ADDRESS RELEASE_VER -------------- ------------ 188.8.131.52 3.2.2-1-a24f664daf 172.31.32.189 3.2.2-1-a24f664daf 184.108.40.206 3.2.2-1-a24f664daf 220.127.116.11 3.2.0-05-2c8c36be7a 18.104.22.168 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,
SELECT address,release_ver FROM system.nodes;ADDRESS RELEASE_VER -------------- ------------- 22.214.171.124 3.3-1-14df3bb390 172.31.32.189 3.3-1-14df3bb390 126.96.36.199 3.3-1-14df3bb390 188.8.131.52 3.3-1-14df3bb390 184.108.40.206 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 .