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 Upgrade Instructions.
Upgrade NuoDB hosts during a low load period.
Before you start the upgrade:
Determine whether you will want to change any NuoDB configuration files to take advantage of new features or changes to features. See and Changes in this Release. On each upgraded host, you will want to make any necessary updates to configuration files before you restart the broker on that host.
Installation of the new NuoDB release overwrites these configuration files:
If you made any changes to these files, you should make a copy of your file in the older release so that you can copy it back to its location in the new release. Installation does not overwrite these configuration files:
Obtain the package for your operating system from email@example.com.
Back up your data before making any upgrades to the software. For each database, make a copy of the content of the archive directory of at least one storage manager. See Backing Up and Restoring Databases.
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.
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 NODES System Table Description provides the platform and release version used to create 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 id,address,platform_ver,release_ver FROM system.nodes;ID ADDRESS PLATFORM_VER RELEASE_VER -- -------------- ------------ ------------------- 3 22.214.171.124 196610 2.3.3-15-e8afa1ae20 4 172.31.32.189 196610 2.3.3-15-e8afa1ae20 5 126.96.36.199 196610 2.3.3-15-e8afa1ae20 6 188.8.131.52 589824 3.0.0-05-82e1397e00 7 184.108.40.206 589824 3.0.0-05-82e1397e00
This shows that the database processes with node IDs 3,4, and 5 were created with a 2.3.3 version of NuoDB. At this time, the system query
getreleaseversion() returns the older release version. It will continue to return the older release version, until all running database processes were created with the newer release. For example:
SELECT getreleaseversion() FROM dual;------------------- 2.3.3-15-e8afa1ae20
At the end of the rolling upgrade, the
SYSTEM.NODES table shows that
PLATFORM_VER is the latest platform version (in this case,
RELEASE_VER is the latest release version, (in this case,
getreleaseversion() function should now return
SELECT id,address,platform_ver,release_ver FROM system.nodes;ID ADDRESS PLATFORM_VER RELEASE_VER --- -------------- ------------- ------------------------- 3 220.127.116.11 589824 3.0.0-05-82e1397e00 4 172.31.32.189 589824 3.0.0-05-82e1397e00 5 18.104.22.168 589824 3.0.0-05-82e1397e00 6 22.214.171.124 589824 3.0.0-05-82e1397e00 7 126.96.36.199 589824 3.0.0-05-82e1397e00 SQL>
SELECT getreleaseversion() FROM dual;------------------- 3.0.0-05-82e1397e00
See one of the following topics according to your current NuoDB release: