Federation Router Continuity vs DistCp Maintenance Window for Small-Cluster HDFS Migration

Recommended approach

For a small application that must preserve one namespace view and will not deploy a router tier, use DistCp with a short planned maintenance window rather than HDFS Router-based Federation. DistCp avoids the router’s extra network hop, HA requirements, and release-sensitive mount table, but it is not a continuous single-namespace solution. It is a cutover: clients must be pointed to the target cluster after the final sync, and writes occurring between the last DistCp pass and client cutover are lost unless writers are paused.

Confirmed facts vs likely explanation

Confirmed: DistCp can run while the source cluster is live, does not capture writes made after the bulk copy starts, and provides no atomic cutover. A final incremental pass plus writer quiesce is required to bound data loss.

Confirmed: Router-based Federation adds a network hop, and a router failure can block all mounted namespaces unless router HA is configured. Its support status and client compatibility matrix are release-specific, so the target Hadoop minor release must be checked before relying on it.

Likely: the final delta size is approximately the source write rate multiplied by the bulk-copy duration plus the final-pass duration. Write bursts can make this much larger than dataset size divided by average throughput, so measure it rather than estimate.

Sizing the final incremental pass and quiesce window

1. Run a baseline DistCp of the dataset while the source is live and record throughput.
2. Run a second pass after a known write burst to measure the final delta size and copy time.
3. Set the quiesce window to: measured final-pass time plus checksum and count validation, config distribution, application restart, and a buffer.
4. Pause all writers during the final sync and validation. Resume only after clients are cut over to the target.
5. Rehearse the cutover in a non-production environment before production.

Sequencing client configuration changes

1. Prepare target fs.defaultFS and classpath dependencies (Hadoop jars, site XML, keytabs if used) on all application nodes without activating them.
2. Validate with hadoop fs -ls and a small write against the target while the old cluster remains available.
3. Stop applications during the final DistCp pass and validation.
4. Switch fs.defaultFS to the target only after target checksum and count checks pass.
5. Restart applications with the new config and keep the old configuration available for immediate rollback.

Safe verification commands

hadoop distcp hdfs://source:8020/path hdfs://target:8020/path
hadoop fs -ls hdfs://target:8020/path
hadoop fs -Dfs.defaultFS=hdfs://target:8020 -test -d /

Missing diagnostic detail

What is the maximum acceptable cutover downtime? If it is shorter than the measured final-pass plus validation and restart time, the no-router DistCp window will not meet the requirement, and you should revisit router federation or dual-write after confirming release support.

Assumption: the application can tolerate a brief writer pause. Router federation status and client compatibility for the target release are unverified and require release-specific documentation review.