While a replication runs, ensure that the source directory is not modified. A file added during replication does not get replicated. If you delete a file during replication, the replication fails.

Additionally, ensure that all files in the directory are closed. Replication fails if source files are open. If you cannot ensure that all source files are closed, you can configure the replication to continue despite errors. Uncheck the Abort on Error option for the HDFS replication. For more information, see Configuring Replication of HDFS Data

After the replication completes, you can view the log for the replication to identify opened files. Ensure these files are closed before the next replication occurs.

High latency among clusters can cause replication jobs to run more slowly, but does not cause them to fail. For best performance, latency between the source cluster NameNode and the destination cluster NameNode should be less than 80 milliseconds. (You can test latency using the Linux ping command.) Cloudera has successfully tested replications with latency of up to 360 milliseconds. As latency increases, replication performance degrades.

1. Verify that your cluster conforms to one of the Supported Replication Scenarios.
2. If you are using different Kerberos principals for the source and destination clusters, add the destination principal as a proxy user on the source cluster. For example, if you are using the hdfssrc principal on the source cluster and the hdfsdest principal on the destination cluster, add the following properties to the HDFS service Cluster-wide Advanced Configuration Snippet (Safety Valve) for core-site.xml property on the source cluster:

   <property>
       <name>hadoop.proxyuser.hdfsdest.groups</name>
       <value>*</value>
   </property>
   <property>
       <name>hadoop.proxyuser.hdfsdest.hosts</name>
       <value>*</value>
   </property>

   Deploy the client configuration and restart all services on the source cluster.

3. If the source cluster is managed by a different Cloudera Manager server than the destination cluster, configure a peer relationship. If the source or destination is Amazon S3, you must configure AWS credentials.
4. Do one of the following:
   1. Select Backup > Replication Schedules
   2. Click Create Schedule > HDFS Replication.

   or

   1. Select Clusters > HDFS Service Name.
   2. Select Quick Links > Replication.
   3. Click Create Schedule > HDFS Replication.

   The Create HDFS Replication dialog box displays, and opens displaying the General tab. Click the Peer or AWS Credentials link if your replication job requires them and you need to create these entities.

5. Select the General tab to configure the following:
   1. Click the Name field and add a unique name for the replication schedule.
   2. Click the Source field and select the source HDFS service. You can select HDFS services managed by a peer Cloudera Manager Server, local HDFS services (managed by the Cloudera Manager Server for the Admin Console you are logged into), or you can select AWS Credentials.
   3. Enter the Source Path to the directory (or file) you want to replicate. For replication to Amazon S3, enter the path using the following form:

      s3a://bucket name/path

   4. Click the Destination field and select the destination HDFS service from the HDFS services managed by the Cloudera Manager Server for the Admin Console you are logged into, or select AWS Credentials.
   5. Enter the Destination Path where the source files should be saved. For replication to Amazon S3, enter the path using the following form:

      s3a://bucket name/path

   6. Select a Schedule:
      • Immediate - Run the schedule Immediately.
      • Once - Run the schedule one time in the future. Set the date and time.
      • Recurring - Run the schedule periodically in the future. Set the date, time, and interval between runs.
   7. Enter the user to run the replication job in the Run As Username field. By default this is hdfs. If you want to run the job as a different user, enter the user name here. If you are using Kerberos, you must provide a user name here, and it must be one with an ID greater than 1000. (You can also configure the minimum user ID number with the min.user.id property in the YARN or MapReduce service.) Verify that the user running the job has a home directory, /user/username, owned by username:supergroup in HDFS. This user must have permissions to read from the source directory and write to the destination directory.
      Note the following:

      • The User must not be present in the list of banned users specified with the Banned System Users property in the YARN configuration (Go to the YARN service, select Configuration tab and search for the property). For security purposes, the hdfs user is banned by default from running YARN containers.
      • The requirement for a user ID that is greater than 1000 can be overridden by adding the user to the "white list" of users that is specified with the Allowed System Users property. (Go to the YARN service, select Configuration tab and search for the property.)
6. Select the Resources tab to configure the following:
   • Scheduler Pool – (Optional) Enter the name of a resource pool in the field. The value you enter is used by the MapReduce Service you specified when Cloudera Manager executes the MapReduce job for the replication. The job specifies the value using one of these properties:
     • MapReduce – Fair scheduler: mapred.fairscheduler.pool
     • MapReduce – Capacity scheduler: queue.name
     • YARN – mapreduce.job.queuename
   • Maximum Map Slots - Limits for the number of map slots per mapper. The default value is 20.
   • Maximum Bandwidth - Limits for the bandwidth per mapper. The default is 100 MB.
   • Replication Strategy - Whether file replication tasks should be distributed among the mappers statically or dynamically. (The default is Dynamic.) Static replication distributes file replication tasks among the mappers up front to achieve a uniform distribution based on the file sizes. Dynamic replication distributes file replication tasks in small sets to the mappers, and as each mapper completes its tasks, it dynamically acquires and processes the next unallocated set of tasks.
