Planning the Upgrade

The key to a successful upgrade process is to plan the process ahead of time. This page helps you develop an upgrade process that fits the needs of your cluster and users.

Choosing a Cluster Upgrade Method

Choose the upgrade method and form your upgrade plans based on this choice. MapR provides an offline upgrade method, as well as a rolling upgrade method for clusters that meet certain criteria. The method you choose affects the flow of events while upgrading packages on nodes and the duration of the maintenance window.

Offline Upgrade

The offline upgrade process is simpler than a rolling upgrade, and usually completes faster. Offline upgrade is the default upgrade method when other methods cannot be used.

Offline Upgrade Paths without the MapR Installer

You can perform an offline upgrade from the following MapR versions:

3.x
4.0.x
4.1
5.0

During the maintenance window, the administrator stops all jobs on the cluster, stops all cluster services, upgrades packages on all nodes (which can be done in parallel), and then brings the cluster back online at once.

Offline Upgrade Path with the MapR Installer

You can perform an offline upgrade from a MapR cluster that was installed using the MapR Installer. The MapR Installer stops MapReduce jobs, stops services, upgrades the packages, brings the cluster back online, enables certain features, and can upgrade ecosystem components as well.

Rolling Upgrade

There are two types of rolling upgrades: manual and scripted. The scripted rolling upgrade is preferred because it is less prone to errors.

In a manual rolling upgrade, you upgrade the MapR software one node at a time so that the cluster as a whole remains operational throughout the process. The fileserver service on each node goes offline while packages are upgraded, but its absence is short enough that the cluster does not raise the data under-replication alarm.

The scripted rolling upgrade keeps the file system online throughout the upgrade process, which allows for reads and writes for critical data streams. With scripted rolling upgrade, the administrator downloads the scripted installer mapr-setup file, runs it to unpack upgrade script, and runs /opt/mapr-installer/bin/upgrade (with relevant options) which, in turn, invokes mapr_upgrade.py.

The following restrictions apply to rolling upgrade:

Rolling upgrades only upgrade MapR packages, not ecosystem components.
The administrator should block off a maintenance window, during which only critical jobs are allowed to run and users expect longer-than-average run times.

Rolling Upgrade Paths

You can perform a manual rolling upgrade or a scripted rolling upgrade from the following MapR versions:

4.0.x
4.1
5.0

Scheduling the Upgrade

Consider the following factors when scheduling the upgrade:

When will preparation steps be performed? How much of the process can be performed before the maintenance window?
What calendar time would minimize disruption in terms of workload, access to data, and other stakeholder needs?
How many nodes need to be upgraded? How long will the upgrade process take for each node, and for the cluster as a whole?
When should the cluster stop accepting new non-critical jobs?
When (or will) existing jobs be terminated?
How long will it take to clear the pipeline of current workload?
Will other Hadoop ecosystem components (such as HBase or Hive) get upgraded during the same maintenance window?
When and how will stakeholders be notified?

Planning Upgrades to MapR Clients

Determine if you need to upgrade MapR client nodes. Upgrade MapR client nodes after you upgrade the MapR cluster nodes.

MapR Client Nodes

On each MapR client node, upgrade to the client version that is compatible with the operations that you want to perform on the cluster. The following table shows which supported client operations are available based on the client version and the cluster version. The supported client operations are:

File system access
Submit MapReduce (MR) v1 job
Submit MapReduce v2 applications
Submit MapReduce v2 applications with Resource Manager zero-configuration failover

Supported Client Operations	4.0.1 cluster					4.0.2 cluster					4.1 cluster
	4.0.1 client	4.0.2 client	4.1 client	5.0 client	5.1 client	4.0.1 client	4.0.2 client	4.1 client	5.0 client	5.1 client	4.0.1 client	4.0.2 client	4.1 client	5.0 client	5.1 client
File system access	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Submit MR v1 job	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Submit MR v2 apps	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Submit MR v2 apps RM 0-config failover	N/A	N/A	N/A	N/A	N/A	No	Yes	Yes	Yes	Yes	No	Yes	Yes	Yes	Yes

Supported Client Operations	5.0 cluster					5.1 cluster
	4.0.1 client	4.0.2 client	4.1 client	5.0 client	5.1 client	4.0.1 client	4.0.2 client	4.1 client	5.0 client	5.1 client
