HPE Ezmeral Data Fabric 6.2 is In Maintenance and transitions to "End of Maintenance" in June 2024. Please see the latest documentation.

About Release 6.2
This site contains documentation for HPE Ezmeral Data Fabric release 6.2 including installation, configuration, administration, and reference content, as well as content for the associated bundled ecosystem components and drivers.
6.2 Installation
This section contains information about installing and upgrading HPE Ezmeral Data Fabric software. It also contains information about how to migrate data and applications from an Apache Hadoop cluster to a HPE Ezmeral Data Fabric cluster.
6.2 Data Fabric
HPE Ezmeral Data Fabric is the industry-leading data platform for AI and analytics that solves enterprise business needs.
6.2 Administration
This section describes how to manage the nodes and services that make up a cluster.
- Administering Users and Clusters
  Lists topics that help manage a data-fabric cluster.
- Administering Nodes
  Provides a synopsis of managing nodes in a cluster.
- Administering Volumes
  This section provide information about how to organize and manage data using volumes, a unique feature of HPE Ezmeral Data Fabric clusters.
- Administering Files and Directories
- Administering Tables
  Administration of the HPE Ezmeral Data Fabric Database is done primarily via the command line (maprcli) or with the Managed Control System (MCS). Regardless of whether the HPE Ezmeral Data Fabric Database table is used for binary files or JSON documents, the same types of commands are used with slightly different parameter options. HPE Ezmeral Data Fabric Database administration is associated with tables, columns and column families, and table regions.
- Administering Streams
- Administering Data Fabric Gateways
  A HPE Ezmeral Data Fabric gateway mediates one-way communication between a source HPE Ezmeral Data Fabric cluster and a destination cluster. You can replicate HPE Ezmeral Data Fabric Database tables (binary and JSON) and HPE Ezmeral Data Fabric Streams streams. HPE Ezmeral Data Fabric gateways also apply updates from JSON tables to their secondary indexes and propagate Change Data Capture (CDC) logs.
- Administering Services
- Monitoring the Cluster
  This section describes how to monitor the health and performance of a MapR cluster.
- Configuring Security
  Describes how to configure security and manage secure clusters.
- Managing Secure Clusters
  Provides procedures that will enable you to use MapR clusters securely.
- Administering the Data Access Gateway
  The HPE Ezmeral Data Fabric Data Access Gateway is a service that acts as a proxy and gateway for translating requests between lightweight client applications and the HPE Ezmeral Data Fabric cluster. This section describes considerations when upgrading the service, how to modify configuration settings, and how to administer and manage the service.
- Planning for High Availability
- Administrator's Reference
  This section contains in-depth reference information for the administrator.
  - maprcli and REST API Syntax
    This section provides information about the HPE Ezmeral Data Fabric command API. Most commands can be run on the command-line interface (CLI), or by making REST requests programmatically or in a browser.
  - Utilities
    Contains information about various scripts and utilities, that help setup, maintain, and monitor clusters.
  - Configuration Files
    This section contains reference information about various configuration files.
  - Alarms Reference
    The pages in this section provide details about all of the types of alarms.
    - User/Group Alarms
    - Cluster Alarms
    - Node Alarms
    - Table-Replication Alarms
    - Secondary Index Alarms
    - Volume Alarms
      - Compaction Failed
      - Compaction Skipped Large Container Volume Alarm
        Compaction is skipped due to large container with garbage below the garbage threshold in the container.
      - Data Unavailable
      - Data Under-Replicated
        Describe the alarm that is triggered when a volume is under replicated.
      - Warm-Tier Data Node Down
        Provides the resolution for the Warm-Tier Data Node Down alarm.
      - Data Under-Encoded
      - Data Below-Parity
      - Offload/Recall Failed
      - Inodes Limit Exceeded
      - Large Row
      - Mirror Failure
      - No Nodes in Topology
      - Snapshot Failure
      - Snapshot Restore Failure
        Describes the alarm that is triggered when the Snapshot Restore operation fails repeatedly.
      - Topology Almost Full
      - Label Almost Full
        The alarm that is triggered when Storage Pools/Nodes with the specified label are running out of space.
      - Topology Full Alarm
      - Label Full Alarm
        The alarm that is triggered when Storage Pools/Nodes with the specified label are completely out of space.
      - Volume Advisory Quota Alarm
      - Volume Become Master Stuck
      - Volume with Non-Local Containers
      - Volume Quota Alarm
  - HPE Ezmeral Data Fabric Environment
    This section provides information associated with the Data Fabric environment.
- Troubleshooting Cluster Administration
  Lists the common errors and their solutions.
- Best Practices for Backing Up HPE Ezmeral Data Fabric Information
  Lists the best practices and performance considerations to follow when backing up HPE Ezmeral Data Fabric information.
6.2 Development
This section contains information related to application development for Ezmeral ecosystem components and HPE Ezmeral Data Fabric products, including the file system, Database (Key-Value and JSON), and Event Streams.
Other Docs
This section contains release-independent information, including: Installer documentation, Ecosystem release notes, interoperability matrices, security vulnerabilities, and links to other data-fabric version documentation.
Glossary
Definitions for commonly used terms in MapR Converged Data Platform environments.

Mirror Failure

UI Column: Mirror Alarm
Logged As: VOLUME_ALARM_MIRROR_FAILURE
Meaning: A mirror operation failed.
Resolution: Make sure the CLDB is running on both the source cluster and the destination cluster. Look at the CLDB log (/opt/mapr/logs/cldb.log) and the MapR filesystem log (/opt/mapr/logs/mfs.log) on both clusters for more information. If the attempted mirror operation was between two clusters, make sure that both clusters are reachable over the network. Make sure the source volume is available and reachable from the cluster that is performing the mirror operation. For more troubleshooting information, see how to handle this alarm.