Child pages
  • Resolving Duplicate Domain Names in a Mirrored or DR Cluster
Skip to end of metadata
Go to start of metadata


When creating domains, you must ensure that all domain names and all bucket names within a particular domain are unique amongst all clusters you manage. This is particularly important if you are replicating from one cluster to another. Using Content Router or Netmail Store Feeds, you can create two types of DR cluster configurations:

  • DR Cluster. Copies one or more clusters and their contents in another physical location.
  • Mirrored Configuration. Copies the contents of cluster 1 to 2 and the contents of cluster 2 to 1.

In either type of configuration, if two clusters contain two unique domains/buckets with the same external name, Content Router/Feeds replication will create a duplicate domain/ bucket name(s) in the DR or mirrored cluster. This results in indeterminate access to objects in the duplicated domains/buckets. Sometimes a request to a particular object in one of the duplicate domains/buckets succeeds, but other times it fails.

When Netmail Store detects a duplicate, it logs a Critical error to its Admin Console similar to the following:

SCSP CRITICAL: Domain 'collisiondomain.e0f55af9abcacd625cfd946a1a5e49d0'
(uuid=15748c61aea50ec3bcdd28df763f6cfa) has collided with existing Domain
(uuid=6ba3aeda10f2254e5b418b73c684c838). Remove or rename one of the versions to
avoid conflict.

If you receive a Critical error, perform one of the following procedures:

  • Rename a duplicate domain from the Admin Console in the replication source cluster (recommended for a DR cluster conflict). This method resolves the issue and prevents it from happening in the future.

Note: This method does not work in a mirrored configuration because both clusters have duplicates. In this situation, use the next procedure.

  • Manually rename either conflicting domain or bucket in either cluster. This is the only method you can use in a mirrored cluster conflict. It resolves the issue and prevents it from reoccurring. For a DR cluster conflict, this method is not recommended because the next time the same domain or bucket is replicated to the DR cluster from its source, the duplicate domain name still exists.

Renaming a Domain in its Source Cluster (DR Cluster Conflict Only)

This section describes how to rename a domain in its source cluster where the name of the domain is assumed to be unique. After you rename the domain, it replicates without errors to the DR cluster.

For a conflict in a mirrored configuration, see Manually Renaming a Domain or Bucket in a Mirrored or DR Cluster.

To rename a domain in the source cluster of a DR cluster:

1. Open the Netmail Store Admin Console, and click Settings.

2. On the Cluster Settings page, click Edit next to the name of the domain you want to rename.

3. In the Add Cluster Tenant section, enter a new name in the Domain Name field.

4. Click Save.

5. If prompted, enter an administrator user name and password.

Manually Renaming a Domain or Bucket in a Mirrored or DR Cluster

To manually rename a domain or bucket in a mirrored or DR cluster, use the SCSP COPY command with the following query arguments and authenticate as a cluster administrator.

Query ArgumentMeaning
admin

Also called administrative override, this query argument lets you ignore Allow headers and bypass the Castor-Authorization header.
This query argument requires cluster administrator credentials. Note that administrative override does not impact lifepoint policy deletability for immutable objects.

newname=new-domain-name

The new name for the domain or bucket. See Guidelines for Managing Tenants.

aliasuuid=domain-UUID

The UUID of the domain or bucket to rename.
You can find the UUID in the critical log message printed when a duplicate is detected.

To rename a domain in a mirrored or DR cluster:

1. Record the alias UUID for the duplicate domain or bucket you want to rename from the related critical error message.

2. HEAD the alias UUID of the domain or bucket to see if it has protection settings that need to be modified.

Use SCSP INFO command as follows:

INFO /alias-uuid?admin Host: domain-name-or-ip

You must authenticate as a cluster administrator (that is, a user in the security.administrators parameter).
If present in the HEAD results, you must also get the value of the CastorAuthorization header and pass it in using the new cluster name with the rename command as shown in the next step.

3. Rename the domain or bucket.

curl -X COPY
  -H 'Castor-Authorization: renamed-value-from-HEAD'
  -H 'lifepoint: [] reps=16'
  -H 'Castor-Stream-Type: admin'
  --anyauth -u 'cluster-administrator-username:password'
  --location-trusted 'http://nodeip?domain=domain-name&admin&aliasuuid=uuid&

  newname=new-domain-or-bucketname'

4. If you are using an Indexer, you must drop and re-create your index in order for the new name to be updated in search and listing requests (See Reindexing Content).

For example, to rename the cluster.example.com domain to archive.example.com by sending commands to a node whose IP address is 172.16.0.35:

1. Record the alias UUID for cluster.example.com from the related critical error message (bbc2365b3283c23c47595abcfd09034a in this example).

2. HEAD the domain to get its protection settings, if any:

curl -i
  -anyauth -u 'admin:ourpwdofchoicehere'
  --location-trusted 'http://172.16.0.35/alias-uuid?admin'

Sample output:

HTTP/1.1 200 OK
  Cache-Control: no-cache-context
  Castor-Authorization: cluster.example.com/_administrators,
  POST=cluster.example.com
  Castor-Stream-Type: admin
  Castor-System-Alias: bbc2365b3283c23c47595abcfd09034a
  Castor-System-CID: ffffffffffffffffffffffffffffffff
  Castor-System-Cluster: cluster.example.com
  Castor-System-Created: Wed, 17 Nov 2010 15:59:13 GMT
  Castor-System-Name: cluster.example.com
  Castor-System-Owner: admin@CAStor administrator
  Castor-System-Version: 1290009553.775
  Content-Length: 0
  Last-Modified: Wed, 17 Nov 2010 15:59:13 GMT
  lifepoint: [] reps=16
  Etag: "099e2bc25eb8346ed5d94a598fa73bfa"
  Date: Wed, 17 Nov 2010 16:02:07 GMT
  Server: CAStor Cluster/5.0.0

3. If a Castor-Authorization header is present, you must update it to reflect the new name for the duplicate. If it is not present, you do not need to add it. The information you need is:

Castor-Authorization: cluster.example.com/_administrators,
POST=cluster.example.com

You must change this header to:

Castor-Authorization: archive.example.com/_administrators,
POST=archive.example.com

You must also add the following headers exactly as shown:

-H 'Castor-Stream-Type: admin'
-H 'lifepoint: [] reps=16'

Note: lifepoint: [] reps=16 enables the domain to be replicated as many times as possible. Use Castor-Stream-Type: admin for all objects that use a Castor-Authorization header.

4. Rename the domain.

curl -i -X COPY
  -H 'Castor-Authorization: archive.example.com/_administrators,
  POST=archive.example.com'
  -H 'Castor-Stream-Type: admin'
  -H 'lifepoint: [] reps=16'
  --anyauth -u 'admin:ourpwdofchoicehere'
  --location-trusted
  'http://172.16.0.35?domain=cluster.example.com&admi
  &aliasuuid=bbc2365b3283c23c47595abcfd09034
  &newname=archive.example.com'
  -D rename-domain.log

5. If using an Indexer, drop and recreate your index in order for the new name to be updated in search and listing requests. (See Reindexing Content.)

  • No labels