Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 请问变更tiup的yaml文件后，如何在删除数据的情况下重启集群，并使得新配置生效
|
username: 我家有个臭皮崽
As per the topic:
Currently, I have changed a configuration in the tiup yaml file:
I adjusted the value of schedule.hot-region-cache-hits-threshold from the default value of 3 to 30. I want to know how to restart the tikv cluster and make the new configuration take effect without destroying the cluster.
I see that the tiup cluster command has edit-config and show-config. Executing show-config allows you to see the current configuration. Since it’s in a production environment, I’m hesitant to execute edit-config. I want to confirm, after using edit-config and then upgrading to the specified cluster, will it update the cluster’s configuration?
First, use tiup cluster edit-config <tidb-name>, then use tiup cluster reload <tidb-name> -R <component>(tidb, pd, etc.).
Yes, edit first then reload. It’s strange why there is an idea of deleting the database before restarting 
You misunderstood, I am worried that it will affect the data, after all, it’s online business 
Isn’t it possible to directly restart using the following command: tiup cluster restart <cluster_name>?
The functions of restart and reload are different; reload needs to load new configurations from the central control.
Yes, isn’t the blogger describing reloading the configuration?
What is the biggest difference between the two? Can’t restart also reload the configuration?
After modifying the cluster configuration, you need to use the tiup cluster reload command to reload the configuration for it to take effect. This command will publish the configuration from the control machine to the remote machines where the services are running and restart the services in order according to the upgrade process. During the restart process, the cluster remains available.
The tiup cluster restart command is used to restart all or part of the services in the specified cluster.
If you are concerned about data impact, you can reload role by role using -R or instance by instance using -N. Generally, reloading has minimal impact under multiple nodes. However, to be safe, it is best to reload during off-peak business hours.
I still don’t quite understand. It seems that both the reload and restart commands can reload the configuration, and both are rolling upgrades. Restart can also upgrade only certain components through parameters like -R, so my understanding is that there isn’t much difference.
After modifying the cluster configuration, you need to use the tiup cluster reload command to reload the configuration for it to take effect. This command will publish the configuration from the control machine to the remote machines where the services are running and restart the services in sequence according to the upgrade process. During the restart, the cluster remains available.
The tiup cluster restart command is used to restart all or part of the services in the specified cluster. During the restart, the cluster is unavailable.
The difference lies in whether the cluster is available during the restart process.
The difference is that restart will stop all nodes and then start all nodes, making the cluster unavailable, while reload will restart each node one by one, allowing the cluster to continue providing services.
You mean restart is not a rolling upgrade, but reload is a rolling upgrade, right? I just checked, and during the restart process, the cluster will indeed be temporarily unavailable, but it can also support configuring nodes.
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 