Scaling In a Cluster by Removing a Specific Node

Function

If a cluster has excess capacity due to off-peak traffic or reduced data volume, you can reduce its nodes to cut costs.

Constraints

During a scale-in, the data on the to-be-removed nodes needs to be migrated to the remaining nodes. The timeout for data migration per node is 48 hours. Scale-in will fail if this timeout expires. When the cluster has large quantities of data, you are advised to manually adjust the data migration rate and avoid performing the migration during peak hours.
Yearly/Monthly clusters do not support the removal of specified nodes by calling this API.
All mission-critical data has been backed up before a cluster scale-in. This is to prevent data loss.
Only Elasticsearch and OpenSearch clusters support this option.
During a scale-in, the data on the to-be-removed nodes needs to be migrated to the remaining nodes. The timeout for data migration per node is 48 hours. Scale-in will fail if this timeout expires. When the cluster has large quantities of data, you are advised to manually adjust the data migration rate and avoid performing the migration during peak hours.
For a cluster without master nodes, scale-in is allowed only if the number of data nodes plus cold data nodes is at least three. During a scale-in, you can only remove less than half of the data nodes plus cold data nodes, and the remaining number must be greater than the maximum number of index replicas.
For a cluster with master nodes, scale-in is allowed only if the cluster has at least two data nodes. During a scale-in, you can only remove less than half of the cluster's master nodes.
After the scale-in, the cluster nodes' disk usage must be less than 80%.
After the scale-in, there has to be at least one of each type of node in each AZ. For a cross-AZ cluster, the difference between the numbers of the same-type nodes in different AZs cannot exceed 1.

Calling Method

For details, see Calling APIs.

URI

POST /v1.0/{project_id}/clusters/{cluster_id}/node/offline

**Table 1** Path Parameters
Parameter	Mandatory	Type	Description
project_id	Yes	String	Definition: Project ID. For details about how to obtain the project ID and name, see Obtaining the Project ID and Name. Constraints: N/A Value range: Project ID of the account. Default value: N/A
cluster_id	Yes	String	Definition: ID of the cluster to be scaled in. For details about how to obtain the cluster ID, see Obtaining the Cluster ID. Constraints: N/A Value range: Cluster ID. Default value: N/A

Request Parameters

**Table 2** Request body parameters
Parameter	Mandatory	Type	Description
migrate_data	No	String	Definition: Whether to migrate data. Value range: true: Migrate data. During data migration, the system migrates all data from the to-be-removed nodes to the remaining nodes, and removes these nodes upon completion of the data migration. false: Do not migrate data. If the data on the to-be-removed nodes has replicas on other nodes, data migration can be skipped and the cluster change can be completed faster. Default value: true
shrink_nodes	Yes	Array of strings	Definition: ID of the node to be removed. Constraints: N/A Value range: Obtain the ID attribute in instances by referring to Querying Cluster Details. Default value: N/A
agency_name	No	String	Definition: Agency name that grants the current account the permission to access and use OBS. To store snapshots to an OBS bucket, you must have the required OBS access permissions. Constraints: VPC permissions required by the agency: "vpc:subnets:get","vpc:ports:". This parameter is mandatory when the new IAM plane is connected. This parameter is optional when the old IAM plane is connected. Value range: N/A Default value*: N/A

Response Parameters

Status code: 200

Request succeeded.

None

Example Requests

Scale in a cluster by removing specified nodes.

POST https://{Endpoint}/v1.0/{project_id}/clusters/4f3deec3-efa8-4598-bf91-560aad1377a3/node/offline

{
  "shrink_nodes" : [ "2077bdf3-b90d-412e-b460-635b9b159c11" ],
  "migrate_data" : "true"
}

Example Responses

None

Status Codes

Status Code	Description
200	Request succeeded.
400	Invalid request. Modify the request before retry.
409	The request could not be completed due to a conflict with the current state of the resource. The resource that the client attempts to create already exists, or the update request fails to be processed because of a conflict.
412	The server did not meet one of the preconditions contained in the request.