Data Stores
Separate data stores might exist on top of HDFS and Ozone or at the local file system level. These data stores might have their own replication or backup and restore mechanisms used in conjunction with traditional Hadoop replication strategies. Services might have additional availability capabilities and configurations to help establish intra-cluster high availability. This creates a robust and fault tolerant environment when paired with cross-cluster replication.
Data Lake
For the CDP Public Cloud form factor, it is possible to backup and restore the metadata maintained in the Data Lake services. The backup and restore operation creates a comprehensive backup that improves the likelihood of data in the backup to be synchronized across all the services running in the Data Lake.
There is a downtime when a Data Lake backup is performed, as some Data Lake services are stopped. Additionally, access to the HMS/Ranger databases are blocked for the duration of the backup.
HBase
HBase should be deployed in High Availability (HA) mode by configuring backup leader nodes. You must configure high availability when HBase applications require low-latency queries and can tolerate minimal (near-zero-second) staleness for read operations.
For information about enabling HBase with High Availability, see Enabling HBase HA using Cloudera Manager
HBase has a built-in replication mechanism for replicating writes between clusters. This is one of the few services that can work in an Active-Active configuration. HBase utilizes the Write Ahead Log (WAL) to track changes that need to be shipped to the peer cluster. Once the peer relationship is established, HBase automatically manages shipping WAL changes to minimize administrative overhead, but can require administrator intervention in certain conditions where the peer becomes unavailable. When planning, pay close attention to replication WAL backlogs when a cluster is offline. These WAL backlogs can fill HDFS, causing additional issues in environments with significant data churn.
Peer replication status is monitored through built-in HBase status commands. Integration into alerting systems requires additional customer integration.
When Phoenix is implemented in conjunction with HBase, use the native HBase replication mechanism to synchronize data across disaster recovery environments.
For information about enabling HBase replication, see Deploying HBase Replication
Kudu
Kudu maintains its own in-memory state and uses local disks to maintain persistent copies of data. Kudu has no built-in cluster-to-cluster replication. When planning disaster recovery for Kudu, consider two instances and a dual ingest pattern. It is possible to backup Kudu tables but these are one-off snapshots at a single point in time.
Review the Cloudera documentation for Kudu recovery Backing up and Recovering Apache Kudu
Cloudera Search (Solr)
Cloudera Search includes a backup and restore mechanism primarily designed to provide disaster recovery capability for Apache Solr. You can create a backup of a Solr collection by creating and exporting a snapshot and restoring from this backup to recover from scenarios, such as accidental or malicious data modification or deletion. When planning for disaster recovery for Cloudera Search, consider two instances and a dual ingest pattern. It is possible to backup Solr tables but these are one off snapshots at a single point in time.
Review the Cloudera documentation for Search recoveryBacking up and restoring data using Search
