MapR 5.1 is at End of Life (EOL) and no longer supported. Please see the latest documentation. This documentation is not being updated.

5.1 DB & Streams
This section covers the MapR-DB, MapR-Streams, and MapR-Gateways features. Each feature may contain both administrator and developer topics.
- MapR-DB
  - Architecture of MapR-DB
    MapR-DB's architecture gives it a large of advantages over other NoSQL databases.
  - Performance Enhancements for SSD Based MapR-DB Deployments
  - MapR-DB as a Document Database
    MapR-DB supports OJAI documents as a native data store. OJAI documents are stored in a compact binary format, not as plain ASCII text.
  - MapR-DB as a Wide-Column Database
    - Logical Model of MapR-DB Binary Tables
    - Filesystem Operations on MapR-DB Tables
    - Migrating Between Apache HBase Tables and MapR-DB Binary Tables
    - Designing Row Keys for MapR-DB Binary Tables
      A row key identifies a row in a MapR-DB binary table.
    - Designing Column Families for MapR-DB Binary Tables
      Scanning an entire table for matches can be very performance-intensive. Column families enable you to group related sets of data and restrict queries to a defined subset, leading to better performance. When you design a column family, think about what kinds of queries are going to be used the most often, and group your columns accordingly.
    - Configuring Maximum Row Sizes for Binary Tables
      The default maximum row size at installation is 32MB. You can configure this maximum by changing the value of the mfs.db.max.rowsize.kb parameter with the maprcli config save command.
    - Enabling Access to MapR Tables via HBase APIs, hbase shell, and MapReduce Jobs
    - Creating MapR-DB Binary Tables
    - Displaying Table Region Information for MapR-DB Tables
    - Creating Applications That Access MapR-DB Binary Tables
    - Bulk Loading and MapR-DB Binary Tables
    - Replicating MapR-DB Binary Tables
    - Indexing MapR-DB Binary Tables with Elasticsearch
    - Impersonation via the HBase REST Gateway
- MapR Streams
  MapR Streams brings integrated publish/subscribe messaging to the MapR Converged Data Platform.
- MapR Gateways
  A MapR gateway mediates one-way communication between a source MapR cluster and a destination cluster. MapR-DB binary tables and MapR Streams streams can be replicated.

Decommissioning a MapR Node

Prerequisites

After verifying a successful migration, you can decommission the source nodes where the tables were originally stored.

Before you start, drain the node of data by moving the node to the /decommissioned physical topology. All the data on a node in the /decommissioned topology is migrated to volumes and nodes in the /data topology.

Run the following command to check if a given volume is present on the node:

maprcli dump volumenodes -volumename <volume> -json | grep <ip:port>

Run this command for each non-local volume in your cluster to verify that the node being decommissioned is not storing any volume data.

About this task

To decommission a MapR node:

Procedure

Change to the root user (or use sudo for the following commands).
Stop the Warden: service mapr-warden stop
If ZooKeeper is installed on the node, stop it: service mapr-zookeeper stop
Determine which MapR packages are installed on the node:
- dpkg --list | grep mapr (Ubuntu)
- rpm -qa | grep mapr (Red Hat or CentOS)
Remove the packages by issuing the appropriate command for the operating system, followed by the list of services. Examples:
- apt-get purge mapr-core mapr-cldb mapr-fileserver (Ubuntu)
- yum erase mapr-core mapr-cldb mapr-fileserver (Red Hat or CentOS)
Remove the /opt/mapr directory to remove any instances of hostid, hostname, zkdata, and zookeeper left behind by the package manager.
Remove any MapR cores in the /opt/cores directory.
If the node you have decommissioned is a CLDB node or a ZooKeeper node, then run configure.sh on all other nodes in the cluster (see Configuring the Node).