Linearizable Reads: Log Reads, ReadIndex and Leases

A leader might not be the leader any more

Serving a read straight from the leader's local state is tempting but unsafe: a leader isolated by a partition may not know a newer leader has been elected and has accepted writes, so it would return stale data. There are three standard fixes. Log reads put the read through the log like a write; correct but costly. ReadIndex: the leader (once it has committed an entry in its own term) records its current commit index, confirms it is still leader by getting heartbeat acknowledgements from a majority, waits until its state machine has applied up to that index, then answers locally. This costs one round of heartbeats but no disk write. Lease reads: after a successful heartbeat round, the leader assumes no other leader can exist for slightly less than the election timeout and serves reads without contacting anyone. This is the fastest, but its safety now depends on bounded clock drift, which breaks the 'safety never depends on timing' principle. Followers can also serve reads by asking the leader for a ReadIndex.

Choosing read consistency in etcdctl

etcd serves linearizable reads by default. A serializable read is answered by the local member and may be stale, but needs no quorum.

# Linearizable (default): confirmed with a quorum, never stale
etcdctl get /config/feature-x

# Serializable: answered locally by whichever member you hit; may be stale
etcdctl get /config/feature-x --consistency=s

Stale reads in disguise

A common bug: reading from any replica 'because reads are safe'. In a consensus system a follower read without ReadIndex can return a value that was overwritten seconds ago, which breaks linearizability even though no write was lost.

त्वरित जाँच: What extra assumption makes lease-based reads faster but riskier than ReadIndex?

• Disks never lose data
• Messages are never reordered
• Clock drift between servers is bounded
• There are always an odd number of servers