Operational Changes (MapR 6.1.0)

Repository Changes

Recent changes to the download repository for core and ecosystem packages might affect your ability to install or upgrade software. For more inforrmation, see What's New in Version 6.1.0.

MapR Database

OJAI Support

MapR 6.1.0 introduces support for OJAI 3.0. For a list of classes and methods deprecated in OJAI 3.0, see https://docs.datafabric.hpe.com/apidocs/61/ojai/java/deprecated-list.html.

MapR 6.1.0 deprecates support for OJAI 1.0. The next release after 6.1.0 will no longer support OJAI 1.0.

Permissions on Arrays in MapR Database JSON

Starting from MapR 6.1.0, when you grant permissions on a field using array syntax (for example, person[]), you no longer have to grant separate permissions if the field also contains non-array values. However, this can result in errors if you attempt to define a new permission that conflicts with an existing one.

For example, suppose you have the following two documents in a JSON table:

{
    "_id" : "id001",
    "person" : [
        {"name" : {"last" : "Smith", "first" : "John"}},
        {"name" : {"last" : "Subramanium", "first" : "Ananya"}}
    ]
}
{
    "_id" : "id002",
    "person" : {"name" : {"last" : "Doe", "first" : "Jane"}}
}

In document id001, person is an array of nested documents and in id002, it is a single nested document.

The following table summarizes the behavior in 6.1 versus pre-6.1 when you grant permissions in the sequence shown:

Permission Grant Sequence	6.1 Behavior	Pre-6.1 Behavior	Key Differences
person[] person	Permission granted on person in documents id001 and id002 Error - conflicts with permission on person[] You do not need to grant this permission. The previous is sufficient.	Permission granted on person in document id001 Permission granted on person in document id002	In 6.1, having permission on person[] also gives you permission on person. Prior to 6.1, you need two separate permissions.
person person[]	Permission granted on person in document id002 Error - conflicts with permission on person You (or an administrator with appropriate permissions) must drop the permission on person before you grant permission on person[].	Permission granted on person in document id002 Permission granted on person in document id001	In 6.1, if an array permission conflicts with an existing permission, you must remove the conflicting permission.

The new 6.1 behavior applies to permissions granted in earlier versions after you upgrade your MapR cluster.

NOTE If you upgrade your cluster using rolling upgrades, whether you encounter pre-6.1 or 6.1 behavior depends on whether the MapR node enforcing the permission has been upgraded.

See Permissions on Arrays for more details about the new 6.1 behavior.

Data Types and Secondary Indexes

In MapR Database 6.1.0, you are no longer restricted to creating secondary indexes on scalar data fields. You can now create indexes on fields with arrays and nested documents. As a consequence, a 6.1 index may contain additional rows that are missing in an equivalent pre-6.1 index. If a query uses a covering index, MapR Database 6.1 returns these additional rows. See Data Types and Secondary Index Fields for more information about data type support.

Secondary Indexes and Upgrades

Starting with MapR Database 6.1, you can define secondary indexes using container field paths. Pre-existing indexes created in earlier releases do not support this new functionality, even after you upgrade your MapR cluster to 6.1. After you upgrade your cluster to 6.1, any new indexes you create support this functionality. You can use these indexes in your application if you are using a 6.1 (or later) client.

NOTE If your client is running on a MapR cluster node, after you upgrade the cluster node, the client becomes a 6.1 client and supports the new indexing functionality. Your pre-6.1 client can use an index created in a 6.1 cluster if the index does not use the new container field path functionality.

For more information about indexes on complex types, see Complex Types Support in MapR Database JSON.

MapR File System

Data-on-Wire Encryption

Beginning with MapR 6.1, data-on-wire encryption is enabled by default for newly created volumes for secure clusters. Data-on-wire encryption encrypts data in a volume during transmission over the wire. Data-on-wire encryption is not supported for non-secure clusters. You can disable data-on-wire encryption for individual volumes using MCS, the maprcli, or REST API commands. For more information, see the -wiresecurityenabled parameter of volume create and volume modify. See also Creating a Volume or Modifying a Volume.

Impersonation

Beginning with MapR 6.1:

• You cannot generate a ticket with impersonated UID and/or GID as the following:
  • UID 0 and/or GID 0 (user root)
  • UID mapr_uid and/or GID mapr_gid (user mapr)
• User mapr can impersonate anyone, including user root.

For more information, see Managing Impersonation and maprlogin.

MapR Tickets

Beginning with MapR 6.1, if the UID and GID in the ticket (without impersonation capability) is different from the UID and GID of the logged-in user, all operations are performed using the UID and GID of the ticket and not that of the logged-in user.

MapR Event Store For Apache Kafka (Streams)

Caution: Do Not Remove mapr-librdkafka In MapR 6.1 and later, the mapr-core package has a dependency on mapr-librdkafka. If the mapr-librdkafka package is installed, do not remove it manually. Doing so might result in the removal of MapR core packages, rendering the node unusable.

Using the Incremental Install function of the MapR Installer, you can safely deselect the Streams Tools and Streams Clients service options. The MapR Installer ensures that the mapr-librdkafka package is left intact when the services are removed. For manual operations, removing the mapr-librdkafka package is not recommended unless you also plan to remove the MapR software.

Partition Maximum As of MapR 6.1, the MapR Event Store For Apache Kafka API enforces a maximum of 4096 partitions for a topic. If you create an application with the MapR Event Store For Apache Kafka 6.1 API, the maximum number of partitions is 4096. If you previously created an application with MapR Event Store For Apache Kafka 6.0.1 API (or older) and you've upgraded, the original number of partitions can be used. For example, if you were using more than 4096 partitions in MapR 6.0.1 or earlier, you can continue to use the same number of partitions after upgrading.

MapR Installer

Off-Cluster Elasticsearch and OpenTSDB With MapR Installer 1.10, the installer no longer includes an option to support off-cluster Elasticsearch and OpenTSDB when security is turned on. For non-secure clusters, MapR continues to support the option for off-cluster Elasticsearch and OpenTSDB.

Deprecated Features

• None