Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Make cluster meet reliable under link failures #461
Make cluster meet reliable under link failures #461
Changes from all commits
49e5a7f
d8e6da5
ec68829
a760aa6
0cf724a
1abf81c
da01bb8
be5cb97
d6b9cbd
50f896b
7ac84b6
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Not a blocker for this PR but I think it will be good if we could standardize the logging statement, at least in cluster.c and cluster_legacy.c (which by the way should be renamed as we don't intend to deprecate the current cluster implementation any time soon, even considering the V2 work). There has been discussion in the past about using a more "structural" logging mechanism as well but I now think "incremental perfection" is more practical. What I would like to see in the server log and int the cluster topology area is:
"who" received a message from "whom" about "which node"'s "what" properties have changed from "which value" to "which other value" at "when".
Ideally, an admin can just look at a single log statement to gather all the information.
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.
moved the discussion to #656
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.
nit - I would suggest pulling the conclusion up, which is the last sentence in the comment block below and then explaining the rationale.
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.
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.
This is not strictly needed, right? I saw the servers are started with
cluster-enabled
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.
This is needed (for now at least) since normally we select a random db. We could key it off of the clustering tests though.
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.
Generalize this into a helper function?
unit/cluster/base.tcl has a similar test https://github.com/valkey-io/valkey/blob/unstable/tests/unit/cluster/base.tcl#L12
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.
nit - these definitions are a bit too far from where they are referenced and also they are used only once. It feels like the idea is to treat them as constants? If so, implementing as a proc in some helper tcl files will help deliver that "read-only" impression and increase their usage.