Known Issues

You may encounter the following known issues after upgrading to Version 5.1.0.

Installation and Configuration Issues

CentOS Version 6.3 and Earlier
MapR installations on Version 6.3 and earlier can fail because of an unresolved dependency on the redhat-lsb-core package. This problem occurs when the CentOS repository points to vault.centos.org, rather than mirror.centos.org. If you encounter this problem, use one of the following workarounds:
  • Add this repository: http://mirror.centos.org/centos/6/os/x86_64/
  • Manually download and install the RPM: 
    wget http://mirror.centos.org/centos/6/os/x86_64/Packages/redhat-lsb-core-4.0-7.el6.centos.x86_64.rpm 
yum localinstall redhat-lsb-core-4.0-7.el6.centos.x86_64.rpm
16216
When you run configure.sh with the -HS option on client nodes, the mapred-site.xml is re-generated and does not retain existing user settings. To work around this problem, use the -R option in the command.
16155
In order to reconfigure a Mac client from secure mode to non-secure mode (or vice versa), you must follow these steps:
  1. Manually remove the entry for the current cluster from: 
    /opt/mapr/conf/mapr-clusters.conf
  2. Run configure.sh.
16386

If you enable centralized logging on a cluster that was using YARN log aggregation in Version 4.0.1 prior to upgrading to version 4.1.0, you can no longer access previously aggregated MapReduce logs from the HistoryServer UI.

Workaround: Perform the following steps to view previously aggregated MapReduce logs from the History Server UI:

  1. Use the yarn logs command to retrieve the logs for each MapReduce application. The output of this command contains stdout, stderr, syslog with specific delimiters.
  2. Parse the output of yarn logs command to create syslog, stdout, stderr files using UNIX tools such as sed or awk.
  3. Add the syslog, stdout, stderr files to the centralized logging directory with the following directory hierarchy:
    /var/mapr/local/<NodeManager node>/logs/yarn/userlogs/application_<applicationID>/container_<containerID>/

You will need to create the application and container directories and provide the user that submitted the application the proper permissions on the files and directories.

For example, if usera submitted the application, usera should have the following permissions on the directories and log files:
  • Application directories: 
    drwxr-s--- 5 usera mapr 4096 2015-01-07 11:32 /var/mapr/local/qa-node101.qa.lab/logs/yarn/userlogs/application_<id>
  • Container directories: 
    drwxr-s--- - usera mapr 3 2015-01-07 11:32 /var/mapr/local/qa-node101.qa.lab/logs/yarn/userlogs/application_<id>/container_<id>
  • Log files: 
    -rw-r----- 2 usera mapr 290 2015-01-07 11:32 /var/mapr/local/qa-node101.qa.lab/logs/yarn/userlogs/application_<id>/container_<id>/stderr
NOTE: After you complete the workaround, you will also be able to run maprcli job linklogs on these logs.

Issue with Removing Replicas When Indexing MapR-DB Data in Elasticsearch

Only one user should manage indexing of any given source MapR-DB table. If indexing of the table in a given Elasticsearch type is no longer needed and any other user attempts to run the command maprcli table replica elasticsearch remove to stop replicating from the table to that Elasticsearch type, the command will fail with the message that permission is denied.

MapR Streams does not support producers and consumers running on Windows

Neither 32-bit and 64-bit Windows operating systems are supported for producers and consumers.

MapR Client

23624: The same MapR client can access both secure and nonsecure clusters; however, a MapR client that is configured to access a secure cluster can access a nonsecure cluster only if these conditions are met:
  • The secure cluster must be listed first in mapr-clusters.conf.
  • A user must obtain a ticket for the secure cluster even if the user wants to access only the nonsecure cluster.

MCS Replication Tab Visible for JSON Tables

22455: In the MCS, the Table Replication tab is visible for JSON tables; however, replication is not supported for these tables.

Metrics Database Issues

Note the following limitations with job metrics:
  • You cannot use the Metrics Database to record activity for applications that run in YARN (MRv2). The database only supports MRv1 jobs.
  • MRv1 metrics are not supported on any RedHat 7.x system.
  • When you use MRv1 metrics, be aware of the following issues:
    • When the hoststats service crashes, MRv1 metrics will not be up-to-date in the mysql database.
    • The hoststats service may occasionally consume a large amount of memory.
    Workarounds:
    1. When hoststats crashes or consumes an excess amount of memory, restart hoststats with the following command: 
      maprcli node services -name hoststats -action restart -filter '[csvc==hoststats]'
    2. If restarting hoststats does not resolve your issue, complete the following steps to delete the metrics and restart hoststats.
      1. Run the following command to delete the MRv1 metrics:
         hadoop fs -rm /var/mapr/cluster/mapred/jobTracker/system/jobs/history/metrics
      2. Run the following command to restart Hoststats: 
        maprcli node services -name hoststats -action restart -filter '[csvc==hoststats]'
    3. If step 1 and 2 do not resolve the hoststats issue, for example in the case of a memory leak, you may want complete the following steps to disable MRv1 metrics:
      1. On the nodes that have the metrics package installed, comment out the following parameters in the /opt/mapr/hadoop/hadoop-0.2.0/conf/hadoop-metrics.properties file:
        • maprmepredvariant.class
        • maprmepredvariant.period
        • maprmapred.class
        • maprmapred.period
        For example: 
        #maprmepredvariant.class=com.mapr.job.mngmnt.hadoop.metrics.MaprRPCContext
#maprmepredvariant.period=60
#maprmapred.class=com.mapr.job.mngmnt.hadoop.metrics.MaprRPCContextFinal
#maprmapred.period=60
      2. Run the following command to restart hoststats on all nodes where it is running: 
        maprcli node services -name hoststats -action restart -filter '[csvc==hoststats]'

Resource Manager Issues

14696/15100
When automatic or manual ResourceManager failover is enabled and a job is submitted with impersonation turned ON by a user without impersonation privileges, the job submission eventually times out instead of returning an appropriate error. This behavior does not affect standard ecosystem services such as HiveServer because they are configured to run as the mapr user (with impersonation allowed). However, this problem does affect non-ecosystem applications or services that attempt to submit jobs with impersonation turned ON. MapR recommends that customers add the user in question to the impersonation list so that the job can proceed.
14907
When several jobs are submitted and the ResourceManager is using the ZKRMStateStore for failover, the cluster may experience ZooKeeper timeouts and instability. MapR recommends that customers always use the FileSystemRMStateStore to support ResourceManager HA. See Recovery for the ResourceManager.

Services Do Not Start After CentOS 7.0 Reboot

This problem is specific to the CentOS 7.0 operating system. When a CentOS 7.0 node is rebooted, Warden starts but fails to bring up other cluster services. To work around this problem, manually add the fully qualified domain name to the /etc/hosts file before rebooting the system.

SuSe 11 Does Not Support Secure Clusters

Secure MapR clusters are not supported on SuSe 11 platforms because of an incompatibility with the glibc version that is installed. This problem does not affect other operating systems that MapR supports, which have the required glibc version.