Step 1. Planning the Upgrade | Step 2. Preparing to Upgrade | Step 3. Upgrading With the MapR Installer or Upgrading Without the MapR Installer | Step 4. Upgrading MapR Clients
The first stage to a successful upgrade process is to plan it ahead of time. This page helps you map out an upgrade process that fits the needs of your cluster and users.
This page contains the following topics:
- Choosing a Cluster Upgrade Method
- Scheduling the Upgrade
- Planning Upgrades to MapR Clients
- Planning Upgrades to Ecosystem Components
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 impacts the flow of events while upgrading packages on nodes, and also impacts the duration of the maintenance window. See below for more details.
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 to 5.0 from the following MapR versions:
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 Paths with the MapR Installer
You can perform an offline upgrade to 5.0 from the following type of cluster:
- MapR 4.1 cluster that was installed using the MapR Installer.
The MapR Installer stops MapReduce v1 jobs, stops services, upgrades the packages, brings the cluster back online, enables certain features, and can upgrade ecosystem components as well.
There are two types of rolling upgrades: manual and scripted. The scripted rolling upgrade is preferred because it it 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.pyr.
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 to 5.0 from the following MapR versions:
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 Node
On each MapR client node, upgrade to the client version that is compatible with the operations that you want to perform on the cluster:
|Supported Client Operations||4.0.1 cluster||4.0.2 cluster||4.1 cluster||5.0 cluster|
|4.0.1 client||4.0.2 client||4.1 client||5.0 client||4.0.1 client||4.0.2 client||4.1 client||5.0 client||4.0.1 client||4.0.2 client||4.1 client||5.0 client||4.0.1 client||4.0.2 client||4.1 client||5.0 client|
|File system Access||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes|
|Submit MapReduce v1 job||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes|
|Submit MapReduce v2 applications||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes||Yes|
|Submit MapReduce v2 applications |
with ResourceManager zero-configuration failover
MapR POSIX Client Nodes
On each MapR POSIX client node, upgrade to the client version that is compatible with the operations that you want to perform on the cluster:
|Supported Client Operations||4.0.2 cluster||4.1 cluster||5.0 cluster|
|4.0.1 client||4.0.2 client||4.1 client||5.0 client||4.0.1 client||4.0.2 client||4.1 client||5.0 client||4.0.1 client||4.0.2 client||4.1 client||5.0 client|
|File system Access||N/A||Yes||Yes||Yes||N/A||Yes||Yes||Yes|
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. Based on the method that you use to upgrade the cluster, the process that you take to plan and perform the upgrade differ.
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. For example, If you have Hive 0.13-1504 installed, the MapR Installer will update Hive 0.13 to the latest Hive 0.13 version that is available.
- Forces the upgrade of ecosystem components with versions that are not compatible with the MapR version you are upgrading to.
- Allows you to upgrade existing ecosystem components if newer version are available.
Note that 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, consider the following:
- 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.
If you are upgrading from 3.x, you must upgrade all ecosystem packages, regardless of the ecosystem version you are running.
- Install the same version (or a later 4.1 supported version) of the ecosystem package on the upgraded cluster.
- MapR re-releases major versions of ecosystem products on a monthly basis. If you have an existing version of a component that matches a major supported version of that product, you still need to upgrade to the latest ecosystem release of that major version. For example, you may have hive-13-1405 installed, but you need to upgrade to a more recently released version: hive-13-1508 (mapr-hive-0.13.201509211105-1.noarch.rpm).
If you need to upgrade one or more ecosystem component, complete the MapR Core upgrade first and then upgrade each ecosystem component.