krzysztof/landing_page
1
0
Fork 0
mirror of https://github.com/qdrant/landing_page.git synced 2026-09-30 16:38:31 +02:00
Code Issues Packages Projects Releases Wiki Activity

Update distributed_deployment.md

Browse Source
This commit is contained in:
davidmyriel
2024-11-14 15:33:38 -08:00
parent ffb8e8d633
commit 538d69326e
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
qdrant-landing/content/documentation/guides/distributed_deployment.md
+2 -2
View File
@@ -1159,11 +1159,11 @@ client.CreateCollection(context.Background(), &qdrant.CreateCollection{
Write operations will fail if the number of active replicas is less than the `write_consistency_factor`.
The configuration of the write_consistency_factor is important for adjusting the cluster's behavior when some nodes go offline due to restarts, upgrades, or failures.
The configuration of the `write_consistency_factor` is important for adjusting the cluster's behavior when some nodes go offline due to restarts, upgrades, or failures.
By default, the cluster continues to accept updates as long as at least one replica of each shard is online. However, this behavior means that once an offline replica is restored, it will require additional synchronization with the rest of the cluster. In some cases, this synchronization can be resource-intensive and undesirable.
Setting the write_consistency_factor to match the replication factor modifies the cluster's behavior so that unreplicated updates are rejected, preventing the need for extra synchronization.
Setting the `write_consistency_factor` to match the replication factor modifies the cluster's behavior so that unreplicated updates are rejected, preventing the need for extra synchronization.
If the update is applied to enough replicas - according to the `write_consistency_factor` - the update will return a successful status. Any replicas that failed to apply the update will be temporarily disabled and are automatically recovered to keep data consistency. If the update could not be applied to enough replicas, it'll return an error and may be partially applied. The user must submit the operation again to ensure data consistency.