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.
- DMX-489
- With default replication configurations, small files consuming more time to complete the replication process
- 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.
- 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.
- 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.
- 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.
