-
Notifications
You must be signed in to change notification settings - Fork 9.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lease TTL resetting on leader elections or single-node restart, but it isn't doccumented #9395
Comments
It is needed since only the leader records TTL for performance reasons. It wont be changed. We should document it though. But if you expect the leader changes much more frequent than lease can expire, you have to either make your cluster more reliable or shorter the lease. |
in another word, etcd lease is for short period keepalive in the range of seconds or minutes at max. not for hours or days. |
Thanks for the explanation! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey Folks,
https://github.com/coreos/etcd/blob/master/lease/lessor.go#L343 Seems to indicate (and some initial testing confirms) that every time there is a leader election (which happens on cluster restart), all of the leases get re-set to the current time plus the initial TTL (plus the leader timeout).
So, two questions:
Why is this needed? It makes sense to me that we have to extend the time by the amount of time which the old leader would take to start rejecting attempts to extend a lease, but it seems to be that that that would never be longer than the leader election timeout. Re-setting all the leases to the initial TTL seems very heavy handed.
I couldn't find any discussions of this in the docs. It was pretty unexpected to us to find that leases might never expire if there were enough leader elections, so if this is deliberate, I think it merits some talk in the docs.
Thanks for the clarification.
The text was updated successfully, but these errors were encountered: