Operational Changes (MapR 6.1.0)
Lists the functional changes made to existing commands in MapR version 6.1.0.
Note the following functional changes to existing commands in Version 6.1.
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 inid002
, 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 documentsid001
andid002
- Error - conflicts with permission on
person[]
You do not need to grant this permission. The previous is sufficient.
- Permission granted on
person
in documentid001
- Permission granted on
person
in documentid002
In 6.1, having permission on person[]
also gives you permission onperson
. Prior to 6.1, you need two separate permissions.person
person[]
- Permission granted on
person
in documentid002
- Error - conflicts with permission on
person
You (or an administrator with appropriate permissions) must drop the permission on
person
before you grant permission onperson[]
.
- Permission granted on
person
in documentid002
- Permission granted on
person
in documentid001
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 GID0
(user root) - UID
mapr_uid
and/or GIDmapr_gid
(user mapr)
- UID
- User mapr can impersonate anyone, including user root.
maprlogin
. - You cannot generate a ticket with impersonated UID and/or GID as the following:
- 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