7. Select the Advanced Options tab, to configure the following:
   • Add Exclusion click the link to exclude one or more paths from the replication.
     The Regular Expression-Based Path Exclusion field displays, where you can enter a regular expression-based path. When you add an exclusion, include the snapshotted relative path for the regex. For example, to exclude the /user/bdr directory, use the following regular expression, which includes the snapshots for the bdr directory:

     .*/user/\.snapshot/.+/bdr.*

     You can add more than one regular expression to exclude.

   • MapReduce Service - The MapReduce or YARN service to use.
   • Log path - An alternate path for the logs.
   • Description - A description of the replication schedule.
   • Error Handling You can select the following:
     • Skip Checksum Checks - Whether to skip checksum checks on the copied files. If checked, checksums are not validated. Checksums are checked by default.
         Important:

       You must skip checksum checks to prevent replication failure due to non-matching checksums in the following cases:

       • Replications from an encrypted zone on the source cluster to an encrypted zone on a destination cluster.
       • Replications from an encryption zone on the source cluster to an unencrypted zone on the destination cluster.
       • Replications from an unencrypted zone on the source cluster to an encrypted zone on the destination cluster.

       Checksums are used for two purposes:

       • To skip replication of files that have already been copied. If Skip Checksum Checks is selected, the replication job skips copying a file if the file lengths and modification times are identical between the source and destination clusters. Otherwise, the job copies the file from the source to the destination.
       • To redundantly verify the integrity of data. However, checksums are not required to guarantee accurate transfers between clusters. HDFS data transfers are protected by checksums during transfer and storage hardware also uses checksums to ensure that data is accurately stored. These two mechanisms work together to validate the integrity of the copied data.
     • Skip Listing Checksum Checks - Whether to skip checksum check when comparing two files to determine whether they are same or not. If skipped, the file size and last modified time are used to determine if files are the same or not. Skipping the check improves performance during the mapper phase. Note that if you select the Skip Checksum Checks option, this check is also skipped.
     • Abort on Error - Whether to abort the job on an error. If selected, files copied up to that point remain on the destination, but no additional files are copied. Abort on Error is off by default.
     • Preserve - Whether to preserve the block size, replication count, permissions (including ACLs), and extended attributes (XAttrs) as they exist on the source file system, or to use the settings as configured on the destination file system. By default source system settings are preserved. When Permission is checked, and both the source and destination clusters support ACLs, replication preserves ACLs. Otherwise, ACLs are not replicated. When Extended attributes is checked, and both the source and destination clusters support extended attributes, replication preserves them. (This option only displays when both source and destination clusters support extended attributes.)

       If you select one or more of the Preserve options and you are replicating to Amazon S3, the values all of these items are saved in meta data files on S3. When you replicate from Amazon S3 to HDFS, you can select which of these options you want to preserve.

         Note: To preserve permissions to HDFS, you must be running as a superuser on the destination cluster. Use the "Run As Username" option to ensure that is the case.

     See Replication of Encrypted Data and HDFS Transparent Encryption.

   • Delete Policy - Whether files that were deleted on the source should also be deleted from the destination directory. This policy also determines the handling of files in the destination location that are unrelated to the source. Options include:
     • Keep Deleted Files - Retains the destination files even when they no longer exist at the source. (This is the default.).
     • Delete to Trash - If the HDFS trash is enabled, files are moved to the trash folder. (Not supported when replicating to Amazon S3.)
     • Delete Permanently - Uses the least amount of space; use with caution.
   • Alerts - Whether to generate alerts for various state changes in the replication workflow. You can alert on failure, on start, on success, or when the replication workflow is aborted.
8. Click Save Schedule.

   The replication task now appears as a row in the Replications Schedule table. (It can take up to 15 seconds for the task to appear.)

   If you selected Immediate in the Schedule field, the replication job begins running when you click Save Schedule.

To specify additional replication tasks, select Create > HDFS Replication.

  Note: If your replication job takes a long time to complete, and files change before the replication finishes, the replication may fail. Consider making the directories snapshottable, so that the replication job creates snapshots of the directories before copying the files and then copies files from these snapshottable directories when executing the replication. See Using Snapshots with Replication.

If your cluster has clients installed on hosts with limited resources, HDFS replication may use these hosts to run commands for the replication, which can cause performance degradation. You can limit HDFS replication to run only on selected DataNodes by specifying a "whitelist" of DataNode hosts.

You can limit which hosts can run replication processes by specifying a whitelist of hosts. For example, you may not want a host with the Gateway role to run a replication job since the process is resource intensive.

The Replications Schedules page displays a row of information about each scheduled replication job. Each row also displays recent messages regarding the last time the Replication job ran.

Figure 1. Replication Schedules Table

Only one job corresponding to a replication schedule can occur at a time; if another job associated with that same replication schedule starts before the previous one has finished, the second one is canceled.

You can limit the replication jobs that are displayed by selecting filters on the left. If you do not see an expected schedule, adjust or clear the filters. Use the search box to search the list of schedules for path, database, or table names.

• While a job is in progress, the Last Run column displays a spinner and progress bar, and each stage of the replication task is indicated in the message beneath the job's row. Click the Command Details link to view details about the execution of the command.
• If the job is successful, the number of files copied is indicated. If there have been no changes to a file at the source since the previous job, then that file is not copied. As a result, after the initial job, only a subset of the files may actually be copied, and this is indicated in the success message.
• If the job fails, the icon displays.
• To view more information about a completed job, select Actions > Show History. See Viewing Replication History.

You can view historical details about replication jobs on the Replication History page.

To view the history of a replication job:

1. Select Backup > Replication Schedules to go to the Replication Schedules page.
2. Locate the row for the job.
3. Click Actions > Show History.

Figure 2. Replication History Screen (HDFS)

Figure 3. Replication History Screen (Hive, Failed Replication)

You can use Cloudera Manager to replicate HDFS data to and from Amazon S3, however you cannot replicate data from one Amazon S3 instance to another using Cloudera Manager. You must have the appropriate credentials to access the Amazon S3 account and you must create buckets in Amazon S3 to store the replicated files.

When you replicate data to cloud storage with BDR, BDR also backs up file metadata, including extended attributes and ACLs.