Why Multi-Leader Replication Causes Conflicts and How to Tackle Them
This article examines how single‑value objects encounter data‑value conflicts in multi‑leader replication architectures, explains the role of causal ordering versus concurrent writes, and outlines the need for global clocks, versioning, and broadcast mechanisms to resolve such conflicts.
Multi‑Leader Replication Conflict Issues
We continue the discussion on single‑value object conflicts in multi‑leader replication deployment architectures. The article is split into multiple parts and does not yet detail conflict‑resolution solutions.
Private data refers to data that only its owner can write, while others have read‑only access. No constraints are imposed, allowing arbitrary writes.
In a Multi‑Leader replication model, a user (UserA) performs a series of writes (x=1, x=2, x=3). These writes have a causal relationship: each operation depends on the previous one, forming a total order in the time series.
If the same three operations run on a single‑leader replication architecture, the inherent order prevents conflicts. However, in a multi‑leader setup the writes are routed to different IDC nodes, leading to potential data‑value conflicts.
When asynchronous replication occurs, the same field may hold different values across nodes, creating a conflict.
If operations have a causal dependency, a global clock (logical clock or Google TrueTime) is required to preserve order. If operations are independent (concurrent), a version number provides a global order for resolving value conflicts.
For uniquely constrained data such as a name, the request layer must make decisions when a data‑value conflict arises.
Shared data that can be overwritten only once resembles uniquely constrained data, but ownership differs. Predictable system‑provided resources allow pre‑allocation and design to avoid complex consensus, e.g., using a global resource table to assist broadcast mechanisms.
Because conflicts occur at the user‑request layer, merely introducing a total order is insufficient; a broadcast mechanism (total‑order broadcast) is needed.
The final data type discussed is shared data that can be overwritten multiple times. In a Multi‑Leader model, conflicts arise both from concurrent edits and from replication across data centers.
Summary
From the above multi‑leader conflict analysis, the key technologies are ordering and version numbers , focusing on data‑value conflicts. We introduced the concept of a Clock for causally related operations and a Version for concurrent operations, laying the groundwork for Lamport Timestamps and Version Vectors.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Xiaokun's Architecture Exploration Notes
10 years of backend architecture design | AI engineering infrastructure, storage architecture design, and performance optimization | Former senior developer at NetEase, Douyu, Inke, etc.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.