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
. - 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.
- 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.
- 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.
- OPSAPS-62995
- The HBase replication policy first time setup fails when the destination cluster is a Data Hub.
- OPSAPS-63071
- HBase replication policies from on-premises (CDH5 and CDH6) clusters fail when the source cluster Cloudera Manager version is 7.6.0.
- 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 Replication Policies page), select to get the policy deleted. option on the
- OPSAPS-66305
- If the snapshot export/import fails during HBase replication policy creation, and then you choose 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. option for the replication policy on the
- 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.
- OPSAPS-70074
- When you choose the Check Hive Metadata step is skipped during the replication policy run. option during the Hive replication policy creation process to replicate data from CDP Private Cloud Base cluster to CDP Public Cloud, the
- OPSAPS-62230
- HBase replication no longer fails if the content of the /tmp folder gets deleted while Cloudera Manager is running.
- OPSAPS-70297
- You can specify a custom username in the field during the HBase replication policy creation process. The option appears after you choose the option. Replication Manager uses the specified username on the source cluster to export the initial snapshot to the target.