Skip to main content
Hitachi Vantara Knowledge

Replication collisions

With an active/active link, clients can make configuration changes and changes to namespace content on both HCP systems involved in the link. This situation can result in configuration and content collisions.

With an active/passive link, if clients are allowed to make changes on both HCP systems involved in the link while the link is failed over to the replica, configuration and content collisions can occur on failback. Collisions can also occur on failback if changes made on the replica while a link is failed over conflict with configuration or content that was not yet replicated at the time of failover.

The way HCP handles collisions that occur due to replication depends on the type of collision. The general rule for namespace content is that more recent changes have priority over conflicting less recent changes. If conflicting changes occur at exactly the same time, HCP gives priority to the change that occurred on the system where the link was created.

When configuration changes result in a conflict, the Replication service pauses replication or recovery of the tenant, as applicable.

NoteIf the system time is not in sync on the two systems involved in a replication link, replication collision handling may have unexpected results.

Object content collisions

An object content collision occurs when:

  • For an HCP namespace without versioning enabled, these events occur in the order shown:
    1. An object is created with the same name in that namespace on both systems involved in a replication link, but the object has different content on the two systems.
    2. The object on one of the systems is replicated to the other system.

    If versioning is enabled for the namespace, no collision occurs. Instead, the less recently created of the two objects becomes an old version of the more recently created object. If the two objects were created at exactly the same time, the object that was created on the system where the link was created is treated as the newer version.

  • For a default-namespace folder, these events occur in the order shown:
    1. An object is created with the same name in that folder on both systems involved in a replication link, but the object has different content on the two systems.
    2. The object on one of the systems is replicated to the other system.

When an object content collision occurs, the more recently created object keeps its name and location. The other object is either moved to the .lost+found folder in the same namespace or renamed, depending on the namespace configuration. If the two objects were created at exactly the same time, the object that was created on the system where the link was created keeps its name and location.

When HCP moves an object to the .lost+found folder, the full object path becomes .lost+found/replication/link-id/old-object-path.

When renaming an object due to a content collision, HCP changes the object name to object-name.collision or object-name.version-id.collision, where version-id is the version ID of the object. HCP uses the second format only if versioning has ever been enabled for the namespace that contains the object but is not currently enabled.

If the new name is already in use, HCP changes the object name to object-name.1.collision or object-name.version-id.1.collision, as applicable. If that name is already in use, HCP successively increments the middle integer by one until a unique name is formed.

Objects that have been relocated or renamed due to content collisions are flagged as replication collisions in their system metadata. Clients can use the metadata query API to search for objects that are flagged as replication collisions.

If an object that has been flagged as a replication collision changes (for example, if its retention period is extended), its collision flag is removed. If a client creates a copy of a flagged object with a new name, the collision flag is not set on the copy.

Namespaces can be configured to have the DIsposition service automatically delete objects that are flagged as replication collisions. When selecting this option for a namespace, the tenant administrator specifies the number of days the DIsposition service should wait before deleting such an object. The days are counted from the time the collision flag is set. If the collision flag is removed from an object, the object is no longer eligible for deletion by the DIsposition service.

System metadata collisions

A system metadata collision occurs when these events occur in the order shown:

  1. Different changes are made to the system metadata for a given object on each of two systems in a replication topology.
  2. The changed system metadata on one of the systems is replicated to the other system.
For example, suppose a user on one system changes the shred setting for an object while a user on the other system changes the index setting for the same object. When the object on either system is replicated to the other system, a system metadata collision occurs.

If a collision occurs when changed system metadata for a given object is replicated from one system (system A) in a replication topology to another system (system B) in the topology:

  • For changed system metadata other than the retention setting and hold status:
    • If the last change made on system A is more recent than the last change made on system B, HCP changes the system metadata on system B to match the system metadata on system A.
    • If the last change on system B is more recent than the last change on system A, HCP does not change the system metadata on system B.
  • For a changed retention setting:
    • If the retention setting on system A specifies a longer retention period than does the retention setting on system B, HCP changes the retention setting on system B to match the retention setting on system A.
    • If the retention setting on system B specifies a longer retention period than does the retention setting on system A, HCP does not change the retention setting on system B.
  • For a changed hold status:
    • If the object is on hold on system A but not on system B, HCP places the object on hold on system B.
    • If the object is on hold on system B but not on system A, HCP leaves the object on hold on system B.
