当tiup mirror show的时候，显示是6.1.2,tiup 版本是6.1.2自带的版本1.11.0,然后去启动v5和v4集群的prometheus组件的时候，就会启动失败，但是当tiup mirror set v5.3.3后，去启动v5和v4集群的prometheus组件的时候就可以成功
因为之前认为 tiup 去启停组件的时候，应该和mirror set 或者是说和集群版本是没有耦合的关系?但是到了6.1后，这个逻辑是变了，不知道这样设计的目的是什么
会不会是版本兼容性问题？
具体失败报错信息贴一下
tiup merge 下源试试
merge的话肯定可以的，但就是好奇为啥不merge不行
可能到了6.1，有了版本兼容验证
我觉得很合理
报错就是
version 4.0.13 on linux/amd64 for component drainer not found: unknown version: check config failed
tiup 在reload时会默认 check config，check config 因为一些历史原因会去 mirror 中 check 版本号等相关信息，在 mirror 找不到对应版本时会报错。
大佬，这个能详细说下嘛，
但是仅仅去重启1个节点而已，为什么要有版本兼容验证呢？按照实际使用情况来看，以前没有这样的验证？6.1 增加这样的验证又是为什么呢？
我觉得这是现象，用5.3.3的mirror 去重启tidb 4.0.x集群的prometheus组件就不会报错，但是
6.1.2的mirror 去重启tidb 4.0.x集群的prometheus组件就会报错，说明到了6.1后，这个机制发生了改变
tiup 版本不一样吧，这玩意看 tiup 这个工具的逻辑的。
tiup reload 的逻辑，应该是会 check 版本和配置。这个很合理。
举个🌰：
我对一个 tidb server 节点打个补丁。如果 reload 的时候发现这个版本和我的管理版本不一样，就会直接覆盖掉。除非你打补丁的时候接了 --overwrite 
。
还有就是你手动修改一个节点 toml 文件，那么 reload 的时候也会讲这个节点的配置修改回来。
所以 reload 的时候校验版本和配置 很河里。
tiup reload 的逻辑，应该是会 check 版本和配置。这个很合理。
如果是安装 部署 升级 打补丁，我觉得这个很合理，但是如果是仅仅是去重启1个节点也做配置的话，是不是没有必要呢
，所以你用的 restart 还是 reload？
reload 的原理和restart 差不多吧，除了下发1份配置文件以外
reload 的逻辑复杂多了。
