Known Issues

This section lists known issues that you might run into while using the Replication Manager service.

DOCS-13504
When you create an HBase replication policy between a source cluster using Cloudera Manager version is 7.6.0-patch5366 or higher and a target cluster using Cloudera Manager version is 7.6.0 or lower, the first-time setup is not initiated and the following misleading message appears during policy creation:

Skipping Replication Setup because it has already been done.

To resolve this issue, upgrade the target cluster to Cloudera Manager version to 7.6.0-patch5366 or higher.
DMX-489
With default replication configurations, small files consuming more time to complete the replication process
You can increase the number of mappers to improve the replication performance.
DMX-518
Hive replication policy fails when a table is dropped in the source database (export tables) when the replication job is running.
DMX-519
If snapshots on the /user/hive/warehouse directory is not enabled, Hive replication policy fails when inserts are done on a source table during replication job run.
DMX-521
While running Hive replication policy, if you drop a table, it is not dropped on the target cluster. The data still remains and 'show tables' displays the dropped table after successful replication instances.
DMX-1455
An HBase replication policy from Cloudera Operational Database COD to COD cluster fails if you select the Perform Initial Snapshot option in the Create Replication Policy wizard, and the source and destination COD clusters use different AWS accounts.
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-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.
DMX-2923
When you create an HBase replication policy with the Perform Initial Snapshot option in a bi-directional replication setup from the disaster recovery cluster to the production cluster, the original table gets dropped and it is recreated with the content in the disaster recovery cluster. Therefore, the original content of the table is lost.
When you create the HBase replication policy in a bi-directional replication setup from the disaster recovery cluster to the production cluster, do not select the Perform Initial Snapshot option.
OPSAPS-65573
HBase replication policy creation and the Retry Failed Snapshots option can be run concurrently which is incorrect.
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.
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.

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-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.