New Features and Changes in Cloudera Manager 6.1.0

The certmanager can now use the following option to automatically skip invalid certificates and import the rest of the bundle: --skip-invalid-ca-certs. Previously, if one or more of the certificates in a bundle were invalid, then the entire setup operation failed.

Auto-TLS now supports the following services: Flume, Java Keystore KMS, KeyTrustee server, KeyTrustee KMS, Thales HSM KMS, and Luna HSM KMS. When adding these services while Auto-TLS is enabled, TLS configuration will be added automatically.

You can now use BDR to replicate data from an insecure cluster that does not use Kerberos authentication, to a secure cluster that uses Kerberos. Note that the reverse is not true. BDR does not support replicating from a secure cluster to an insecure cluster.

To perform the replication, the destination cluster must be managed by Cloudera Manager 6.1.0 or higher. The source cluster must run Cloudera Manager 5.14.0 or higher in order to replicate to Cloudera Manager 6.

For more information, see Replicating from Insecure to Secure Clusters for Hive or Replicating from Insecure to Secure Clusters for HDFS.

BDR enhanced the Invalidate Metadata option so that the command is issued per Impala service after replication. This ensures that if a cluster has multiple Impala services, only the target Impala's metadata cache will be invalidated and require refresh, which can impact performance.

BDR now ignores Hive tables backed by Kudu during replication. The change does not affect functionality since BDR does not support replicating Kudu tables. This change was made to guard against data loss due to how the Hive Mestastore, Imapla, and Kudu interact.

Previously, Cloudera Manager retained logs for BDR Replication jobs indefinitely. Now, Cloudera Manager retains BDR logs for 90 days by default. You can now change the number of days Cloudera Manager retains logs for or disable log retention completely with the Backup and Disaster Log Retention property of the HDFS Service.

This feature compares two HDFS snapshots to reduce the number of files scanned during the copy-listing phase of replication to only those files that have known changes between runs. This can speed up replication performance dramatically when large number of files are unchanged between replications.

This feature relies on the immutable snapshot feature of HDFS. This feature existed in prior releases of CDH, it is now on by default in 6.1. You can also configure replication jobs to abort on snapshot diff failure when you create or edit a replication schedule. This can happen if files that are in the scope of replication have been added, changed or deleted on the destination cluster, which is generally unsupported by BDR. However, BDR will fall back to an exhaustive comparison of files, and you can use various options for conflict resolution in this case, such as "delete policy".

See the following pages for guidelines on using snapshot diff-based replication: Hive Guidelines and HDFS Guidelines.

When taking locks on a table, Hive creates a Zookeeper object for each such lock which contains the full query string. This query string is only used to display locks with SHOW LOCKS EXTENDED command. It has no impact on the actual locking process.

However, this often created huge memory pressure on the ZooKeeper instance. For example, for a query string of 1MB in size, if the locks are acquired on 10000 partitions of a table, then this requires 10GB of memory on ZooKeeper. To alleviate this pressure, the maximum query length stored in ZooKeper lock object has been limited to 10000 characters by default via hive.locks.query.string.max.length property. To reiterate, this does not affect any behavior except for how queries are displayed in the output of the SHOW LOCKS EXTENDED command. This configuration value can be increased to a maximum of 1 million, which is the data limit of a znode (1 MB).

A new configuration parameter, hive.metastore.connect.retries, has been added for HiveServer2 with an increased default value.

Cloudera Manager now supports configuring the Impala idle_query_timeout and idle_session_timeout parameters.

A new Impala Daemon configuration parameter, Java Heap Size of Impala Daemon in Bytes has been added to configure the JVM heap size. It defaults to 4 GB, and, like all memory parameters, may require tuning.

Impala Daemon's JVM Heap Usage plots are now available on the Impala Daemon's Status page on the Cloudera Manager Admin Console.

Cloudera Bug: OPSAPS-47832

Impala exposes additional metrics about the JVM and GC now. GC metric charts for the Impala Daemon's embedded JVM will now be seen on the Impala Daemon's role status page in the Cloudera Manager Admin Console.

The Impala predefined charts have been updated to include more meaningful metrics and remove rarely used plots.

Impala resource pools now contain minimum/maximum allowed memory limit (MEM_LIMIT) values for queries submitted to a particular pool. This change also adds validations for those attributes. For more information about these attributes, see IMPALA-7349.

The Kafka Broker parameter Data Retention Hours (data.retention.hours) was removed from the Cloudera Manager Admin Console. Use the Data Retention Time (data.retention.ms) parameter instead.

A new configuration property, num.network.threads has been added to the Kafka broker configuration parameters. The default value is based on the upstream version.

For CDH 6.1 and higher installations, default values for the following configuration parameters of the Kafka service have been changed based on production recommendations: - num.replica.fetchers=4 and num.network.threads=8

The graceful stop timeout of the Kafka service has been increased to 120 seconds, and a new configuration property, num.recovery.threads.per.data.dir has been added.

New metrics have been added that show the number of offline log directories and offline partitions in Kafka