File system access	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Submit MR v1 job	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Submit MR v2 apps	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Submit MR v2 apps RM 0-config failover	No	Yes	Yes	Yes	Yes	No	Yes	Yes	Yes	Yes

MapR POSIX Client Nodes

On MapR POSIX client nodes, the only supported client operation is file system access. As of 5.1, MapR FUSE-based POSIX clients are available, in addition to MapR loopback NFS clients.

NOTE: Only MapR 5.1 clusters support MapR FUSE-based POSIX clients.

MapR POSIX loopback NFS clients can be upgraded or a fresh install can be performed. Additionally, MapR POSIX loopback NFS clients can be migrated to a FUSE-based POSIX Basic client. MapR POSIX loopback NFS clients can not be migrated to FUSE-based Platinum POSIX clients.

See Upgrade MapR POSIX loopbacknfs Client and Migrating to FUSE-based POSIX Clients for more information.

NOTE: Basic and Platinum POSIX client packages are recommended for fresh installation and for all new clusters.

Upgrade to the client version supported by your cluster, as shown in the following table. Upgrading to the 5.x client is recommended for 4.1 and 5.x clusters of MapR loopbacknfs POSIX nodes. If you plan on using FUSE-based POSIX clients, ensure that the cluster has been upgraded to MapR 5.1 or higher because the FUSE-based POSIX client can only connect to clusters running MapR v5.1 or higher.

The following table shows which MapR loopback NFS client versions are supported by which MapR clusters. For example, the MapR 5.1 cluster supports 4.0.2, 4.1, 5.0, and 5.1 Mapr loopback NFS clients.

Table 1. MapR loopback NFS POSIX Client Upgrades
4.0.2 cluster					4.1 cluster
4.0.1 client	4.0.2 client	4.1 client	5.0 client	5.1 client	4.0.1 client	4.0.2 client	4.1 client	5.0 client	5.1 client
N/A	Yes	Yes	Yes	Yes	N/A	Yes	Yes	Yes	Yes (recommended)

5.0 cluster					5.1 cluster
4.0.1 client	4.0.2 client	4.1 client	5.0 client	5.1 client	4.0.1 client	4.0.2 client	4.1 client	5.0 client	5.1 client
N/A	Yes	Yes	Yes	Yes (recommended)	N/A	Yes	Yes	Yes	Yes (recommended)

Determining Cross-Cluster Feature Support

MapR supports features that operate on more than one cluster. Before you upgrade, consider the impact of the following cross-cluster features:

Volume Mirroring: Volume mirroring from a lower MapR version to higher MapR version is supported. For example, you can mirror volumes from a MapR 4.0.1 cluster to a MapR 5.1 cluster. However, you cannot mirror volumes from a MapR 5.1 cluster to a MapR 4.0.1 cluster.
Table Replication: Table replication works between clusters of different versions as long as both versions support MapR-DB table replication. For example, you can replicate MapR-DB binary tables from a MapR 5.1 cluster to a MapR 4.1 cluster.

Planning Upgrades to Ecosystem Components

Before you upgrade, refer to the Interoperability Matrix to see which ecosystem components are supported with the version of MapR that you are upgrading to.

Depending on the method used to upgrade the cluster, the process used to plan and perform the upgrade is different.

Upgrading Ecosystem Components Using the MapR Installer

The MapR Installer upgrades the cluster and ecosystem components at the same time.Therefore, before you start the MapR Installer to perform an upgrade, consider that the MapR Installer does the following during an upgrade:

Automatically updates ecosystem components to the latest available MapR version of that component version.
Forces the upgrade of ecosystem components when the existing versions are not compatible with the new MapR version.
Allows you to upgrade existing ecosystem components if newer version are available.

You will need to perform pre-upgrade steps for each ecosystem component prior to launching the MapR Installer Web Interface.

Upgrading Ecosystem Components with Manual Steps

When you plan to manually upgrade ecosystem components, you may need to upgrade a supported version of an ecosystem component to a more recent supported version in order to ensure cross-compatibility among the ecosystem components in the cluster.

What's Next

Go to Preparing to Upgrade.