Clock synchronization requirements for stretched etcd cluster using leases across multiple sites

[prateekkohli21]

Hi Team,

We are running an etcd cluster stretched across multiple sites (1 member per site).
We use etcd leases (TTL + keepalive) for leader election and failover.

As per my understanding, it seems leases and raft rely on elapsed/monotonic time, not wall-clock comparison.

Question:
Do etcd members require clock synchronization (NTP/chrony) between sites for:

1. lease expiration correctness
2. raft leader election stability

So is clock sync mandatory, recommended or unnecessary for correctness?

Looking for official guidance for stretched/WAN clusters.

Thanks!!

[ahrtr]

etcd does not strictly require the clocks of its members to be synchronized, but it is generally considered best practice to keep them in sync. The leader uses its local clock to determine whether leases have expired.

Note that Raft leader election is not affected by wall-clock being unsynchronized or by clock drift.

Related docs:

• https://etcd.io/docs/v3.6/learning/why/#notes-on-the-usage-of-lock-and-lease
• https://etcd.io/docs/v3.6/learning/api/#lease-api