Skip to content

DOC-13173 Enhance documentation for Index Rebalance and Upgrade #3805

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

Draft
wants to merge 3 commits into
base: release/7.6
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions modules/learn/pages/clusters-and-availability/failover.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -27,9 +27,9 @@ Graceful failover _must_ be manually initiated. Hard failover _can_ be manually
Hard failover can also be initiated automatically by Couchbase Server: this is known as _automatic_ failover.
The Cluster Manager detects the unavailability of a node, and duly initiates a _hard_ failover, without administrator intervention.


Note that when a node is failed over (as opposed to _removed_), some replica vBuckets are lost from the surviving nodes; since some are promoted to _active_ status, and are not replaced with new replica-copies.
By contrast, xref:learn:clusters-and-availability/removal.adoc[removal] creates new copies of those replica vBuckets that would otherwise be lost. This maintains the cluster's previous level of data-availability; but results in greater competition for memory resources, across the surviving nodes.
NOTE: When a node is failed over (as opposed to _removed_), some replica vBuckets are lost from the surviving nodes; since some are promoted to _active_ status, and are not replaced with new replica-copies.
By contrast, xref:learn:clusters-and-availability/removal.adoc[removal] creates new copies of those replica vBuckets that would otherwise be lost.
This maintains the cluster's previous level of data-availability; but results in greater competition for memory resources, across the surviving nodes.

Ideally, after any failover, xref:learn:clusters-and-availability/rebalance.adoc[rebalance] should be performed.
This is especially important when a Data Service node has been failed over, since the rebalance will ensure an optimal ratio of active to replica vBuckets across all the remaining Data Service nodes.
Expand Down
24 changes: 24 additions & 0 deletions modules/learn/pages/clusters-and-availability/rebalance.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -145,6 +145,8 @@ The Index Service maintains a cluster-wide set of index definitions and metadata

The rebalance process takes into account the nodes' CPU, RAM, and disk bandwidth to limit its effect on database performance.

NOTE: Shard Based Rebalance and Rebalance Based on File Transfer are synonyms for File-based Rebalance.

[#index-rebalance-methods]
==== Index Rebalance Methods

Expand Down Expand Up @@ -228,6 +230,28 @@ This setting has no effect if you have enabled file-based index rebalancing.
Users with Full Admin or Cluster Admin roles can change the batch size using the REST API.
See xref:rest-api:rest-modify-index-batch-size.adoc[Modify Index Batch Size].

[#smart-batching]
==== Smart Batching

During a Rebalance operation, Couchbase Server breaks the rebuilding process into batches to limit the performance impacts.

The default batch size is set to 3 applying a limit on the amount of work attempted concurrently.

In Couchbase Server 7.1 and later versions, you can use smart batching with one or more of the following purposes:

* Reduces further time and resources required to move the index metadata.
* Rebuilds indexes at their new locations during rebalance.
* Increases rebalance performance by increasing pipeline parallelism by starting the next batch when the previous batch is only partially completed.
* Allows the increase of overall concurrency by using administrator-determined modifications of the batch size.
* Optimizes the sharing of data streams where index relocation takes place.
* Repairs, prior to index relocation, index replicas lost due to node failure.
* When appropriate, reassigns scheduled index-rebuilding from one batch to the next, to balance the workloads.

If at least one node in the cluster is running a Server version 7.1+ then most of the smart batching features apply to the cluster where some of the nodes are running an earlier version.

You can change the default batch size of 3 by the Full Admin and Cluster Admin roles using the REST API.
For information, see xref:rest-api:rest-modify-index-batch-size.adoc[Modify Index Batch Size].

[#rebalancing-the-search-service]
=== Search Service

Expand Down
5 changes: 4 additions & 1 deletion modules/manage/pages/manage-settings/general-settings.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -313,12 +313,15 @@ During an upgrade, mixed mode clusters with nodes that support bloom filters wil

[#file-based-index-rebalance]
* *File Transfer Based Rebalance*:
Controls whether Couchbase Server rebuilds indexes or copies them between nodes.
Controls whether Couchbase Server rebuilds indexes or copies them between nodes.
Use the **Enable File Transfer Based Rebalance** checkbox to enable or disable the File Transfer Based Rebalance from the UI.
The default cleared setting has an Index Server node rebuild any newly assigned index during a rebalance.
You cannot enable file-based rebalance when you have enabled Memory Optimized Index Storage.
When you select this option, Couchbase Server copies the index files from one Index Server node to another during a rebalance instead of rebuilding them.
See xref:learn:clusters-and-availability/rebalance.adoc#index-rebalance-methods[Index Rebalance Methods].
+
NOTE: Shard Based Rebalance and Rebalance Based on File Transfer are synonyms for File-based Rebalance.
+
You can disable this feature from the UI or via REST API. To learn about disabling this feature via REST API, see xref:rest-api:post-settings-indexes.adoc#disable-file-transfer-based-rebalance[Curl Command to Disable the File Transfer Based Rebalance]. This feature is disabled by default.
+
WARNING: Disabling this feature slows down the Rebalance operation.
Expand Down
2 changes: 2 additions & 0 deletions modules/rest-api/pages/post-settings-indexes.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -161,6 +161,8 @@ include::example$post-settings-indexes.jsonc[]

The following command disables the File Transfer Based Rebalance (`enableShardAffinity`) feature in the xref:manage:manage-settings/general-settings.adoc#index-storage-mode[Index Storage Mode].

NOTE: Shard Based Rebalance and Rebalance Based on File Transfer are synonyms for File-based Rebalance.

[source#example-curl,bash]
----
include::example$post-settings-indexes.sh[tag=disable-ftb-rebalance]
Expand Down
2 changes: 2 additions & 0 deletions modules/rest-api/pages/rest-modify-index-batch-size.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,8 @@
{description}


NOTE: Shard Based Rebalance and Rebalance Based on File Transfer are synonyms for File-based Rebalance.

== HTTP Method and URI

----
Expand Down