Tenant conflicts
A tenant conflict occurs when you add a tenant to an erasure coding topology and that tenant is on one or more replication links where:
- The link is not in the topology
- One or both of the systems involved in the link are in the topology
When a tenant conflict occurs, the Replication service automatically pauses replication or recovery of the tenant on each link that meets the criteria listed above.
To recover from a tenant conflict, take one of these actions:
- Remove the tenant from the links on which replication or recovery of the tenant is paused.
- Remove the tenant from the erasure coding topology. Then resume replication or recovery of the tenant on the applicable links.
Here's a scenario that shows how a tenant conflict can cause the Replication service to pause replication of a tenant. In this scenario:
- Erase coding topology ECT1 is a ring topology that consists of:
- Systems A, B, C, and D
- Active/active link AB between systems A and B
- Active/active link BC between systems B and C
- Active/active link CD between systems C and D
- Active/active link DA between systems D and A
- ECT1 is the active erasure coding topology.
- Tenant T1 is included in topology ECT1. Therefore, T1 is included on links AB, BC, CD, and DA and exists on systems A, B, C, and D.

These events occur in the order shown:
- You deploy system E.
- You retire topology ECT1.
- You create active/active link BE between systems B and E.
- You create active/active link CE between systems C and E.
- You create a new topology, ECT2, that consists of systems B, C, and E and links BC, BE, and CE.
- You add tenant T1 to topology ECT2.
- All of these occur:
- T1 is added to links BE and CE and is replicated to system E.
- The Replication service on system B pauses replication or recovery of T1 on link AB because system B is in topology ECT2 and system A is not
- The Replication service on system C pauses replication or recovery of T1 on link CD because system C is in topology ECT2 and system D is not