--- title: Removal description: Node removal allows a node to be taken out of a cluster in a highly controlled fashion, using rebalance to redistribute data, indexes, event processing, and query processing among available nodes. pubDate: 2026-08-17T09:53:44.266Z antora: editUrl: https://github.com/couchbase/docs-server/edit/release/7.6/modules/learn/pages/clusters-and-availability/removal.adoc xref: xref:7.6@server:learn:clusters-and-availability/removal.adoc[] --- [Consult the llms.txt file for a full list of contents](/llms.txt) [View original HTML](/server/7.6/learn/clusters-and-availability/removal.html) # Removal > Node _removal_ allows a node to be taken out of a cluster in a highly controlled fashion, using _rebalance_ to redistribute data, indexes, event processing, and query processing among available nodes. ## [](#understanding-removal)Understanding Removal _Removal_ provides the most highly controlled means of taking a node out of a cluster. Any node, whatever its service-configuration, can be removed. However, removal should be used only when all nodes in the cluster are responsive, and those intended to remain in the cluster after removal have the capacity to support the results. Removal essentially means using [Rebalance](rebalance.md) to redistribute data across a subset of pre-existing cluster-nodes. It can be performed with the UI, the CLI, or the REST API. When the CLI or REST API is used, a single command initiates a rebalance, specifying which nodes are to be excluded. When the UI is used, nodes to be removed are first identified, then rebalance is initiated. When the rebalance is complete, the _cluster map_ is correspondingly updated and distributed to clients. The process occurs while the cluster continues to service requests for data. Note that when a node is removed from a cluster, its configuration is deleted. If the removed node is subsequently re-added to the cluster, it is added as a new node, with a new definition of its configuration. For information on how to perform node-removal with the UI, the CLI, and the REST API, see [Remove a Node and Rebalance](../../manage/manage-nodes/remove-node-and-rebalance.md). ## [](#removal-and-cluster-resources)Removal and Cluster Resources Whenever a node is removed from a cluster, the resources of the cluster are necessarily diminished. When the removed node hosted the Data Service, the reduced cluster necessarily has less memory, storage, and processing power to support the maintenance of data; and may also have insufficient nodes to support the previously established number of bucket-replicas. The actions taken by the Cluster Manager in response to Data-Service node-removal are summarized below. ### [](#removal-without-replication-constraint)Removal Without Replication-Constraint A bucket can be configured with _replicas_. The maximum number of replicas permitted is 3\. The number of Data Service nodes required to support replication, given a configuration of _n_ replicas, is _n + 1_. If node-removal does not reduce the number of Data Service nodes below _n + 1_, the number of replicas for the bucket is maintained, following rebalance. Correspondingly, the volume of data on each of the surviving Data Service nodes is increased. This is illustrated by the following two tables, which respectively represent a cluster of Data Service nodes before and after the removal of one node. Table 1 shows the number of items, on each of four individual nodes and for the entire cluster, for a single bucket with two replicas. (Note that some numbers are approximated: these are displayed in italics.) __Table 1\. Four Data Service Nodes, One Bucket with 31,591 Items, Two Replicas__ | Host | Active Items | Replica Items | | ------ | ------------ | ------------- | | Node 1 | 7,932 | _15,800_ | | Node 2 | 7,895 | _15,800_ | | Node 3 | 7,876 | _15,700_ | | Node 4 | 7,888 | _15,700_ | | Total | 31,591 | _63,000_ | As Table 1 shows, each of the four nodes takes a roughly equal share of the bucket-items kept in _active_ vBuckets. It also takes a roughly equal share of the replica bucket-items, kept in _replica_ vBuckets. Since the bucket has two replicas, the ratio of _active_ to _replica_ items, both on each node and in the total for the cluster, is approximately _1:2_. Table 2 shows the results on the cluster of the removal of node 4 and subsequent rebalance. __Table 2\. Three Surviving Data Service Nodes, One Bucket with 31,591 Items, Two Replicas__ | Host | Active Items | Replica Items | | ------ | ------------ | ------------- | | Node 1 | 10,497 | _21,000_ | | Node 2 | _10,500_ | _21,000_ | | Node 3 | _10,400_ | _21,000_ | | Node 4 | NA | NA | | Total | 31,591 | _63,000_ | As Table 2 shows, following removal and rebalance, all data is hosted on the three surviving Data Service nodes. The ratio of _active_ to _replica_ items remains _1:2_ throughout: this is because the number of Data Service nodes has been reduced from _n + 2_ to _n + 1_, and is therefore still sufficient to maintain the specified number of replicas. On each individual node, however, the numbers of active and replica items are now correspondingly higher. ### [](#removal-with-replication-constraint)Removal With Replication-Constraint If node-removal reduces the number of Data Service nodes below _n + 1_, the number of replicas for the bucket is reduced to the maximum possible, following rebalance. This is shown by the following table, which represents the cluster of Data Service nodes shown above in Table 2, after the removal of a further node and subsequent rebalance. __Table 3\. Two Surviving Data Service Nodes, One Bucket with 31,591 Items, One Surviving Replica__ | Host | Active Items | Replica Items | | ------ | ------------ | ------------- | | Node 1 | 15,897 | _15,700_ | | Node 2 | _15,700_ | _15,800_ | | Node 3 | NA | NA | | Node 4 | NA | NA | | Total | 31,591 | _31,500_ | As this shows, following removal and rebalance, all data is hosted on the two surviving Data Service nodes. The approximate ratio, on each node, of active to replica items is now _1:1_, indicating that a single replica has been retained; this being the maximum number permitted by the new hardware configuration. Note that since multiple buckets may have been configured, and different replication-levels applied, removal and rebalance may result in the replica-count for some buckets being reduced, but for others maintained. For further examples of rebalance, in the context of _failover_, see [Failover](failover.md). ## [](#removal-versus-graceful-failover)Removal versus Graceful Failover As an alternative to removal, a responsive Data Service node can be taken out of a cluster by means of _Graceful Failover_. This may be faster, but the consequences do not maintain previous availability-levels. An account of the advantages and disadvantages is provided in [Graceful Failover](graceful-failover.md#advantages-and-disadvantages).