Planning the MapR Core Upgrade
This section describes how to develop a sucessful plan for your upgrade process.
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 InstallerYou can perform an offline upgrade from the following MapR versions:
- 3.x
- 4.0.x
- 4.1
- 5.x
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.
You can perform a manual rolling upgrade or a scripted rolling upgrade from the following MapR versions:
- 4.0.x
- 4.1
- 5.x
Updating the JDK
Check the JDK Support Matrix to verify that your JDK version is supported by the MapR version to which you are upgrading. If your old MapR version was 3.0 and the new MapR version is 5.x, you might need to update JDK 6 to JDK 7 or 8. See the JDK Support Matrix for more information.
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. You 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.
- File system access
- Submit MapReduce (MR) v1 job
- Submit MapReduce v2 applications
- Submit MapReduce v2 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 5.1, MapR FUSE-based POSIX clients are available, in addition to MapR loopback NFS 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.
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.2 cluster supports 4.0.2, 4.1, 5.0, 5.1, and 5.2 Mapr loopback NFS clients.
| 5.2 client | 5.1 client | 5.0 client | 4.1 client | 4.0.2 client | 4.0.1 client | |
|---|---|---|---|---|---|---|
| 5.2 cluster | Yes | Yes | Yes | Yes | Yes | N/A |
| 5.1 cluster | Yes | Yes (recommended) | Yes | Yes | Yes | N/A |
| 5.0 cluster | Yes | Yes (recommended) | Yes | Yes | Yes | N/A |
| 4.1 cluster | Yes | Yes (recommended) | Yes | Yes | Yes | N/A |
| 4.0.2 cluster | Yes | Yes | Yes | Yes | Yes | N/A |
Determining Cross-Cluster Feature Support
- 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.2 cluster. However, mirroring from a higher version in source cluster to a lower version in destination cluster is supported only if new features are not enabled in the source cluster. For example, you can mirror volumes from a MapR 5.2 cluster to a MapR 5.1 cluster (only) if new features are not enabled in the MapR 5.2 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.NOTE: As of MapR 5.2, MapR-DB JSON table replication is also supported. You cannot replicate MapR-DB JSON tables to cluster that runs a version prior to 5.2.
Planning for the MapR Expansion Pack
To plan for the MapR Expansion Pack (MEP), see Planning MapR Expansion Pack Upgrades.
Planning for Port Changes
Upgrading to MapR 5.2.x might require you to open additional ports on your firewall to take advantage of new features. For example, the Multi-MFS feature allows multiple instances of the FileServer to run on a single node in a single process. However, each instance listens on its own set of ports, and you must ensure that these ports are open. For more information about the ports used by specific services, see Ports Used by MapR. For information about Multi-MFS, see Working with Multiple Instances of the MapR-FS.