Open topic with navigation
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 broker.
For each host in the domain, execute the following steps:
Disable enforcement for the domain. This prevents NuoDB from automatically starting any database processes on any hosts while you are upgrading this host. This applies to all databases including databases that are not running on the host being upgraded.
Invoke the following NuoDB Manager command:
anAdminUserPw\ --command 'disable enforcer domain'
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
Caution: Do not uninstall the previous release of NuoDB. Doing so can cause problems if the new NuoDB user ID (
uid) does not match the old one.
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.
In NuoDB release 2.3, the default value of the
removeSelfOnShutdown NuoDB host property is
true. This means that shutting down the broker causes it to be removed from the durable domain configuration. NuoDB recommends that
removeSelfOnShutdown be set to
false in deployments and starting with NuoB 2.4, the default setting of
After you install NuoDB 2.5 or later, and before you restart the broker, check the setting of the
removeSelfOnShutdown propety in the host's
default.properties file. If necessary, change its setting from
removeSelfOnShutdown property is specified in the
$NUODB_HOME/etc/default.properties file (see Host Properties (default.properties)).
In release 2.3, the default value of the
backoff.reqMinUptime host property was -1 (disabled). It is considered bast practice to set
backoff.reqMinUptime=30000 in the
$NUODB_HOME/etc/default.properties file before restarting the latest NuoDB broker.
After installation is complete, start the broker. The following example starts the broker 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
It is not necessary to restart your database(s). The NuoDB enforcer automatically restarts them. You can invoke
show domain summary to confirm that they are running:
nuodb [domain] >
show domain summaryHosts: [broker] * ec2-52-11-92-215.us-west-2.compute.amazonaws.com/22.214.171.124:48004 (us-west-2) CONNECTED [broker] ip-172-31-0-24/126.96.36.199:48004 (us-west-2) CONNECTED Database: test, (unmanaged), processes [2 TE, 2 SM], ACTIVE [SM] ip-172-31-0-68/188.8.131.52:48005 (us-west-2) [ pid = 8599 ] [ nodeId = 2 ] RUNNING [TE] ip-172-31-0-68/184.108.40.206:48006 (us-west-2) [ pid = 8625 ] [ nodeId = 4 ] RUNNING [SM] ip-172-31-0-24/220.127.116.11:48005 (us-west-2) [ pid = 30301 ] [ nodeId = 1 ] RUNNING [TE] ip-172-31-0-24/18.104.22.168:48006 (us-west-2) [ pid = 30325 ] [ nodeId = 3 ] RUNNING nuodb [domain] >
show host versionHost: 22.214.171.124 (version number) Professional Edition
Repeat these four steps for each host in the domain.
Following an upgrade to NuoDB 3.2, see Tasks After Upgrading to Release 3.2 .
Following an upgrade to NuoDB 3.1, see Tasks After Upgrading to Release 3.1 .
Following an upgrade to NuoDB 3.0, see Tasks After Upgrading to Release 3.0.
Following an upgrade to NuoDB 2.6, see Tasks After Upgrading to Release 2.6.
Following an upgrade to NuoDB 2.5, see Tasks After Upgrading to Release 2.5.
Following an upgrade to NuoDB 2.4, see Tasks After Upgrading to Release 2.4.
See also: Verifying the Rolling Upgrade.