Product overview > Availability overview > Multi-master replication



Topology considerations for multi-master replication

When implementing multi-master replication, consider aspects in the design such as: arbitration, linking, and performance.


Link considerations in topology design

Ideally, a topology includes the minimum number of links while optimizing trade-offs among change latency, fault tolerance, and performance characteristics.


Arbitration considerations in topology design

Change collisions might occur if the same records can be changed simultaneously in two places. Set up each catalog service domain to have about the same amount of processor, memory, network resources. You might observe that catalog service domains performing change collision handling (arbitration) use more resources than other catalog service domains. Collisions are detected automatically. They are handled with one of two mechanisms:

For topologies in which collisions are possible, consider implementing a hub-and-spoke topology or a tree topology. These two topologies are conducive to avoiding constant collisions, which can happen in the following scenarios:

  1. Multiple catalog service domains experience a collision

  2. Each catalog service domain handles the collision locally, producing revisions

  3. The revisions collide, resulting in revisions of revisions

To avoid collisions, choose a specific catalog service domain, called an arbitration catalog service domain as the collision arbiter for a subset of catalog service domains. For example, a hub-and-spoke topology might use the hub as the collision handler. The spoke collision handler ignores any collisions that are detected by the spoke catalog service domains. The hub catalog service domain creates revisions, preventing unexpected collision revisions. The catalog service domain that is assigned to handle collisions must link to all of the domains for which it is responsible for handling collisions. In a tree topology, any internal parent domains handle collisions for their immediate children. In contrast, if you use a ring topology, you cannot designate one catalog service domain in the ring as the arbiter.

The following table summarizes the arbitration approaches that are most compatible with various topologies.

Table 1. Arbitration approaches. This table states whether application arbitration is compatible with various technologies.
Topology Application ration? Notes
A line of two catalog service domains Yes Choose one catalog service domain as the arbiter.
A line of three catalog service domains Yes The middle catalog service domain must be the arbiter. Think of the middle catalog service domain as the hub in a simple hub-and-spoke topology.
A line of more than three catalog service domains No Application arbitration is not supported.
A hub with N spokes Yes Hub with links to all spokes must be the arbitration catalog service domain.
A ring of N catalog service domains No Application arbitration is not supported.
An acyclic, directed tree (N-ary tree) Yes All root nodes must rate their direct descendants only.


Multi-master replication performance considerations

Take the following limitations into account when using multi-master replication topologies:


Parent topic:

Multi-master data grid replication topologies