Here are some examples of how HCP handles collisions when changed system metadata for a given object is replicated from one system (system A) in a replication topology to another system (system B) in the topology.
Example 1

The object starts out on both system A and system B with these system metadata settings:

  • Shred: false
  • Index: false

The list below shows a sequence of events in which the system metadata for the object is changed and the changes are then replicated.

  1. On system A, a client changes the shred setting to true.
  2. On system B, a client changes the index setting to true.
  3. The changes on system A are replicated to system B. The resulting settings for the object on system B are:
    • Shred: false
    • Index: true
Example 2

The object starts out on both system A and system B with these system metadata settings:

  • Retention: Initial Unspecified
  • Shred: false
  • Index: false

The list below shows a sequence of events in which the system metadata for the object is changed and the changes are then replicated.

  1. On system A, a client changes the retention setting to Deletion Prohibited.
  2. On system B, a client changes the retention setting to Deletion Allowed.
  3. On system B, a client changes the index setting to true.
  4. On system A, a client changes the shred setting to true.
  5. The changes on system A are replicated to system B. The resulting settings for the object on system B are:
    • Retention: Deletion Prohibited
    • Shred: true
    • Index: false
Example 3

The object starts out on both system A and system B with these system metadata settings:

  • Retention: Initial Unspecified
  • Hold: true
  • Shred: false
  • Index: false

The list below shows a sequence of events in which the system metadata for the object is changed and the changes are then replicated.

  1. On system A, a client changes the retention setting to Deletion Allowed.
  2. On system B, a client changes the retention setting to Deletion Prohibited.
  3. On system B, a client changes the index setting to true.
  4. On system A, a client changes the shred setting to true.
  5. On system A, a client releases the object from hold.
  6. The changes on system A are replicated to system B. The resulting settings for the object on system B are:
    • Retention: Deletion Prohibited
    • Hold: true
    • Shred: true
    • Index: false
  7. The changes on system B are replicated to system A. The resulting settings for the object on system A are:
    • Retention: Deletion Prohibited
    • Hold: true
    • Shred: true
    • Index: false

Custom metadata collisions

A custom metadata collision occurs when these events occur in the order shown:

  1. One of these changes occurs:
    • An annotation is added with the same name to a given object on each of two systems in a replication topology, but the annotation has different content on the two systems.

      The addition of an annotation to a given object on only one of the systems does not result in a custom metadata collision if the object does not have an annotation with the same name on the other system. In this case, the new annotation is replicated without conflict.

    • Different changes are made to the content of a given annotation for a given object on each of the two systems in a replication link.
    • A change is made to the content of a given annotation for a given object on one system in a replication link, and the same annotation is deleted on another system in the link.
  2. The change made on one of the systems is replicated to the other system.

For a default-namespace directory, these events occur in the order shown:

  1. One of these changes occurs:
    • Custom metadata is added to a given object on both systems involved in a replication link, but the added custom metadata is different on the two systems.

      The addition of custom metadata to an object on only one of the systems involved in a replication link does not result in a custom metadata collision. Instead, the new custom metadata is replicated from that system to the other system involved in the link without conflict.

    • The custom metadata for a given object is replaced on both systems involved in a replication link, but the replacement custom metadata is different on the two systems.
    • The custom metadata for a given object is replaced on one of the systems involved in a replication link, and the same custom metadata is deleted on the other system involved in the link.
  2. The change made on one of the systems is replicated to the other system.

If a collision occurs when a custom metadata change for a given object is replicated from one system (system A) in a replication link to another system (system B) in the link:

  • If the last change on system A is more recent than the last change on system B, HCP applies the change from system A to the custom metadata on system B
  • If the last change on system B is more recent than the last change on system A, HCP does not change the custom metadata on system B

