场景: 目前我们的业务直接使用 社区版 tikv 的事务api, 客户端是 github.com/tikv/client-go/v2. 事务逻辑包含了一组 key 的 get 然后 set (因此假如 tikv 检测到冲突就会有事务失败的可能)
版本: 正在打算从 tikv 4.0.5 版本升级到 5.2.1,
部署方式: 使用 docker 部署, 没有使用 tiup管理.
由于网络上直接使用 tikv 的用户很少, 也没有搜到正规的升级流程的文档, 所以我们简单地做了 rolling restart (一个节点重启完, pd-ctl 查询到该节点 up, 再等 10秒就做下一个). 在实施过程中 部分 tikv 事务会因为冲突错误而失败. 可以通过日志确认该事务没有并发执行(不可能逻辑冲突).
附件是错误的相关日志截图
想请教下有没有优雅一点的办法能够减少或者避免这类情况的出现. 谢谢
轮转操作一个个节点升级的思路是对的，如果想要更加优雅升级，不让业务有感知，可以考虑先驱逐节点上的leader ，等没有leader 了再升级它。
这样操作对业务是透明的，业务不受影响，缺点是得每个节点都先驱逐leader ，后升级，再允许leader迁移回来，操作繁琐且耗时较久。
如果有tiup操作会比较简单，如果没有，就得手工去调整tipd 的调度策略和升级。
请问一下驱逐leader这样的工作能否通过 pd-ctl / tikv-ctl 来完成? 如果没有命令的话否有编程调用的参考?
有的，参考这儿
scheduler add grant-leader-scheduler 1 // 把 store 1 上的所有 Region 的 leader 调度到 store 1
scheduler add evict-leader-scheduler 1 // 把 store 1 上的所有 Region 的 leader 从 store 1 调度出去
谢谢 
有的，可以看上面大佬贴的链接。
还有，操作的时候有任何问题可以在论坛提问
可以试试
不是可以使用tiup直接升级吗？
他的环境 没有使用 tiup管理
先驱离leader 然后再升级呀
滚动升级
