Skip to content
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

Fix multi-shard explanation. #2493

Merged
merged 4 commits into from
Jan 5, 2024
Merged

Fix multi-shard explanation. #2493

merged 4 commits into from
Jan 5, 2024

Conversation

nihohit
Copy link
Contributor

@nihohit nihohit commented Jul 20, 2023

No description provided.

@netlify
Copy link

netlify bot commented Jul 20, 2023

👷 Deploy request for redis-doc pending review.

Visit the deploys page to approve it

Name Link
🔨 Latest commit c043bd1

Copy link
Member

@oranagra oranagra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -50,7 +50,7 @@ In cases where the client should adopt a behavior different than the default, th
This tip is in-use by commands that don't accept key name arguments.
The command operates atomically per shard.
- **multi_shard:** the client should execute the command on several shards.
The shards that execute the command are determined by the hash slots of its input key name arguments.
The client should split the inputs according to the hash slots of its input key name arguments. For example, the command `MSET {foo} baz {foo}1 baz1 bar vaz` should be split to `MSET {foo} baz {foo}1 baz1` and `MSET bar vaz`. If the keys are hashed to more than a single slot, the command must be split even if all the slots are managed by the same shard.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe an example with DEL will be easier to follow?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intentionally chose MSET, because it's slightly more complex than MGET / DEL. If you think that the phrasing and principle are clear enough that a less complex example would work, I'll switch to DEL.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think the principle is clear enough with DEL and MGET and it'll be easier to read.
it's right that the implementation in case of MSET is more complex, but that's something to worry about in implementation stage.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@oranagra oranagra added the to-be-merged should probably be merged soon label Jul 20, 2023
docs/reference/command-tips.md Outdated Show resolved Hide resolved
@zuiderkwast zuiderkwast merged commit b990e9f into redis:master Jan 5, 2024
1 check failed
@zuiderkwast
Copy link
Contributor

I merged this now. Thanks!

I have two other questions regarding the multi-shard request policy:

  1. Why is there no mention that this behaviour of a client breaks the atomicity of the commands? I wasn't aware that we actually recommend this behaviour.
  2. What shall the client return to the user if the command fails on one node and succeeds on the other nodes? (There is no obvious way to report a partial failure to the user.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
to-be-merged should probably be merged soon
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants