Planning Your MapR Core 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

Supported upgrade methods are:

Upgrade Workflows describes these methods in more detail. The method you choose affects the flow of events while upgrading packages on nodes and the duration of the maintenance window.

The following table summarizes the MapR core upgrade paths supported for each method:

Upgrade From	Upgrade To	Offline	Rolling
3.x	MapR 6.1.0	Yes	No
4.x	MapR 6.1.0	Yes	No*
5.x	MapR 6.1.0	Yes	Yes**
6.x	MapR 6.1.0	Yes	Yes

*Rolling upgrades from 4.x to 5.x are supported, after which you may perform another rolling upgrade from 5.x to 6.x.

**MapR core by itself supports rolling upgrades from release 5.x to later releases. If your cluster includes MapR core and MapR ecosystem components, rolling upgrades to release 6.x are supported only from release 5.2.x and EEP 3.0.1 or later. Ecosystem components will continue to work during a rolling upgrade of MapR core as long as the ecosystem components are not updated. But the rolling upgrade of ecosystem components is not supported. If you choose to upgrade MapR core and ecosystem components together, the ecosystem components might not function properly during the upgrade process.

The following table summarizes upgrade support for Ezmeral Ecosystem Packs (EEPs):

Upgrade From	Upgrade To	Offline	Rolling
Pre-MEP	EEP 6.0.0	Yes	No
EEP 1.1.x	EEP 6.0.0	Yes	No
EEP 2.x	EEP 6.0.0	Yes	No
EEP 3.0.1+	EEP 6.0.0	Yes	Yes*
EEP 4.x	EEP 6.0.0	Yes	Yes*
EEP 5.x	EEP 6.0.0	Yes	Yes*

*A rolling upgrade of MapR core is supported, and ecosystem components will continue to work during the rolling upgrade, but a rolling upgrade of ecosystem components is not supported.

Transition EEPs

The following EEPs are considered transition EEPs because you can upgrade these EEPs directly to release 6.1.0 using a rolling upgrade (for components that support a rolling upgrade):

EEP 3.0.1 and later 3.0.x
EEP 4.x
EEP 5.x

Transition EEPs can coexist with release 6.1.0 only during the course of an upgrade. You must not enable release 6.1.0 new features while a transition EEP is in use on release 6.1.0. You must upgrade to EEP 6.0.0 before enabling new features for release 6.1.0.

Offline Upgrade

The offline upgrade process is simpler than a rolling upgrade, and usually completes faster. In an offline upgrade, MapR software processes and the jobs that depend on them are stopped on all nodes so that packages can be updated. 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 core versions:

MapR 6.x
MapR 5.x
MapR 4.1
MapR 4.0.x
MapR 3.x

NOTE After upgrading MapR core to release 6.0 or later, you must upgrade ecosystem components to an EEP that is compatible with your core 6.0 or later release. To determine the compatible EEPs, see EEP Support and Lifecycle Status. This must be done before you enable core features.

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).
Brings the cluster back online at once.

Rolling Upgrade

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 following restrictions apply to rolling upgrades:

In release 6.0 and later, only manual rolling upgrades are supported. Scripted rolling upgrades are not supported.
Rolling upgrades only upgrade core packages, not ecosystem components. A rolling upgrade of ecosystem components is not supported.
If you choose to do a rolling upgrade on a cluster with core and ecosystem components, the ecosystem components will continue to work during the rolling upgrade as long as the ecosystem components are not updated. If you choose to upgrade core and ecosystem components together, the ecosystem components might not function properly during the upgrade process.
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 from only the following core versions:

Release 5.2.x with EEP 3.0.1 or later
Release 6.x with EEP 4.0.0 or later

NOTE After upgrading core, you must upgrade ecosystem components to EEP 4.0.0 or later, and this must be done before you enable release 6.x or later features. To determine the EEP required by your release, see EEP Support and Lifecycle Status.

Updating the JDK

Check the JDK Support Matrix to verify that your JDK version is supported by the core version to which you are upgrading. Releases 6.0 and 6.1 require JDK 8. For more information, see the JDK Support Matrix.

Planning for Security

Security is not enabled by default for upgrades. During an upgrade, the security attributes of your cluster are preserved unless you decide to change them. Note that if you have configured security on a release 5.2.x cluster, you cannot use the MapR Installer or Stanzas to upgrade. You must upgrade manually. For information about custom security, see Customizing Security in MapR.

Before upgrading core software, make sure that you have reviewed the list of known vulnerabilities in Security Vulnerabilities. If a vulnerability applies to your release, contact your HPE support representative for a fix, and apply the fix immediately, if applicable.

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 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. You upgrade MapR client nodes after you upgrade the cluster nodes but before enabling new features.

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 following client operations are supported on 4.0.x and 5.x clusters and clients.

File system access
Submit MapReduce (MR) v1 job
Submit MapReduce v2 applications

The following client operation is supported on 4.0.2 and higher clusters with 4.0.2 and higher clients. For example, this operation is not available on a 5.1 cluster with a 4.0.1 client.

Submit MapReduce version 2 applications with Resource Manager zero-configuration failover

MapR POSIX Client Nodes

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

NOTE Only releases 5.1 or higher support MapR FUSE-based POSIX clients.

MapR POSIX loopback NFS clients can be upgraded, or a fresh install can be performed.

See Upgrading the 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 release 5.1 or higher because the FUSE-based POSIX client can only connect to clusters running release v5.1 or higher.

The following table shows which MapR loopback NFS client versions are supported by which MapR data-fabric clusters. For example, the release 6.0 cluster supports 4.0.2, 4.1, 5.0, 5.1, and 5.2 loopback NFS clients.

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

Determining Cross-Cluster Feature Support

MapR Data Platform 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 works from a lower MapR version to a higher MapR version irrespective of the features that you enable on the higher version. For example, you can mirror volumes from a release 6.1 cluster to a release 6.2 cluster irrespective of whether or not you have enabled the new features present in the release 6.2 version.
However, volume mirroring from a higher release version to a lower release version works only when you enable identical sets of features on both clusters. For example, you can mirror volumes from a release 6.2 cluster to a release 6.1 cluster only if you do not enable new features that are present on the release 6.2 cluster.
Table Replication: Table replication works between clusters of different versions as long as both versions support MapR Database table replication. For example, you can replicate MapR Database binary tables from a release 6.2 cluster to a release 6.0 cluster.
NOTE As of release 5.2, MapR Database JSON table replication is also supported. You cannot replicate MapR Database JSON tables to a cluster that runs a version prior to release 5.2.

Planning for the Ezmeral Ecosystem Pack

To plan for the Ezmeral Ecosystem Pack (EEP), see Planning Ezmeral Ecosystem Pack Upgrades.

What's Next

Go to Preparing to Upgrade MapR Core.