【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
看303视频的时候，说如下处理方式，想知道如果升级到1/3的时候报错了，然后通过tiup cluster replay ，那是不是只是处理了失败的这一步的问题，而不会继续处理升级还需要做的剩余的操作？ 升级中断报错后，当报错解决了，大家是如何处理的？
升级时报错中断，处理完报错后，如何继续升级
1、查看操作记录，找到失败的升级操作记录的ID
$ tiup cluster audit
2、重试上次的升级操作记录
$ tiup cluster replay
个人历史遇到过程中断失败因为历史产生的Tombstone节点未能有效清理导致，根据报错提示清理的delete对应的 Tombstone store节点 然后 tiup cluster replay继续就好了。
如果升级pd成功了，在升级tikv的时候报错了，报错没有及时解决，可以执行什么命令回退已经升级成功的pd吗？
退不了 
我一般是处理好错误，重新升级
replay就是把你报错没升级完的操作接着执行下去
就是怕错误没找到原因，那到了时间就要回退，这个时候要怎么去回退
感谢，那如果没有解决报错，要如何回退？
升级中断报错后的处理步骤通常如下：
查看操作记录：首先，您需要查看操作记录，找到失败的升级操作记录的ID。可以使用以下命令：
$ tiup cluster audit
这一步可以帮助您确定失败的操作是哪一步，以及具体的操作ID。
重试失败的操作：使用 tiup cluster replay 命令重试失败的操作。例如：
$ tiup cluster replay <operation-id>
其中 <operation-id> 是您从上一步中获取的操作ID。
手动继续剩余的升级步骤：如果 tiup cluster replay 命令成功执行了失败的步骤，您需要手动继续执行剩余的升级步骤。这可能包括检查集群状态、执行任何必要的数据迁移或配置更改等。
好的，那看来tiup cluster replay的动作并不是只执行报错这一步的操作，而是继续从这个报错的动作继续完成升级的操作
从"tidb菜鸟一只"那边的回复是：replay就是把你报错没升级完的操作接着执行下去 噢，有时间的时候我这也故意把其中一台的ssh密钥弄失败，然后试试这个replay的操作验证下
使用 tiup cluster status 查看集群的当前状态，确认哪些节点还在升级过程中，哪些节点已经升级完成
接下来手动执行剩余步骤
参考官网： https://docs.pingcap.com/zh/tidb/stable/upgrade-tidb-using-tiup
不支持回退，只能向前 
对头，TIDB没有回头路 
升级前做好备份，如果升级失败，可以重新部署老版本集群，在把数据恢复进去，这就是变相的回退方案。
那如果要回退，只能是使用br备份进行恢复操作了？那风险是不是有点儿大，或者可以停机的话，停掉之后进行冷备了
如果数据量大，从nas恢复到本地磁盘也挺慢的，也建议先将备份恢复一次，确保备份是可用的，前期准备工作还是挺多的，还要有机器可以用来进行恢复测试
生产环境升级的时候，在测试环境验证没有问题，就直接干吗 
在以下链接看到如下内容: What’s New in TiDB 5.0 | TiDB 文档中心
TiUP v1.4.0 版本以前，DBA 使用 tiup-cluster 升级 TiDB 集群时，如果命令执行中断，那么整个升级操作都需重新开始。
新版本 TiUP 支持使用 tiup-cluster replay 子命令从断点处重试失败的操作，以避免升级中断后所有操作重新执行。
其实还是希望有命令可以直接回退回去
嗯对，我都是在内部环境验证升级逻辑没有问题了，然后找晚上低峰谷的时间，先做生产集群做快照备份，然后直接升级。
历史从5.4.2 升级到6.1.0 ；再到后来从6.1.0升级到7.5.3 都是这么干的。
但是历史遇到一个字符集大小写的问题，这个new_collations_enabled_on_first_bootstrap参数如果老的集群是false的话，升级到新版本， 虽然文档介绍说新版本默认是true，但是升级不会修改这个参数，这个参数只有在集群初始化的时候遇到。