Cloudera Docs

Fixed Issues

This section lists fixed issues in the Replication Manager service.

CDPSDX-2879: Ranger import fails when you create a Hive replication policy for a medium duty Data Lake cluster
When you create a Hive replication policy with the Include Sentry Permissions with Metadata or Skip URI Privileges option for a medium duty Data Lake cluster, Ranger import fails. Before you choose the Include Sentry Permissions with Metadata option for a Hive replication policy for a medium duty Data Lake cluster, contact Cloudera Support.
DMX-348: Export remote Hive Metastore step failed while using Replication Manager
While creating a replication policy with no Sentry permissions for the source database/tables, with latest Data Lake clusters, an error message appears The remote command failed with error message: Command (HDFS replication (433)) has failed.
Make sure that while using CDH cluster(s), you do not use MapReduce 1 service.
DMX-355: Currently, Replication Manager does not work efficiently with high-frequency policies
Recommend using policy frequency which is greater than 30 minutes.
DMX-364: Multiple instance of Replication Manager UI displays as "In Progress"
When the replication policy is scheduled with a specific interval, it is seen from the UI that all the instances are "In Progress" and one of the instances is failed.
Refresh the web browser and try again.
DMX-391: Schedule Run option displays only "Does not repeat" and "Custom" options
Recommend to use "Does not repeat" or "Run now" option to schedule the replication policy.
DMX-489
With default replication configurations, small files consume more time to complete the replication process. You can increase the number of mappers to improve the replication performance.
DMX-636: Inconsistency in the value of Timestamp Type column when source ORC is replicated, and source and target clusters are in different time zones
From an Auto TLS source cluster, when a ORC table with static data is replicated, the data in the Timestamp Type column does not match in the target cluster.
DMX-666: Replication fails when the exception "connection timed out" is not handled in Cloudera Manager
Ensure there is connectivity between Source Cloudera Manager and SDX CM. If the source hostname is not resolved to IP, add the host mapping of Cloudera Manager host to /etc/hosts entries of SDX CM.
OPSAPS-61288: Replication setup fails when a non-default namespace is not created on the destination cluster
Create a namespace on the destination cluster before you create an HBase replication policy.
OPSAPS-61596: HBase policy returns "different schema" when tables on source and destination clusters have the same column families
This issue appears because HBase replication policies handle tables that have table attributes incorrectly. Tables with table attributes in replicated tables might lead to other errors as well.
Remove the table attributes for the HBase tables.
OPSAPS-62836
When the first HBase replication policy is created between two clusters where the source cluster is an on-premises cluster, sometimes the policy's status shows Waiting for 'Continue Setup' action call for the first few seconds. No user action is required. The status automatically is updated to Configuring clusters after a few seconds.
OPSAPS-62910, OPSAPS-62948, OPSAPS-62956, and OPSAPS-62998
When you perform HBase replication policy creation, policy update, or policy delete operations on multiple policies between the same cluster pair at once, different failures appear. This is because the HBase peer does not get synchronized during these operations as expected.
Perform HBase replication policy creation, modification, or deletion action one at a time on each HBase replication policy of a cluster pair.
OPSAPS-62995
The HBase replication policy first time setup fails when the destination cluster is a Data Hub.
This issue appears when the HBase classpath is not configured automatically as expected.

To resolve this issue, perform the following steps in Cloudera Manager of the Data Hub before setting up an HBase replication policy:

  1. Navigate to the HBase service.

  2. Search for the following Advanced Configuration Snippet (Safety Valve) values, and add the key and value as shown below:
    • HBase Service Environment Advanced Configuration Snippet (Safety Valve)

      Key: HBASE_CLASSPATH

      Value: HBASE_CLASSPATH="$HBASE_CLASSPATH:/opt/cloudera/parcels/CDH/lib/hbase-cdp-jars/"

    • HBase Client Environment Advanced Configuration Snippet (Safety Valve)

      Key: HBASE_CLASSPATH

      Value: HBASE_CLASSPATH="$HBASE_CLASSPATH:/opt/cloudera/parcels/CDH/lib/hbase-cdp-jars/"

  3. Restart HBase service.

