背景

   本文梳理了一些在版本升级过程中经常遇到的问题，以及对应的相关原理和解决方式，主要针对低版本升级到 v6 及以上版本。希望可以帮助大家在升级遇到问题时能够快速定位并顺利解决。

常见问题

1. 配置了 server-version 参数导致升级之后 tidb-server 无法正常启动

• 问题现象

  tiup cluster upgrade 命令在 reload tidb-server 阶段卡住，升级命令 timeout

   tiup cluster display 查看集群状态 tidb-server 是 down 状态

• 问题原理

  •  故障原因为 config 中配置了 server-version 参数。
  • 老版本没有实现 并发 DDL ，v6.5 + 是实现了并发 DDL 的版本 ，实现了并发 DDL 这个 feature 后，有一个比较大的 改动是将存储 DDL job 的位置由 meta 的 kv 改到了 `mysql.tidb_ddl_job` 这张表中。这样会造成在升级过程中新版本的 TiDB 会将升级执行的 DDL 任务写入 tidb_ddl_job 但是老版本的 tidb 的 DDL owner 无法感知有新任务的情况。为了避免这个问题，在升级代码中会检查老版本的 tidb version，如果老版本还没有引入并发 DDL，则强制会将升级执行的 DDL 任务通过老的方式写入。这段逻辑除了检测集群的 `tidb_server_version` 外，还会检查当前 DDL owner 的版本，只有确认当前 owner 版本和自己的版本（也就是最新 tidb 版本）不同时，才会使用老的方式
  • 但是如果配置文件中设置了 server-version 会覆盖编译时的配置，导致新老版本显示的 version 都是一样的（用的相同的配置文件），然后导致上面代码判断永远为 true，即永远会使用新的方式写入 job。这使得老版本上的 ddl owner 拿不到任务而使得升级的 DDL 卡住。

• 解决方式

通过 tiup cluster edit-config 删除 server-version 相关配置后重新升级即可

   操作方式可参考： tiup cluster edit-config

2. 无法正常选举 tidb-server ddl owner 导致 tidb-server 启动失败

• 问题现象

升级过程中 tidb-server 无法正常启动，tidb-server 日志中报错 ["[upgrading] get owner op failed"]

• 问题原理

升级过程中同时启动 所有 tidb-server 可能会导致 ddl owner 选举失败，进而 tidb-server 无法正常启动

• 解决方式

 手动先启动一台 tidb-server ，等待 ddl owner 选举成功之后，再手动拉起其余 tidb-server

3. tolerant-size-ratio 参数异常导致 apply wait duration 升高

• 问题现象

  • apply wait duration 较升级之前有升高 ，监控位置 TiKV-details

    •     监控位置：TiKV-details - raft propose - apply wait duration per server

  • pd 监控 balance region movement 可以发现同一个store 在短时间内 in 和 out 都有值，说明出现重复调度

    •    监控位置： PD-scheduler-balance region movement

  •   例如图中 0094 的 store 发生了重复调度

• 问题原理

  老版本 tolerant-size-ratio 参数默认值为5 ，新版本该参数默认值为0， 如果是由老版本升级上来且该参数没有修改的情况 下，可能会造成重复调度，影响集群性能

• 解决方式

   通过 pd-ctl 将 tolerant-size-ratio 设置为 0

   操作方式请参考： PD Control 使用说明

   参数修改后效果：

4. 大 sql 使用 resource control 时报错： Exceeded resource group quota limitation

• 问题现象

升级之后在使用了 resource control 的情况下， 执行时间较长的大 sql 可能会报错 ERROR 8252 (HY000) : Exceeded resource group quota limitation

• 问题原理

新版本参数 ltb-max-wait-duration 默认值为 30s ，如果 SQL 请求预估消耗的 RU 超过了当前 LTB 累计的RU，则需要等 待一段时间，如果等待时间超过了默认值30s ，则会报错。

• 解决方式

对于一些突发并发增加、大事务和大查询的场景，建议增加大 ltb-max-wait-duration 减少报错的发生。

参考: PD Control 使用说明

5. new_collations_enabled_on_first_bootstrap 引起的相关问题

  从 v6.0.0 开始，TiDB 默认开启新 Collation 规则，new_collations_enabled_on_first_bootstrap 配置项的默认值由 false 改为 true。此配置，只对新建集群生效。已存在集群无法通过变更此配置项打开或关闭新的 collation 框架，原地升级上来的集群此配置项维持不变。可以通过 select * from mysql.tidb where VARIABLE_NAME="new_collation_enabled" 来确认是否启用了新排序规则框架。

  不同集群此参数不同可能会导致兼容性问题，主要注意以下几点：

1. BR 异地恢复如果上下游参数不同会报错， workaround 是在下游提前创建好对应的 schema 再进行 br 恢复

   更多请参考：备份与恢复常见问题

2. lightning precheck 阶段可能会报错，需要对数据手动处理才可以进行导入
3. ticdc 注意需要开启 enable-old-value=true ，否则可能会出现非预期的报错。

总结与建议

1. 本文中提到的一些问题已在新版本中修复，建议集群升级目标版本选择 LTS 的最新小版本， 同时正式升级之前将 tiup 工具升级至最新版本， 可以有效减少遇到问题的可能性。
2. 升级之前提前配置好新版本相关的配置参数，避免升级过程中因为参数配置问题导致升级失败。
3. 建议升级之前保留好性能基线数据，升级之后对重点性能指标进行比对，如有性能问题可以及时发现。