From 8eda527610978cb9fe54df55aee465195a370c1e Mon Sep 17 00:00:00 2001 From: Andrey Vasnetsov Date: Sat, 9 Nov 2024 21:57:14 +0100 Subject: [PATCH] Update distributed_deployment.md --- .../documentation/guides/distributed_deployment.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/qdrant-landing/content/documentation/guides/distributed_deployment.md b/qdrant-landing/content/documentation/guides/distributed_deployment.md index 237baaa88..a1e225c7a 100644 --- a/qdrant-landing/content/documentation/guides/distributed_deployment.md +++ b/qdrant-landing/content/documentation/guides/distributed_deployment.md @@ -1159,6 +1159,15 @@ 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. + +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. + +For asynchronous updates and injection pipelines capable of handling errors and retries, this strategy might be preferable. + + ### Read consistency Read `consistency` can be specified for most read requests and will ensure that the returned result