In this lesson, you will learn how to maintain a consistent view of data across multiple database nodes by using time-based markers or global sequences.
The Challenge of Distributed Snapshots
In a single-node database, providing "Snapshot Isolation" is easy: the system assigns a transaction a version number (or timestamp) when it starts. All reads for that transaction look only at data committed before that specific time.
In a distributed system, this becomes difficult because each node has its own local clock. If Node A and Node B have slightly different times, a transaction might see inconsistent data depending on which node it queries. To solve this, we must coordinate how we define the "current snapshot" across the entire cluster.
Synchronized Clocks and Sequence Markers
There are two primary ways to ensure that every node agrees on the state of the database at a specific moment:
-
Global Sequence Markers (Logical Time): Instead of relying on physical wall-clock time, the system uses a Global Transaction Manager (GTM). When a transaction begins, it requests a globally unique, monotonically increasing ID from the GTM. Every node in the cluster uses this ID to filter which data versions are visible.
-
Synchronized Clocks (Physical Time): Systems like Google Spanner use high-precision hardware (Atomic Clocks and GPS receivers) to keep physical clocks across data centers tightly synchronized. By accounting for a small, known "uncertainty window" (the epsilon), the system can guarantee that a transaction sees a snapshot consistent with the actual order of events in the real world.
A Conceptual View
Imagine a transaction T1 receives a global timestamp TS=100 from the GTM. When T1 performs a query across three shards:
-- Each node filters rows based on the global timestamp
SELECT * FROM orders
WHERE commit_timestamp <= 100;
Because the timestamp is global, T1 will see a snapshot of the database that is consistent across all nodes, regardless of which physical server holds the data. The complexity lies in ensuring that no node is "missing" any updates that occurred before TS=100.
Key Takeaway: Distributed Snapshot Isolation relies on a shared time-reference—either via a centralized sequencer or tightly synchronized clocks—to ensure that every node in the cluster interprets the "snapshot" of data in exactly the same way.