Decommissioning and Recommissioning an MRS Role Instance

Updated on 2024-09-23 GMT+08:00

View PDF

Data in an MRS cluster can be spread out over multiple Core nodes. If one of these nodes fails, it can destabilize the entire cluster. To prevent this, you can decommission a specific role instance on MRS, which will halt its service provision.

After fault rectification, you can recommission the role instance.

The following role instances can be decommissioned or recommissioned:

DataNode role instance on HDFS
NodeManager role instance on YARN
RegionServer role instance on HBase
ClickHouseServer role instance of ClickHouse (supported in MRS 3.1.2 or later)
IoTDBServer role instance of IoTDB
Broker role instance on Kafka

Constraints

If a role instance is out of service, you must recommission the instance to start it before using it again.
For details about ClickHouseServer instance decommissioning restrictions, see Constraints on ClickHouseServer Scale-in.
By default, if the number of the DataNodes is less than or equal to that of HDFS replicas, decommissioning cannot be performed. If there are only three HDFS replicas and less than four DataNodes in the system, decommissioning cannot be carried out. In such a scenario, an error will be reported, and Manager will exit the decommissioning process 30 minutes after attempting to perform it.
During MapReduce task execution, files with 10 replicas are generated. Therefore, if the number of DataNode instances is less than 10, decommissioning cannot be performed.
If the number of DataNode racks (the number of racks is determined by the number of racks configured for each DataNode) is greater than 1 before the decommissioning, and after some DataNodes are decommissioned, that of the remaining DataNodes changes to 1, the decommissioning will fail. Therefore, before decommissioning DataNode instances, you need to evaluate the impact of decommissioning on the number of racks to adjust the DataNodes to be decommissioned.
If multiple DataNodes are decommissioned at the same time, and each of them stores a large volume of data, the DataNodes may fail to be decommissioned due to timeout. To avoid this problem, it is recommended that one DataNode be decommissioned each time and multiple decommissioning operations be performed.
If the number of IoTDBServers is less than or equal to the number of region copies configured for the cluster (3 by default), decommissioning cannot be performed.

Prerequisites

The IAM users have been synchronized in advance. You can do this by clicking Synchronize next to IAM User Sync on the Dashboard page of the cluster details.
You have logged in to MRS Manager. For how to log in, see Accessing MRS Manager.
If the DataNode is to be decommissioned, perform the following steps to perform a health check before decommissioning:
1. Log in to the client installation node as a client user and switch to the client installation directory.
2. For a security cluster, use user hdfs for permission authentication.
```
source bigdata_env               #Configure client environment variables.
kinit hdfs                       #Configure kinit authentication.
Password for hdfs@HADOOP.COM:    #Enter the login password of user hdfs.
```
3. Run the hdfs fsck / -list-corruptfileblocks command, and check the returned result.
  - If "has 0 CORRUPT files" is displayed, the health check is successful.
  - If the command output does not contain "has 0 CORRUPT files" and the name of the damaged file is returned, perform the following operations to delete the damaged file:
    hdfs dfs -rm Name of the damaged file
    NOTE:
    
    Deleting a file is a high-risk operation. Ensure that the files are no longer needed before performing this operation.

Decommissioning or Recommissioning an Instance on the Console

Log in to the MRS console.
On the Active Clusters page, select a running cluster and click its name to switch to the cluster details page.
On the MRS cluster details page, click Components.
Click a service in the service list.
Click the Instances tab.
Select an instance.
Choose More > Decommission or Recommission to perform the corresponding operation.

Figure 1 Decommissioning an instance

NOTE:

During the instance decommissioning, if the service corresponding to the instance is restarted in the cluster using another browser, MRS displays a message indicating that the instance decommissioning is stopped, but the Operating Status of the instance is displayed as Started. In this case, the instance has been decommissioned on the background. You need to decommission the instance again to synchronize the operating status.

Decommissioning or Recommissioning Instances on Manager

Log in to Manager and go to the page of the component instance to be operated.
- MRS 3.x and later versions: Choose Cluster > Services, click the specified service name on the Services page, and click Instances.
- MRS 2.x and earlier versions: Click Services, click the specified service name in the service list, and click Instances.
Select the specified role instance to be decommissioned.
Select Decommission or Recommission from the More drop-down list.

In the displayed dialog box, enter the password of the current login user and click OK.

Select the operation impact and click OK to perform the corresponding operation.
NOTE:

During the instance decommissioning, if the service corresponding to the instance is restarted in the cluster using another browser, MRS displays a message indicating that the instance decommissioning is stopped, but the Operating Status of the instance is displayed as Started. In this case, the instance has been decommissioned on the background. You need to decommission the instance again to synchronize the operating status.