【 TiDB 使用环境】生产环境
【 TiDB 版本】 6.5
最近在做 DM 集群调整，需要给 Worker 所在机器升配置，我选择了先新购机器，新建充足的 free workers 之后，把数据源切过去新机器的 free workers， 再下线老的 worker 机器。但是有一个有趣的问题，worker 下线相关的命令动作，有两个地方：
tiup dmctl offlineline-member: Offlines member which has been closed
tiup dm scale-in : Scale in a DM cluster
所以我应该使用哪个？标准姿势是怎么样的？
是DM迁移到新服务器吗？那为什么要下线老的workder机器呢。直接stop不就行了。
我是直接 把老的 stop停掉。然后在新服务器上面直接创建一样的任务名，不一样也可以，文件里面写上老的DM已经同步到的binlog和pos值（ “syncerBinlog”: “(mysql-db31-bin.022017, 796479174)”,）
然后直接启动新服务器就行了。启动成功，那就直接把老服务器关进回收。
是把任务迁移到规格更高的新服务器，但是应该要有一个标准流程去下线老服务器呢。我看到就有两种，不知道用哪个
。。。。。要求这么多？直接新建一个DM服务器。把任务什么的都配置好，就等binlog文件内容那里的时候。把老服务器直接stop，直接停了不就行了。就没用了，还要去搞什么下线呢。只要新服务器DM启动成功正常同步。老服务器直接stop init 0 就是下线流程。
你是只有work服务器升级？dm manger中控不迁移升级吗？如果这样的话，还不如直接在让老work服务器关机升级启动继续使用，
要么你只能扩容新增work，然后新建一个数据源，把老的停掉，根据binlog启动新的work上面的数据源。老的服务器直接干掉卸载数据源就行。然后缩容对应的老服务器就行了。我用的是scale-in命令
使用 tiup dm scale-in 命令来下线老的 worker 节点。这是推荐的标准做法,因为它会完整地处理节点下线过程。 至于 tiup dmctl offline-member 命令,它主要用于紧急情况下手动下线已经关闭的成员节点。你所说的场景中,由于是计划内的调整,使用 tiup dm scale-in 更为合适。
感谢！你这个回答靠谱
参考你这个,还不如参考官方文档呢 
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。
