-
Notifications
You must be signed in to change notification settings - Fork 76
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
Extend write consistency factor text, reapply on client vs lower factor #1013
base: master
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for condescending-goldwasser-91acf0 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
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.
Thank you @timvisee! 🙌
|
||
Setting the `write_consistency_factor` to a lower value may allow accepting | ||
writes even if there are unresponsive nodes. Unresponsive nodes are marked as | ||
dead and will automatically be recovered again once available to ensure data |
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.
dead and will automatically be recovered again once available to ensure data | |
dead and will automatically be recovered once available to ensure data |
operation again to ensure a consistent state is reached. | ||
|
||
Setting the `write_consistency_factor` to a lower value may allow accepting | ||
writes even if there are unresponsive nodes. Unresponsive nodes are marked as |
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.
If a write is accepted by one node, and that node restarts before it can propagate the write, will the write be lost?
Fixes qdrant/qdrant#4626
Rendered: https://deploy-preview-1013--condescending-goldwasser-91acf0.netlify.app/documentation/guides/distributed_deployment/#write-consistency-factor
This extends the write consistency factor description a bit. It improves on two points.
First, if a high write consistency factor is used an operation might fail to apply if there aren't enough active replicas. It now describes that the user is responsible for sending the operation again, to ensure a consistent state.
Second, this now describes that a lower write consistency factor may be used. In that case the write will be accepted if there are non-active replicas. Unresponsive replicas are marked as dead and are automatically recovered by the cluster to guarantee data consistency once available.