Upgrade Notes (Release 7.6.1)

Describes the high-level steps and considerations for upgrading to release 7.6.1.

Upgrading to Release 7.6.1 (High-Level Steps)

Depending on your current Data Fabric release, upgrading to release 7.6.1 can require different combinations of procedures. Upgrading to release 7.6.1 can require an OS upgrade and requires a JDK upgrade if your cluster is running release 6.1.x or earlier. The following table summarizes the high-level upgrade steps. Before beginning the upgrade, be sure to review the upgrade considerations later on this page.
If your cluster is running one of these releases Use these steps to upgrade to release 7.6.1 See for more information









  1. Upgrade your OS to an OS that is supported by your current release and release 7.6.1. For example:
    • RHEL 8.2, 8.4, 8.6*, or 8.8
    • Ubuntu 18.04 or 20.04**
    • SLES 15 SP2 or SP3
    You can skip the OS upgrade if the Operating System Support Matrix shows that your current OS is supported on release 7.6.1.
  2. Install Java JDK 11 or JDK 17 or the equivalent.
  3. Upgrade from your current release to release 7.6.1 using one of the upgrade workflows.
  4. Upgrade your EEP components after upgrading core, as indicated in the workflow.

*Release 7.6.1 can be used with odd-numbered RHEL releases 8.1, 8.3, and 8.5, but Red Hat recommends upgrading from RHEL 7.x to even-numbered RHEL releases. For more information, see this article.

**See the upgrade consideration for Ubuntu later on this page.

Professional Support for Upgrades

Upgrading can be time-consuming and complicated. Consider engaging HPE professional support services to assist in planning and executing your upgrade. For more information, contact your support representative. See Contact HPE.

Upgrading a Nonsecure Cluster to Data Fabric 7.x

Nonsecure clusters are not supported on Data Fabric 7.x releases. To upgrade a nonsecure cluster to a 7.x release, secure the cluster first. Then follow the upgrade steps for the release to which you are upgrading.

Release 7.6.1 Requires EEP 9.2.1

Release 7.6.1 requires EEP 9.2.1 or later. For more information about EEPs, see What's New in EEP 9.2.1 and EEP 9.2.1 Reference Information.

Upgrades Using the Installer

Note these considerations for using the Installer to upgrade to release 7.6.1:
  • Only Installer can be used to upgrade to release 7.6.1. For more info, see Installer Updates.
  • Installer supports core upgrades from release 7.4.0 or 7.5.0 to 7.6.1 only. Other core upgrades must be performed using manual steps. See Upgrading Core With the Installer and Upgrading the Ecosystem Pack Without the Installer. All EEP upgrades are supported.
  • Installer is not supported for use with JRE 17 or JDK 17 and will not install JDK 17.
  • Installer cannot be used with older versions of Ubuntu. For more information, see Installer Updates and Selecting an Installer Version to Use.
  • For releases 7.0.0 and later, Installer enforces security by default. You cannot install a non-secure cluster by using Installer, though it is still possible to install a nonsecure cluster by using Stanzas.
  • You cannot use Installer to install Zeppelin. You must install Zeppelin by using the manual steps. See Installing Zeppelin.
  • The Installer is not FIPS compliant and is not supported to run on a FIPS-enabled node. However, you can use the Installer to install a FIPS-compliant cluster. To do this, the Installer node must be installed on a non-FIPS node, and the cluster to be installed cannot include the Installer node as part of the cluster.
  • You can use Installer to install a FIPS-enabled cluster only if all the nodes to be installed are FIPS-enabled. Using the Installer to install a mix of FIPS-enabled and non-FIPS-enabled nodes is not supported.
  • For a list of the operating systems that support Installer, see Installer Support Matrix.
  • For a list of known issues that affect Installer and other Installer versions, see Installer Known Issues.

Online Versus Offline Upgrades

You can upgrade core software using a "rolling upgrade" process that transitions the cluster to release 7.6.1 one node at a time. Except for the node being upgraded, the cluster remains online during this process.
IMPORTANT You cannot upgrade EEP components using an online or "rolling upgrade" process. EEP upgrades are always an offline process.

If you are upgrading from releases 7.2.0, 7.3.0, 7.4.0, or 7.5.0 to 7.6.1, EEP 9.2.1 can be used as a bridging EEP. A bridging EEP is an EEP that is supported on both the release you are currently running and the release to which you want to upgrade. EEP 9.2.1 can be installed on releases 7.2.0, 7.3.0, 7.4.0, 7.5.0, and on release 7.6.1.

EEP Support and Lifecycle Status shows the EEPs that are supported for each core version.

If you are upgrading from release 6.1.x, 6.2.0, 7.0.0, or 7.1.0 to release 7.6.1, no bridging EEP is available. However, you can upgrade core directly to release 7.6.1. You do not need to upgrade to another release first.
CAUTION Before upgrading directly from release 6.1.x or later to 7.6.1, be sure to review the COMSECURE-615 known issue in Known Issues (Release 7.6.1).

Data Access Gateway 6.x and Streams Upgrade Consideration

For the gateway to lightweight client applications, release 7.6.1 requires Data Access Gateway 6.2. Data Access Gateway 6.2 can only be used with core 7.6.1, 7.5.0, 7.4.0, 7.3.0, and 7.2.0 with some restrictions.
CAUTION Streams users who upgrade from release 7.1.0 (DAG 5.0) or release 7.2.0 (DAG 5.1) to release 7.3.0 (DAG 6.0) or 7.4.0 (DAG 6.1) or 7.5.0 (DAG 6.2) or 7.6.1 (DAG 6.2) will not be able to access topics configured using the pre-DAG 6.0 mapping rules.

For more information, see Understanding the HPE Ezmeral Data Fabric Data Access Gateway and the Data Access Gateway 6.2 Release Notes.

32-GB Minimum Memory for Production Nodes

Minimum memory requirements for production nodes have changed. Production nodes require at least 32 GB of memory per node. For more information, see Memory and Disk Space.

Upgrading Object Store

Upgrades from release 7.0.0 to 7.1.0 or later remove the Object Store configuration files in /opt/mapr/conf. This can prevent the Object Store from starting after the upgrade. To address this issue, the following upgrade pages instruct you to make a copy of certain files before upgrading and then restore the files to all nodes running the MOSS server after the upgrade:

Upgrades to CentOS Not Supported

Release 7.6.1 is not supported for use with CentOS. CentOS Linux 8 has reached End of Life (EOL) status. For more information, see this page.

Upgrades From Non-FIPS Mode to FIPS Mode Not Supported

Only new installations of FIPS clusters are currently supported. You cannot use the Installer or manual steps to upgrade a non-FIPS-compliant cluster to a FIPS-compliant cluster.

Upgrading from Ubuntu 16.0.4 to Release 7.6.1

Upgrading from Ubuntu 16.04 to release 7.6.1 requires a slightly different set of upgrade steps because:
  • Release 7.6.1 cannot be used with Ubuntu 16.04.
  • EEP 8.0.0 and later are not supported on Ubuntu 16.04.
  • Installer and later cannot be used with Ubuntu 16.04.
To perform the upgrade:
  1. Upgrade your OS to Ubuntu 18.04 or 20.04. See Upgrading Your Linux Operating System.
  2. If you are using the Installer, update it to the latest version. See Updating the Installer.
  3. Upgrade to EEP 9.2.1 and release 7.6.1 using the preceding high-level steps.

For a list of the operating systems on which you can install different versions of core, see Operating System Support Matrix.

SLES Upgrades Require the Option to Address a Package Vendor Change

In releases 7.0.0 and later, the vendor for core packages changed to "Hewlett Packard Enterprise." In earlier releases, the vendor was "MapR Technologies Inc." This change can affect SLES upgrades.

For a manual upgrade from release 6.2.0 to releases 7.0.0 or later on SLES SP2, the zypper update command can fail because of a vendor mismatch in the RPM provider. Zypper returns an error saying that the vendor for the package you are trying to upgrade has changed.

To avoid this error, add the --allow-vendor-change option to the zypper update command. For an example, see Offline and Manual Upgrade Procedure.

Upgrades and Clear-Text Passwords

Upgrades from releases 6.1.x or 6.2.0 to releases 7.1.0 and later leave the clear-text passwords in the ssl-server.xml and ssl-client.xml configuration files unchanged. However, after applications are tested and the upgrade is known to be successful, the cluster administrator can remove the clear-text passwords. For more information, see Removing Clear-Text Passwords After Upgrade.

configure.sh -R Behavior in Release 7.0.0 or Later

The following changes to configure.sh -R behavior occur when you upgrade from a release earlier than 7.0.0 to releases 7.0.0 or later:
  • mrhsm configuration files are automatically upgraded to support the new PKCS#11 file-store feature.
  • If the legacy cldb.key and/or dare.master.key exist in the ${MAPR_HOME}/conf/ directory, software automatically enables the PKCS#11 file store and imports these keys into the ${MAPR_HOME}/conf/tokens directory. Since, these legacy keys are no longer needed, it is a best practice to move them to a safe place to increase security. It is optional to copy over the ${MAPR_HOME}/conf/tokens to other nodes, as every occurrence imports the same keys during an upgrade:
    • By default, data-fabric software initializes mrhsm using the same default hsm label and so pin as when you do a new release 7.0.0 installation if mrhsm has not already been initialized. You can change these default values by specifying -hsmlabel <label> -hsmsopin <so-pin> options.
    • If mrhsm has already been initialized to use KMIP, you need to specify the -hsmsopin <so-pin> option to enable the file store correctly.

Hadoop and YARN Are Provided as Ecosystem Components

Beginning with core 6.2.0 and EEP 7.0.0, Hadoop and YARN services are no longer included in the repository for core packages. They are provided as ecosystem components in the EEP repository. If you are upgrading and need Hadoop and YARN services, you must install the packages as ecosystem components after upgrading. For more information, see Installing Hadoop and YARN.

Regenerating the mapruserticket File

Changes to the CanImpersonate parameter of the mapruserticket file in release 6.1.0 require users who upgrade manually to regenerate the file before restarting Warden. See Step 1: Restart and Check Cluster Services.

The file needs to be regenerated to ensure that impersonation works correctly for non-mapr users. Prior to release 6.1.0, all mapruserticket files were generated with CanImpersonate = false. Releases 6.1.0 and later enforce the CanImpersonate parameter and set the parameter to true for freshly installed clusters. For upgraded clusters, if CanImpersonate is not set to true, some services will not be able to impersonate.