This section explains how to run scripted rolling upgrades. The rolling upgrade is supported for upgrades from 4.0.x or 4.1 to 5.0 If you are upgrading from an earlier version, see Offline MapR Core Upgrade Using Manual Steps. The rolling upgrade process is designed to upgrade the core packages on all nodes on the cluster in a single operation. Packages are propagated and installed across the nodes while the cluster remains online and operational. (Do not try to use this type of upgrade to upgrade specific nodes only.)
You can monitor the progress of the whole upgrade process by running the MCS on any node that is not currently in maintenance mode (being upgraded).
The upgrade utility is extracted from a setup file and requires a tar file that contains all of the packages. You do not have to have Internet connectivity to run the upgrade if the setup file and the tar file are already downloaded. You do not need to configure a repository for these files.
Rolling upgrades run only in SSH mode, using either key-based (passwordless) authorization or password-based access for remote access to all of the nodes. The upgrade utility copies the archive file to the other nodes on the cluster that you are upgrading and runs similar commands on each node, using a root or sudo user account specified in the upgrade command.
See Preparing Each Node for more information about setting up passwordless SSH.
Before You Upgrade
You can run the same rolling upgrade process on secure and non-secure clusters; however, on a secure cluster, the MapR Admin user must have a security ticket created before running the upgrade. Otherwise the upgrade commands will not run.
The cluster continues to run at the highest capacity possible during the upgrade process.
If your cluster uses RM HA and the standby RM is on a CLDB node, the active RM node will be upgraded before the standby RM node. To reduce the impact on any jobs that are running during the upgrade, set the following parameters to a number that is greater than the number of ResourceManagers in the cluster:
See ResourceManager Configuration Properties for details about these parameters.
You do not need to shut down any services before running a rolling upgrade. As nodes are upgraded, they go into maintenance mode and warden is shut down, which shuts down other services, including any ecosystem components. Rolling upgrades do not upgrade packages for Hadoop ecosystem components. Upgrading the ecosystem is a separate upgrade step. Only MapR core packages are upgraded; however, when an upgraded node comes back online, warden restarts ecosystem components that are compatible with the new release. Incompatible ecosystem components will fail to come up until they are upgraded separately.
Rolling Upgrade Procedure
To run a rolling upgrade from Version 4.0.x to Version 5.0 or from Version 4.1.0 to Version 5.0:
mapr-setuppackage and the archive file (the tar file that contains all of the core packages). Download the archive file to a server on the cluster that you want to upgrade. For example, download the files to a
As root (or by using sudo), run the following command to extract the
mapr-setupfile, which includes the upgrade utility:
By default, the downloaded mapr-setup file does not have execute permissions. Permissions need to be provided (for example,
chmod +x mapr-setup) before running the script.
Run the upgrade utility from the extracted
/opt/mapr-installer/bin/upgradedirectory and provide the path to the archive file. For example:
This example presents a simple case where the upgrade is run as root, and the root username and password are requested interactively. Examples with other credentials are shown later in this section.
The upgrade utility has several options; see Upgrade Command Options. When you run the upgrade, the output describes all of the steps in the upgrade process, and it identifies the groups of nodes where the upgrade will run before it upgrades them. See Rolling MapR Core Upgrade Using Manual Steps for information about the order in which groups of nodes and packages are upgraded.
The output shown here captures the upgrade operations on the first node in the cluster to be upgraded:
You can modify the options (MapR user account and archive file location), stop the upgrade, or continue.
cto continue the upgrade process, then enter the SSH username and password:
Alternatively, you can specify username and password as part of the upgrade command. The upgrade process begins on the first node:
The upgrade process continues on the next node. When the rolling upgrade process is complete on all nodes, configure the new version as usual.
Upgrade Command Options
upgrade -h to display the usage for the upgrade utility:
The utility supports the following options:
|Display the syntax and usage for the utility.|
|Run operations as |
|Run the upgrade as a user with sudo privileges. The default account is |
|Specify the remote sudo password. All nodes must accept the same username and password.|
|Connect with a remote user account that exists on all of the nodes.|
|Specify the remote SSH password. All nodes must accept the same username and password. Specifying a remote password and specifying a private key file are mutually exclusive options. Do not attempt to run the upgrade command with both sets of credentials.|
|Use key-based SSH on clusters that require or are configured for key-based authentication across nodes, such as cloud-based deployments. Specifying a remote password and specifying a private key file are mutually exclusive options. Do not attempt to run the upgrade command with both sets of credentials.|
|Prompt for the SSH password. All nodes must accept the same username and password.|
|Prompt for the sudo password. All nodes must accept the same username and password.|
|Delay the upgrade until all running MRv1 jobs are complete.|
|Specify the MapR Admin user account on the cluster if it is not |
Full path to the tar file that you downloaded, which contains the upgrade packages. For example:
You must specify the full path to this file.
Version of MapR software that you are upgrading to (only
|--ssh-port||Remote SSH port. If your SSH ports are set to non-22 values for security reasons, specify the SSH port. All nodes in the cluster must be set to the same SSH port number for upgrade to succeed.|
The rolling upgrade script offers two choices for SSH user authorization: private-key-based (passwordless) authorization or password-based access.
The upgrade process supports various combinations of login and remote user credentials and the ability to provide these credentials either on the command line or interactively (via prompts). This section describes a few examples.
Upgrade as the root user
This is a simple example of running the upgrade as root. The root username and password are specified in the command line:
Upgrade as a non-root user
This example specifies the remote user account (-u) and the root user (-U) on the command line. This example assumes that a password is required for the sudo user.
Upgrade using a private key
This example uses a private key instead of a password to access the nodes.
Rolling Upgrade Logs
The rolling upgrade process logs its output to the following file:
The log includes the regular output of the upgrade utility as well as other detailed information that is provided for support use.
After you Upgrade
After you complete the scripted rolling upgrade, complete the following steps:
Update the warden configuration files, which are located in
Manually merge new configuration settings from the
/opt/mapr/conf.new/warden.conffile into the
Manually merge new configuration settings from the files in the
/opt/mapr/conf/conf.d.new/directory to the files in the
For upgrades from 4.0.1, any script that points to files within the
/opt/mapr/hadoop-2.4.1directory must be updated to point to the new hadoop 2.x directory.
--> Back to Upgrading Without the MapR Installer