Here are some examples of how HCP handles collisions when custom metadata changes for a given object are replicated from one system (system A) in a replication link to another system (system B) in the link.

Example 1

In an HCP namespace, the object starts out with annotations named a1 and a2 on both system A and system B.

The following list shows a sequence of events in which the annotations for the object are changed and the changes are then replicated.

  1. On system B, a client changes the content of a1.
  2. On system A, a client makes a different change to the content of a1.
  3. On system A, a client adds annotation a3 to the object.
  4. On system B, a client adds annotation a3 with different content from the a3 added on system A.
  5. The changes on system A are replicated to system B. The resulting annotations for the object on system B are:
    • a1 with the changed content from system A
    • a2 (unchanged)
    • a3 with the content added on system B
  6. The changes on system B are replicated to system A. The resulting annotations for the object on system A are:
    • a1 with the changed content from system A
    • a2 (unchanged)
    • a3 with the content added on system B
Example 2

The object starts out with the annotations named a1, a2, and a3 on both system A and system B.

The following list shows a sequence of events in which the annotations for the object are changed and the changes are then replicated.

  1. On system B, a client changes the content of a1.
  2. On system A, a client deletes a1.
  3. On system A, a client changes the content of a2.
  4. On system B, a client changes the content of a2.
  5. On system A, a client deletes a3.
  6. On system B, a client changes the content of a3.
  7. The changes on system A are replicated to system B. The resulting annotations for the object on system B are:
    • a2 with the changed content from system B
    • a3 with the changed content from system B
  8. The changes on system B are replicated to system A, the resulting annotations for the object on system A are:
    • a2 with the changed content from system B
    • a3 with the changed content from system B
Example 3

In a default-namespace directory, the object starts out with same custom metadata on system A and system B.

The following list shows a sequence of events in which the custom metadata for the object is changed and the change is then replicated.

  1. On system B, a client replaces the custom metadata for the object with new custom metadata.
  2. On system A, a client replaces the custom metadata for the object with different custom metadata from the custom metadata used on system B.
  3. The change on system A is replicated to system B. The resulting custom metadata for the object on system B is the new custom metadata from system A.

Access control list collisions

An ACL collision occurs when these events occur in the order shown:

  1. Different changes are made to the ACL for a given object on each of two systems in a replication link.
  2. The changed ACL on one of the systems is replicated to the other system.

An ACL is treated as a single unit. If a collision occurs when a changed ACL for a given object is replicated from one system (system A) in a replication link to another system (system B) in the link:

  • If the last change to the ACL on system A is more recent than the last change to the ACL on system B, HCP changes the ACL on system B to match the changed ACL on system A
  • If the last change to the ACL on system B is more recent than the last change to the ACL on system A, HCP does not change the ACL on system B

For example, suppose the ACL for a given object starts out with these grants on both system A and system B:

  • All users: read
  • User lgreen: write
  • User mwhite: write, delete

The following list shows a sequence of events in which the ACL for the object is changed and the change is then replicated.

  1. On system B, a client changes the grants in the ACL to:
    • All users: read
    • User lgreen: write, delete
    • User mwhite: write, delete, read ACL
  2. On system A, a client changes the grants in the ACL to:
    • All users: read
    • User mwhite: write
    • User pdgrey: write
  3. The changed ACL on system A is replicated to system B. The resulting ACL for the object on system B contains these grants:
    • All users: read
    • User mwhite: write
    • User pdgrey: write

Configuration collisions

A configuration collision occurs when these events occur in the order shown:

  1. Different changes are made to the same configuration property on each of two systems in a replication link.
  2. The changed property on one of the systems is replicated to the other system.

Examples of configuration properties include:

    • The namespace quota for a tenant
    • The data access permission mask for a namespace
    • The versioning setting for a namespace
    • The default shred setting for a namespace
    • The roles for a user account
    • The data access permissions a group account has for a namespace
    • The protocol optimization setting on a namespace

