可以但是没必要，如果确实要部署，只需要设置不同的集群名称、目录位置、组件端口应该就可以了
1 个赞
这个问题不会有，会另外起几台新的机器
现在最稳定的版本是哪个？
只要是服务器性能够支撑，部署在一个环境没问题的
打算从6.4升到7.1，最稳定的这个还真不是很清楚，看了下文档，7.1.0是长期支持版
现在应该是v6.5.5最稳定
1 个赞
如果是在不同机器上，那可以直接部署就行啊
7.1版本好像也挺稳定
应该会影响，最好停下dm，cdc在操作
仅稳定性上来说，v6.5.5大概率是比v7.1.0稳定的。因为v6.5.5已经迭代了5个版本，v7.1.2才迭代了2个版本。
TiDB 版本的命名方式为
X.Y.Z。X.Y代表一个版本系列。
- 从 TiDB 1.0 起，
X每年依次递增，X 的递增代表引入新的功能和改进。Y从 0 开始依次递增，Y 的递增代表引入新的功能和改进。- 一个版本系列首次发版时
Z默认为 0，后续发补丁版本时Z从 1 开始依次递增。
1 个赞
和上面大佬提到的一样，可以操作但是没必要。
你会提出这个操作方案，说明集群的数据量规模以及访问量应该不会特别大，见过几十TB甚至上百TB的集群原地升级过好几个版本的，没出现过说升级失败的问题。最多说在升级的过程出现权限、配置等情况，一般都可以当场解决和处理。TiDB是的升级操作是轮转节点滚动升级的，可以运行短期不同节点的版本有差异，这段时间足够修复遇到的问题，而且这样操作对业务访问的稳定性、以及运维的操作复杂度都可以大大减少。
同一台机器混部两套集群，容易出现资源挤兑等问题，如果能申请到新机器部署，推荐使用主从同步再切换升级的方案。不然，更推荐直接原地升级集群。
这样部署没有意义吧
仅做迁移升级啦,不过迁移后来发现还有好多自定义的组件如果这么搞会很麻烦，监控也要重新部署，数据同步也会中断，如果这么搞还得在研究研究
不能光从迭代数量来判断稳定性吧，既然升级了，肯定是解决了一些之前的问题或者加入了新的功能，版本越高一般意味着功能升级或者性能的提高
z的迭代只会处理问题，不会同步需求和新功能，所以迭代越多越稳定。
当然这也是概率问题，开发质量高的只需要迭代一两个版本就会稳定。
1 个赞
看视省事，后续麻烦不断。
够用就行