Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.Original topic: 我重新配置了TIDB DM的上游数据源source1.yaml ，我应该如何重启生效？
|
username: Hacker_7b2KWuuo
Is it effective to directly use tiup dm reload dm-test to reload the service, or should I execute some other command?
Reconfiguring the upstream data source, does it mean changing the upstream database address or modifying some content?
Hello, I have added the following parameters:
|
username: purge:
interval: 3600
expires: 3
remain-space: 15
Executing other commands works, such as tiup dmctl --master-addr master1:8261 operate-source create /tmp/source1.yml
Documentation link: 使用 TiUP 运维 DM 集群 | PingCAP 文档中心
The command tiup dm reload dm-test is used to restart the DM cluster, similar to restarting the TiCDC cluster. Based on the modifications you provided, it seems you have changed the configuration file of the upstream database, which means you want to adjust the configuration of a specific synchronization task rather than the DM cluster itself.
Therefore, you might need to know how to update the synchronization task configuration. You can refer to the official documentation at:
Use the pause-task command to pause the migration task, modify the configuration, and then use the resume-task command to resume the previous data migration task. Since this is a test environment, you can give it a try.
Brother, this is not correct. I tested it last night. You should first stop the stop-task task, then delete operate-source stop, and then recreate operate-source create, start-task. After that, the config source file will take effect.
Your method works too, and that’s what I’m doing now. However, the official documentation also provides a solution: 切换 DM-worker 与上游 MySQL 实例的连接 | PingCAP 文档中心
There should be no problem using stop task, because stop-task will directly delete your existing migration task, which carries some risks. In previous versions, I remember you could use pause to change the configuration, but I’m not sure if there have been any adjustments in the new version. Since you mentioned you are testing in a validation environment, try using the relatively gentle pause-task method first to see if it works. If it doesn’t, then use the stop-task method.
The stop-task command deletes the task, so any configuration you do afterward is equivalent to creating a new task, which is certainly feasible. However, whether there is a better way is something that should be discussed.
Here are the differences between the two:
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: pause-task only pauses the execution of the migration task but retains the task’s state information in memory, and you can query it using query-status. Using stop-task stops the execution of the migration task and removes the related information from memory, making it unqueryable via query-status, but it does not remove data already written to the downstream database or checkpoint information in dm_meta.pause-task, the task itself still exists, so you cannot start a new task with the same name, and it will prevent the cleanup of relay logs required by the task. After stopping the task using stop-task, the task no longer exists, so you can start a new task with the same name, and it will not prevent the cleanup of relay logs.pause-task is generally used for temporarily pausing migration tasks to troubleshoot issues, while stop-task is generally used for permanently deleting migration tasks or updating configuration information in conjunction with start-task.This is equivalent to a new data source. It has nothing to do with the old one, right?
There is a link from an expert above, follow the documentation and proceed.
For example, you manually compile source1.yaml
Modify
purge:
interval: 3600
expires: 11
remain-space: 15
Then you run tiup dm reload dm-test
Then you check the configuration
tiup dmctl --master-addr 127.0.0.1:8261 config source
You will find that the expires value has not changed.
You don’t need to reload the DM cluster.
To modify the configuration, you can try the following methods:
Method 1: Use stop-task to permanently delete the migration task, then use start-task to update the configuration information.
Method 2: Use the pause-task command to pause the migration task, modify the configuration, and use the resume-task command to resume the previous data migration task. You can first verify if this works in the new version; if not, use Method 1.
|
username: 
|
username: