Preparing to Upgrade

After you have planned your upgrade process, prepare the cluster for upgrade while your existing cluster is fully operational. Prepare to upgrade as described in this section to minimizes downtime and eliminate unnecessary risk. Design and run health tests and back up critical data. Performing these tasks during upgrading reduces the number of times you have to touch each node, but increases down-time during upgrade. Upgrade a test cluster befor upgrading your production cluster.

1. Verify System Requirements for All Nodes

Verify that all nodes meet the following minimum requirements for the new version of MapR software:

• Software dependencies. Packages dependencies in the MapR distribution can change from version to version. If the new version of MapR has dependencies that were not present in the older version, you must address them on all nodes before upgrading MapR software. Installing dependency packages can be done while the cluster is operational. See Packages and Dependencies for MapR Software. If you are using a package manager, you can specify a repository that contains the dependency package(s), and allow the package manager to automatically install them when you upgrade the MapR packages. If you are installing from package files, you must pre-install dependencies on all nodes manually.
• Hardware requirements. The newer version of packages might have greater hardware requirements. Hardware requirements must be met before upgrading.
• OS requirements. MapR’s OS requirements do not change frequently. If the OS on a node doesn’t meet the requirements for the newer version of MapR, plan to decommission the node and re-deploy it with updated OS after the upgrade.
• Certificate requirements. Recent versions of Safari and Chrome web browsers have removed support for older certificate cipher algorithms, including those used by some versions of MapR. For more information on resolving this issue, see Unable to Establish a Secure Connection.

2. Design Health Checks

Plan what kind of test jobs and scripts you will use to verify cluster health as part of the upgrade process. You will verify cluster health several times before, during, and after upgrade to ensure success at every step, and to isolate issues whenever they occur. Create both simple tests to verify that cluster services start and respond, as well as non-trivial tests that verify workload-specific aspects of your cluster.

Design Simple Tests

Here are a few examples of simples tests you can design to check node health:

• Use maprcli commands to see if any alerts exist and to verify that services are running as expected. For example:

  # maprcli node list -columns svc
  service                                                     hostname  ip          
  tasktracker,cldb,fileserver,hoststats                       centos55  10.10.82.55 
  tasktracker,hbregionserver,fileserver,hoststats             centos56  10.10.82.56 
  fileserver,tasktracker,hbregionserver,hoststats             centos57  10.10.82.57 
  fileserver,tasktracker,hbregionserver,webserver,hoststats   centos58  10.10.82.58 
  ...lines deleted...
  # maprcli alarm list
  alarm state  description                                                                                          entity    alarm name                             alarm statechange time 
  1            One or more licenses is about to expire within 25 days                                               CLUSTER   CLUSTER_ALARM_LICENSE_NEAR_EXPIRATION  1366142919009          
  1            Can not determine if service: nfs is running. Check logs at: /opt/mapr/logs/nfsserver.log            centos58  NODE_ALARM_SERVICE_NFS_DOWN            1366194786905          

  In this example you can see that an alarm is raised indicating that MapR is expecting an NFS server to be running on node centos58, and the node list of running services confirms that the nfs service is not running on this node.

• Batch create a set of test files.
• Submit a MapReduce job.
• Run simple checks on installed Hadoop ecosystem components. For example:
  • Run a Hive query.
  • Do a put and get from HBase.
  • Run hbase hbck to verify consistency of the HBase datastore. Address any issues that are found.

Design Non-trivial Tests

3. Verify Cluster Health

Verify cluster health before beginning the upgrade process. Proceed with the upgrade only if the cluster is in an expected, healthy state. Otherwise, if cluster health does not check out after upgrade, you can’t isolate the cause to be related to the upgrade.

Run the suite of simple tests to verify that basic features of the MapR core are functioning correctly, and that any alarms are known and accounted for. Run your suite of non-trivial tests to verify that the cluster is running as expected for typical workload, including integration with Hadoop ecosystem components and third-party tools.

4. Back Up Critical Data

Data in the MapR cluster persists across upgrades from version to version. However, as a precaution you might want to back up critical data before upgrading. If you deem it practical and necessary, you can do any of the following:

• Copy data out of the cluster using distcp to a separate, non-Hadoop datastore.
• Mirror critical volume(s) into a separate MapR cluster, creating a read-only copy of the data which can be accessed via the other cluster.

When services for the new version are activated, MapR-FS will update data on disk automatically. The migration is transparent to users and administrators. Once the cluster is active with the new version, you typically cannot roll back.

5. Perform MapR Installer Pre-upgrade Steps

6. Run Your Upgrade Plan on a Test Cluster

What's Next

Go to Upgrading with the MapR Installer.