Replication: Make Target Writable

REQUIREMENTS

Admin privileges on the Qumulo cluster
Cluster running Qumulo Core 2.11.1 and above (for QQ CLI)
Cluster running Qumulo Core 2.11.2 and above (for Web UI)

PROCESS

If a replication process is interrupted or rendered unable to complete, it can leave the target directory in an inconsistent state that could be missing data. With Qumulo Core 2.11.1 and later, the system can roll back to a snapshot that is automatically stored after a successful replication job. In the case of an interrupted replication, this snapshot can be used to make your target directory writable and point-in-time consistent.

TIP! This feature is often used in conjunction with the Failover/Failback process. Check out the Replication: Failover and Failback with 2.12.0 and above article for additional details.

Make Target Writable via the Web UI (2.11.2 and above)

Log into the Web UI on the secondary cluster and navigate to the Replication page.
Click the button on the desired replication relationship listing.
Select Make Target Writable....
In the resulting confirmation dialog box, click Yes, Make Target Writable.
Wait for the directory to be reverted to the last recovery point. Progress can be monitored by clicking Details.
Click the button and select Delete relationship once the relationship status displays Disconnected and target writable.

Make Target Writable via the QQ CLI (2.11.1 and above)

Using the unique identifier of the target replication relationship, run the following command to initiate the process on the target cluster:

qq replication_make_target_writable --id <id>

This process may take some time to complete and the replication relationship will be in the DISCONNECTING state while it progresses. After the job completes, the target directory will no longer be read-only and the relationship will enter the DISCONNECTED state.

To reconnect the original replication relationship, use the following qq command:

qq replication_reconnect_target_relationship --id <id>

IMPORTANT: If you have implemented a replication failover/failback workflow, this command should not be used until the data has re-replicated back to the primary cluster.

RESOLUTION

You should now be able to successfully make your target directory writable to roll your data back to a previous snapshot when a started replication job fails to complete