1
1
2
0
专栏/.../

TiDB 版本升级常见问题处理(v6.0 及以上版本)

 Jasper  发表于  2024-04-17

背景

   本文梳理了一些在版本升级过程中经常遇到的问题,以及对应的相关原理和解决方式,主要针对低版本升级到 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 恢复

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

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

总结与建议

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

1
1
2
0

版权声明:本文为 TiDB 社区用户原创文章,遵循 CC BY-NC-SA 4.0 版权协议,转载请附上原文出处链接和本声明。

评论
暂无评论