OPSAPS-63071
HBase replication policies from on-premises (CDH5 and CDH6) clusters fail when the source cluster Cloudera Manager version is 7.6.0.
To resolve this issue, perform the following steps in the source cluster Cloudera Manager before you create an HBase replication policy:

  1. Navigate to the HBase service.

  2. Search for the following Advanced Configuration Snippet (Safety Valve) values, and add the key-value pairs as shown below:

    • HBase Service Environment Advanced Configuration Snippet (Safety Valve)

      Key: HBASE_CLASSPATH

      Value: HBASE_CLASSPATH="$HBASE_CLASSPATH:[***location of HBase replication parcel jar file***]"

    • HBase Client Environment Advanced Configuration Snippet (Safety Valve)

      Key: HBASE_CLASSPATH

      Value: HBASE_CLASSPATH="$HBASE_CLASSPATH:[***location of HBase replication parcel jar file***]"

    For example, the location of the HBase replication parcel jar in your CDH source cluster might be /opt/cloudera/parcels/CLOUDERA_OPDB_REPLICATION-1.0-1.CLOUDERA_OPDB_REPLICATION5.14.4.p0.9261092/lib/

  3. Restart HBase service.

OPSAPS-63138
The HBase Replication First Time Setup command runs successfully in the destination cluster though the Admin Setup HBase replication subcommand fails on the source cluster.
OPSAPS-63905
Replication Manager runs the clone_snasphot command when restoring snapshots on SFT-enabled clusters without setting the SFT attributes on the table.
OPSAPS-64034
When you delete an HBase replication policy, the HBase peer used in the policy is also deleted if a replicated table name has the - character. Note that the HBase peer is deleted even when there are existing HBase replication policies using this peer. This issue also occurs if a replicated table in any of the policies that uses this peer has the - character in its name.
OPSAPS-64879
Replication policies with an empty name do not appear on the Replication Policies page.Provide a unique replication policy name during replication policy creation.
OPSAPS-65572
When you create an HBase replication policy between a cluster pair where HBase policies between them are suspended (which also means that the corresponding HBase peer is disabled), the HBase peer is enabled at the end of the policy creation process which results in an inconsistent suspend state for the suspended policies.
OPSAPS-65573
HBase replication policy creation and the Retry Failed Snapshots option can be run concurrently.
OPSAPS-66303
A NullPointerException appears when you delete an HBase replication policy for which the policy creation failed because a table in the policy did not exist on the source cluster. After the failed delete action (using the Actions > Delete option on the Replication Policies page), select Actions > Force Delete to get the policy deleted.
OPSAPS-66305
If the snapshot export/import fails during HBase replication policy creation, and then you choose the Actions > Retry Failed Snapshots option for the replication policy on the Replication Policies page, the HBase peer is not enabled even if there were no export/import failures during the retry action. In this scenario, the replication peer in the HBase service remains disabled and the Retry Failed Snapshots action fails.
Delete the replication policy and re-create it.
OPSAPS-66327
The HBase peer can be created in the disabled state in CDH 6.0 or higher clusters. However, HBase peer cannot be created in disabled state in CDH 5 clusters and the peer remains enabled throughout the replication setup process. As a workaround, you can create a ‘test’ HBase replication policy with a small table in CDH 5 clusters. This creates the HBase peer. This issue is fixed.
OPSAPS-66924
When the snapshot export fails during the HBase replication policy job run, the target HBase folder in the destination Data Hub or COD gets deleted if you are using Cloudera Manager versions that are lower than 7.6.7 CHF8, 7.11.0, or 7.9.0-h6 on the source cluster.

As a workaround, you can either revoke the delete permission for the user, or ensure that you use an access key/role that does not have delete permissions for the required storage component. For more information on how to create an access key in AWS or Azure service principal, see Target HBase folder is deleted when HBase replication policy fails.

OPSAPS-66988
You cannot create HBase replication policies if the target CDP version is 7.2.16, 7.2.16.1, 7.2.16.2, or 7.2.16.3 and the source Cloudera Manager version is 7.7.3 or lower, and the source Cloudera Manager API version is v50 or higher.
OPSAPS-67042
Currently, when you create an HBase replication policy for a table, a snapshot is created and then the replication scope is set to “1”. Because of the order of steps, the data that is generated between snapshot creation and setting the replication scope is not replicated.

As a workaround, you can set the replication scope of the tables on the source cluster that you want to replicate to “1" and then create the HBase replication policy.

To configure the replication scope for a table on the master cluster, run the “alter [***table_name***], {NAME => [***column-family***], REPLICATION_SCOPE => 1} command for each column family that must be replicated. REPLICATION_SCOPE is a column-family level attribute, where the value '0' means replication is disabled, and '1' means replication is enabled.