-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
docs: auto-promoting nodes #10913
docs: auto-promoting nodes #10913
Conversation
Codecov Report
@@ Coverage Diff @@
## master #10913 +/- ##
==========================================
+ Coverage 65.91% 66.26% +0.34%
==========================================
Files 403 403
Lines 37021 37067 +46
==========================================
+ Hits 24403 24563 +160
+ Misses 11112 11007 -105
+ Partials 1506 1497 -9
Continue to review full report at Codecov.
|
Thanks for making the PR. I think this is a good starting point. Let's use this PR to gather comments and suggestions on API changes as well as implementation details regarding learner promotion in upcoming and future releases. |
docs/server-learner.rst
Outdated
@@ -9,7 +9,7 @@ Learner | |||
Gyuho Lee (github.com/gyuho, *Amazon.com*), | |||
Joe Betz (github.com/jpbetz, *Google Inc.*) | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add your name here:)
docs/server-learner.rst
Outdated
@@ -140,6 +142,25 @@ etcd server must not transfer leadership to learner, since it may still lag behi | |||
|
|||
Internally in Raft, second ``MemberAdd`` call to learner node promotes it to a voting member. Leader maintains the progress of each follower and learner. If learner has not completed its snapshot message, reject promote request. Only accept promote request if and only if: The learner node is in a healthy state. The learner is in sync with leader or the delta is within the threshold (e.g. the number of entries to replicate to learner is less than 1/10 of snapshot count, which means it is less likely that even after promotion leader would not need send snapshot to the learner). All these logic are hard-coded in ``etcdserver`` package and not configurable. | |||
|
|||
*Expose "Auto-promoting" node type to "MemberAdd" API.* | |||
|
|||
etcd client adds an “AutoPromote” flag to ``MemberAdd`` API for auto-promoting learner nodes. This flag is only effective when used in conjunction with the “IsLearner” flag, and is ignored otherwise. An etcd server handler applies membership change entry with ``pb.ConfChangeAddAutoPromotingNode`` type. Once the command has been applied, a server joins the cluster with ``etcd --initial-cluster-state=existing`` flag. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is "AutoPromote" flag only needed in short term and will eventually be deprecated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @jingyih, I think you could definitely make a case for that.
On the other hand, I think you could also make a case for removing the --learner
(and IsLearner
) flag, because in v3.5 the default and only behavior of of newly added members is to be a learner (until manually or automatically promoted). It might be more expressive to keep --auto-promote
and allow operators to specify --auto-promote=false
to add a standby learner.
Hi @jingyih @gyuho @jpbetz @xiang90 @WIZARD-CXY Pardon the ping, wanted see if anyone has additional feedback on this proposal and associated PR? |
I added an item for this in tomorrow's etcd community meeting to ask for reviews and comments. https://docs.google.com/document/d/16XEGyPBisZvmmoIHSZzv__LoyOeluC5a4x353CX0SIM |
There are three cases for auto-promote:
|
@xiang90 thanks for the comment. Does that mean you do not think there is a 4th case (the case I have proposed in this PR) to have new voters be added first as learners, which are then auto-promoted upon catching up with leader? Or is 4th case == 1st case? |
Sorry, I mean there are additional 3 cases we should be aware of. I am fine with addressing the one you proposed here. From UX perspective, I hope them can be consistent. So I mentioned other cases for you to consider. |
Thanks for the clarification @xiang90, what you're saying about consistency makes sense to me. I can imagine, for example, having additional possible values for |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
👋 Based on the comments above and the current state of learner doc, I am thinking of something like this for the CLI and PB APIs. CLICurrent learner behaviorDo not automatically promote to reader or voter. Operator must manually trigger promotion.
The above command is equivalent to:
Promote to voterAutomatically promotes learner to voter when is has achieved at least 90% progress towards being in-sync with leader.
Automatically promote learner to voter when the cluster has less than three voters for 5 seconds.
Automatically promote learner to voter when the cluster has less than current number of members for 10 seconds.
Promote to readerPromote to read-only node when progress is 50% of leader's. Allow reading possibly stale data.
Promote to read-only node when any member (voter or otherwise) becomes unhealthy. Disallow reading possibly stale data.
Combine promotion rulesCombines promotion rules so that the learner is promoted either...
In theory, the above rules could be interpreted so that the learner is first promoted to a reader when it has caught up with the leader. Later, if any voter becomes unhealthy, the learner (now a reader) could be promoted to a voter. We wouldn't allow the learner to be promoted to a voter, and later a reader (presumably that would be a demotion). PBFor the protobuf API, was thinking of something like this.
If all that is too much, can go with something a little simpler, e.g. with something that does not support combinations of rules, and which flattens all possible monitors into the Looking forward to feedback. In the meantime, am going to start making adjustments to this PR to support |
13de299
to
2b87fc8
Compare
Pardon the ping @jingyih and @xiang90. I've tried to make adjustments to address some of the comments you've provided me here.
My last comment above describes how I am currently imagining the Looking forward to your feedback. |
Thanks for the detailed propose! I do not quite follow your PB section, maybe it makes more sense to me when I see it in the PR. Currently there is no "reader" member in etcd. Is this something you plan on adding? |
Hi @jingyih thanks for following up. In my comment above I included the concept of a "reader" member because it is mentioned in the learner docs as planned for 3.5. With this comment I wanted to show how, even though the changes in this PR do not include any reference to a "reader", they could easily be extended to support that type of member. I wasn't planning on adding support for a "reader" member in this PR (or in this one either), but I would happy to help with that effort in another PR. |
Thanks! Could you mention this topic in this week's etcd community meeting and ask for people's comment and review? The behavior you defined in CLI section looks good to me. |
Hi @jingyih sorry I couldn't make it today due to a conflict. Will try to make the next one. In the meantime, let me know if there's anything else I can do to move this along. |
My suggestion of the next step is to start implement |
@jingyih Sounds good, it's implemented here. It currently has a I'm happy to remove the flag if people don't like it, but I think it's useful for showing how other rules (e.g. |
@gyuho thanks for the chat during community meeting, here is the PR I referenced with design proposal for auto-promoting nodes. I've tried to follow @jingyih and @xiang90 recommendations above as much as possible. The proposal here lays out long-term API design, which will eventually support automatically promoting nodes based on multiple conditions (# voters in cluster, # healthy nodes). The implementation PR in #10887 implements a subset of this proposal: auto promote based on log progress of learner. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions. |
/stale remove |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@maxenglander thanks for the PR, and fyi that the project Doc is moved to https://github.com/etcd-io/website/ so this PR should be closed and be created in the doc repo now. Sorry it took long in the review process, but we will try to review and merge quickly in the doc repo. Thanks!
Thanks you @spzala I'll get this moved over. |
Yrw, and thank you @maxenglander |
Propose
v3.4v3.5 support for having a cluster automatically promotea learner node to a voting member when added to a cluster with
member add --learner --auto
.The changes proposed for
v3.4v3.5 in this PR are implemented in #10887.