Multi-primary replication: multiple writers require explicit conflict rules.

What multi-primary replication means

Some systems certify transactions before commit. Some serialize changes through group communication or consensus. Others replicate asynchronously and resolve conflicts afterward. These approaches have very different guarantees, so product documentation and workload testing are essential.

Typical write workflow

Application writes to Node A
        ↓
Node A validates and executes transaction
        ↓
Change set is ordered, certified or logged
        ↓
Peer nodes apply the transaction
        ↓
Commit is acknowledged according to the durability model

The critical questions are when the transaction is considered committed, whether peer confirmation is required, what happens when another transaction touches the same data, and how a disconnected node rejoins.

Conflict types

Update-update conflicts

Two nodes update the same row or logical entity concurrently. Certification may abort one transaction, while asynchronous systems may apply a resolution rule later.

Insert and uniqueness conflicts

Different nodes insert the same primary key, unique key, email, order number or other business identifier. Local validation can succeed on both nodes before replication exposes the collision.

Delete-update conflicts

One node deletes a row while another updates it. The final state depends on ordering and conflict policy.

Business invariant conflicts

Transactions may touch different rows but violate a global rule, such as overselling inventory, exceeding an account limit or assigning the same scarce resource twice. Row-level conflict detection may not protect these invariants.

Conflict prevention strategies

• Single-writer ownership: route each tenant, key range or entity to one designated writer.
• Partitioned writes: use different nodes for non-overlapping data sets.
• Certification: detect overlapping write sets and abort conflicting transactions.
• Global ordering: serialize transactions through consensus or deterministic ordering.
• Commutative operations: design updates that can merge safely when the business model allows it.
• Idempotency keys: prevent duplicate effects during retries.
• Global identity generation: avoid primary key and sequence collisions.

Conflict resolution after the event should be a last, well-specified mechanism. Silent last-write-wins policies may be unacceptable for financial, inventory or compliance data.

Synchronous versus asynchronous behavior

Multi-primary versus active-active

Multi-primary is a replication capability. Active-active is the broader service model. An active-active design may use multi-primary replication, but it may instead use sharded ownership, one writer per region, active reads with centralized writes, or a native distributed SQL database. Review the active-active database guide for the broader context.

Operational checklist

• document supported isolation levels and conflict behavior;
• test concurrent insert, update and delete patterns;
• protect primary keys, unique keys and sequences;
• monitor certification failures, replication lag and node membership;
• define network-partition and quorum behavior;
• control schema changes across members;
• test node rejoin, state transfer and full rebuild;
• verify backup restoration does not reintroduce conflicting state.

ShardronDB perspective

ShardronDB does not describe itself as generic multi-primary replication. Its public model uses a gateway to control requests before they reach relational nodes, assigns node-local ownership and separates primary and backup placement. This can reduce overlapping write domains compared with unrestricted multi-writer replication.

The PK Guard rule also rejects client-supplied primary key values for normal inserts. Identity generation occurs after validation, while trusted migration, backup and recovery paths are explicitly separated. Read the primary key collision guide and the coordination-layer guide.

Frequently asked questions