Certain groups of properties are treated as a single unit. Generally, these groups consist of properties that are updated by a single submission in the System Management Console or Tenant Management Console. Two notable exceptions to this rule are data access permissions for user accounts and content properties for content classes. In these cases, each set of data access permissions for a namespace and each content property is treated as an individual property.

If a collision occurs when a configuration change is replicated from one system (system A) in a replication topology to another system (system B) involved in the link:

  • If the last change to the configuration on system A is more recent than the last change to the configuration on system B, HCP changes the configuration on system B to match the configuration on system A
  • If the last change to the configuration on system B is more recent than the last change to the configuration on system A, HCP does not change the configuration on system B

The rules above apply to all configuration collisions except collisions that occur when retention class properties are changed.

Here are two examples of how HCP handles collisions when configuration changes are replicated from one system (system A) in a replication topology to another system (system B) involved in the link.

Example 1

A given tenant starts out on both system A and system B with these properties:

  • Namespace quota: 5
  • Versioning: disabled

The following list shows a sequence of events in which the tenant configuration is changed and the change is then replicated.

  1. In the System Management Console on system B, an administrator changes the namespace quota for the tenant to 10.
  2. In the System Management Console on system A, an administrator enables versioning for the tenant.
  3. The change on system A is replicated to system B. Because namespace quota and versioning are properties in the same submission group, the resulting properties for the tenant on system B are:
    • Namespace quota: 5
    • Versioning: enabled
Example 2

A given tenant-level user account starts out on both system A and system B with these roles and data access permissions:

  • Roles: monitor, compliance
  • Namespace-1 permissions: browse, read, write, delete

The following list shows a sequence of events in which the user account is changed and the changes are then replicated.

  1. In the System Management Console on system B, an administrator changes the namespace quota for the tenant to 10.
  2. In the System Management Console on system A, an administrator enables versioning for the tenant.
  3. The change on system A is replicated to system B. Because namespace quota and versioning are properties in the same submission group, the resulting properties for the tenant on system B are:
    • Namespace quota: 5
    • Versioning: enabled
  4. In the Tenant Management Console on system A, an administrator adds the privileged permission to Namespace-1.
  5. In the Tenant Management Console on system B, an administrator gives the user account browse and read permissions for Namespace-2.
  6. In the Tenant Management Console on system A, an administrator gives the user account browse, read, and write permissions for Namespace-3.
  7. The changes on system A are replicated to system B. Because roles and data access permissions are in separate submission groups, the resulting roles and data access permissions for the user account on system B are:
    • Roles: compliance
    • Namespace-1 permissions: browse, read, write, delete, privileged
    • Namespace-2 permissions: browse, rea
    • Namespace-3 permissions: browse, read, write

Retention class collisions

A retention class collision occurs when these events occur in the order shown:

  1. Different changes are made to the same retention class on each of two systems in a replication link.
  2. The changed retention class on one of the systems is replicated to the other system.

If a collision occurs when a change to a retention class is replicated from one system (system A) in a replication link to another system (system B) involved in the link:

  • If the last change to the retention class on system A is more recent than the last change to the class on system B and:
    • The value of the class on system A is greater than the value of the class on system B, HCP changes the value of the class on system B to the value of the class on system A
    • The value of the class on system A is less than the value of the class on system B and:
      • System B is in enterprise mode, HCP changes the value of the class on system B to the value of the class on system A
        NoteAn exception to this rule is when the value of the class on system A is -2 (Initial Unspecified) and the value of the class on system B is not 0 (Deletion Allowed). In this case, the value of the class on system B does not change.
      • System B is in compliance mode, HCP does not change the value of the class on system B
  • If the last change to the retention class on system B is more recent than the last change to the class on system A, HCP does not change the value of the class on system B

A retention class value of -1 (Deletion Prohibited) is greater than a value that’s a specific duration. A retention class value of 0 (Deletion Allowed) or -2 (Initial Unspecified) is less than a value that’s a specific duration.

 

  • Was this article helpful?