How to recover from a duplicate domain being replicated

Following is how to recover from a duplicate domain being replicated with feeds after subsequent buckets, with objects, have been written to the domain:

INFO THE "VISIBLE" DOMAIN.
```
curl -I --location-trusted --anyauth -u "admin:<password>" "http://<node or cluster>/?domain=<original domain name>&admin"
```
The important headers from the reply are:
- Castor-System-Alias
- Castor-Authorization
- Castor-System-Cluster
RENAME THE VISIBLE DOMAIN TO SOMETHING UNIQUE.
The rename command needs to be sent to the cluster where the domain was originally created, the originating cluster. That domain is the value of the Castor-System-Cluster header.
- If the reply to the above step included the Castor-Authorization header, it must be translated and used in this step.
- If the header was: Castor-Authorization: cluster.example.com/_administrators, POST=cluster.example.com
  and your new domain is posts.example.com, the new value will be: Castor-Authorization: posts.example.com/_administrators, POST=posts.example.com
- If the reply in the above step did not include a Castor-Authorization header, do not include one.
- Here is a full rename copy example, formatted for readability:
```
curl -X COPY 
	-H 'Castor-Authorization: posts.example.com/_administrators, POST=posts.example.com' 
	-H 'lifepoint: [] reps=16' 
	-H 'Castor-Stream-Type: admin' 
	-H 'Content-Type: application/castorcontext' 
	--anyauth -u 'admin:<admin password>' 
	--location-trusted 'http://<node from originating cluster>?domain=<original domain name>&admin&aliasuuid=<Value of Castor-System-Alias>&newname=<new unique domain name>'
```
  The new unique domain name will now appear with the originating cluster as the Castor-System-Cluster along with the original Castor-System-Alias.
WAIT 10 MINUTES AND DO A ROLLING REBOOT OF NODES IN THE ORIGINATING CLUSTER.
ONCE ALL NODES ARE REBOOTED, INFO BOTH THE ORIGINAL AND NEW DOMAIN NAME ON EACH OF THE NODES IN THE ORIGINATING CLUSTER.
```
curl -I "http://<node>/?domain=<original domain name>"
curl -I "http://<node>/?domain=<new unique domain name>"
```
Inspect the Castor-System-Cluster and Castor-System-Alias of each reply. If any of the nodes do not return the new domain or return the old domain name with the old values, reboot that node again.
CHECK THAT BUCKETS ORIGINALLY WRITTEN TO THE OLD DOMAIN ARE NOW VISIBLE IN THE ORIGINATING CLUSTER.
Any buckets written to the old domain name after duplication will now be under the new unique domain name. Test this with an INFO to each node in the cluster. Test a selection of objects from both buckets also, as they should not be visible.
```
curl -I "http://<node>/<originally written bucket>?domain=<original domain name>"
curl -I "http://<node>/<bucket written after duplication>?domain=<new unique domain name>"
```
ADD NEW DOMAIN TO REPLICATION FEED ON ORIGINATING CLUSTER
1. If the replication feed was configured without specifying domains in "Feeds domain list", skip to step 7.
2. From the originating cluster, add the new domain to the replication feed's "Feeds domain list".
RESTART THE REPLICATION FEED FROM THE ORIGINATING CLUSTER.
WHEN THE FEED RESTART ON THE ORIGINATING CLUSTER IS COMPLETE, PERFORM A ROLLING REBOOT OF ALL NODES IN THE OTHER CLUSTER.
WHEN ALL NODES HAVE COMPLETED REBOOTING, INFO BOTH DOMAINS FROM ALL NODES IN THE OTHER CLUSTER.
```
curl -I "http://<node>/?domain=<original domain name>"
curl -I "http://<node>/?domain=<new unique domain name>"
```
Inspect the Castor-System-Cluster and Castor-System-Alias of each reply.
If any of the nodes do not return the new domain or return the old domain name with the old values, reboot that node again.
BUCKETS ORIGINALLY WRITTEN TO THE OLD DOMAIN SHOULD NOW BE VISIBLE IN THE OTHER CLUSTER.
Any buckets written to the old domain name after duplication will now be under the new unique domain name. Test this with an INFO to each node in the cluster. Test a selection of objects from both buckets also as they should not be visible.
```
curl -I "http://<node>/<originally written bucket>?domain=<original domain name>"
curl -I "http://<node>/<bucket written after duplication>?domain=<new unique domain name>"
```
ADD NEW DOMAIN TO THE OTHER CLUSTER
1. If the replication feed was configured without specifying domains in "Feeds domain list" skip to step 12.
2. From the other cluster, add the new domain to the replication feed's "Feeds domain list".
RESTART THE REPLICATION FEED FROM THE OTHER CLUSTER.

WHEN THE FEED RESTART HAS COMPLETED RETEST A SELECTION OF INFOS TO BOTH CLUSTERS.

curl -I "http://<node>/<originally written bucket>/<expected object>?domain=<original domain name>"
curl -I "http://<node>/<bucket written after duplication>/<expected object>?domain=<new unique domain name>"

ONCE THE BUCKETS AND OBJECTS ARE VISIBLE, DELETE THE ELASTICSEARCH INDEX FOR BOTH CLUSTERS.
This is easily done by issuing a DELETE command to the Elasticsearch cluster and specifying the index to delete. The index name used for the delete is the name of the Swarm cluster writing to the Elasticsearch cluster.
If your Elasticsearch cluster is accessible as 'es.example.com' and the Swarm cluster name is 'cluster.example.com' then you would issue to curl command:
```
curl -X DELETE "es.example.com:9200/cluster.example.com"
```
You should get the reply: {"ok":true,"acknowledged":true}
Execute this command for each cluster. You only need to run this once for each Swarm cluster. It does not need to be executed on each Elasticsearch server.
RESTART THE INDEXING FEED ON BOTH CLUSTERS.
WHEN THE INDEXING FEED RESTART HAS COMPLETED, TEST THE INDEX FOR EXPECTED RESULTS.