是的，这种高风险的事情还是尽量少做，在做不到整个集群备份的情况下，起码也要将关键的数据进行备份
熬一熬，等月底6.5.4
1 个赞
在线的只能等驱离，停机的就一步到位，不需要等待。
7*24小时系统 不能停机
看来选V6 LTS多于V7
v7还要等再迭代几个小版本再上生产 
求稳6.5.3 ，要不再等等新的 7版本
我也纠结中，一年就一次大升级，我是想到V7 LTS的，但是看现在情况，还想等社区更多的生产V7体验报告。
步子不要迈的太大，6.5.3
等不及了，我们昨天一键从5.3.1升级到了6.5.3了，上百个节点的大集群升级还是挺顺利的，就是等待时间比较久
升级过后，加索引比以前快的飞起
大佬威武，是要解决什么问题要升级的？
主要是解决加索引太慢的问题。
这个是HTAP集群，业务多又杂，加索引导致别的任务阻塞情况太多了，导致加索引太慢也形成了痛点
这就已经升级完了，效率高啊
升级是在线升级还是停机升级？
直接在线升级的，不停机升级
我们使用transfer-timeout 的方式，为了避免升级时间过长，如果10分钟过去还没迁移完leader就直接升级（会有短暂的感知，提前公告给业务了），即便如此我们也花了十多个小时。
使用–force的方式比较快，但是直接粗暴，业务会有明显感知，集群在升级期间业务几乎是不可用的（或者有大量告警），除非是超大集群升级时业务允许或者有明显的低谷期才会这样用
业务会有明显感知 这里感知是sql执行失败报错了呢还是就是延迟大了
都有可能有，内部重试成功就是延迟大，重试失败就报错，当然不是访问到正在升级的节点的话延迟影响可能不大