TiDB 4.0 升级 5.0 二三事——注意事项

作者：mydb​

靳献旗 ｜ 汽车之家 DBA      

1.背景

TiDB 5.0 版本 GA 到目前已经有一年时间，在稳定性、易用性、性能提升等各个方面都做了很大改进和提升，例如：

• 支持列类型的在线变更 在 4.0 版本，某些列类型无法在线变更，例如业务需要修改 decimal 类型，虽然可以通过添加新列、将旧列数据更新到新列、重命名旧列、将新列重命名为旧列的变通方式完成，但是这种方式不仅适用场景有限而且耗时较长。而 5.0 版本开始支持 decimal 类型在线变更，大大提高了业务开发的灵活度。
• 在 LVS FULL NAT 模式下获取客户端 IP 公司 TiDB 集群前端负载均衡器使用的是 LVS，FULL NAT 模式， 这种模式存在的一个问题是：RealServer 无法获得用户 IP ，即在 TiDB 数据库中无法显示客户端真实 IP，显示的是 LVS 服务器上的一个 IP。很多时候，在排查 TiDB 问题时，需要获取客户端真实 IP，这给我们带来了一定困难。TiDB 5.0 引入了参数 enable-tcp4-only，开启此配置后，在 TiDB 数据库中可以显示客户端真实 IP，对排查问题有很大帮助。
• MPP 架构 TiDB 5.0 通过 TiFlash 节点引入了 MPP 架构，大幅加速聚合查询性能。
• 不可见索引 TiDB 5.0 引入不可见索引，可以帮助 DBA 提升调优 SQL 的效率及手段

以上只是众多特性中的一小部分内容，但是这些特性确实是业务和运维需要的，因此我们计划今年逐步将线上集群升级到 5.0 版本。在升级的过程中遇到一些问题和注意事项，这里记录一下。

2.配置参数

升级步骤及注意事项可以参考 asktug 上的 【4.0 线上集群升级 5.0】SOP 手册，文末给出了链接，内容很详细。本节列一下我们从 4.0.9 升级到 5.1.4 新增的一些配置参数，仅供参考：

server_configs:
  tidb:
    enable-tcp4-only: true                        # LVS模式下查看客户端真实IP
    mem-quota-query: xxxxxx                       # 限制单条SQL最大使用的内存
    oom-action: cancel                            # SQL超过最大内存取消执行
    performance.feedback-probability: 0.0         # 显示设置为0
    tikv-client.copr-cache.capacity-mb: 10000.0   # 缓存的总数据量大小
  tikv:
    gc.enable-compaction-filter: true             # GC新特性
    rocksdb.rate-limiter-auto-tuned: true         # 依据最近的负载量自动优化RocksDB的compaction rate limiter      

这里对一些参数做一下说明： mem-quota-query：这个参数在 4.0.9 版本上不好用，当一个 SQL 消耗内存达到 10G 时，慢日志中记录的内存并不是 10G，可能是一个很小的值，因此也导致这个参数即使配置了也无法生效，在 5.0 版本上测试是没问题的。

feedback-probability：建议将这个参数显示的配置到集群拓扑文件中，尤其是从低版本一路升级过来的集群，下文会提到关于这个参数遇到的一个小问题。

3.注意事项

截止目前，我们已经将生产环境中的四套 TiDB 集群从 4.0 版本升级到了 5.1.4 版本(后续会逐步升级其它集群)，本节主要回顾一下升级期间遇到一些问题和注意事项，需要大家注意。

3.1哈希分区表性能问题

这个问题比较严重，如果线上集群有哈希分区表，要从 4.0 版本升级到 5.0 版本，需要特别注意，否则可能造成故障，下面简要讲述下遇到的问题。

线上一套 4.0.9 的 TiDB 集群，升级时间是 14:00 ~ 14:35 ，升级完毕后，DBA 在 14:39 观察到集群 SQL 99 Duration 大幅升高，紧接着，业务在 14:42 反馈接口挂了。

DBA 开始分析基础监控，分析慢日志，发现慢日志里 TOP 3 的 SQL 全部来自于一张有 256 个哈希分区的表，而且这些 SQL 都使用了 force index ，所以理论上不存在走错索引的情况，SQL 类似如下

SELECT xx,xx,xx FROM club_bbs_all_256partion force index(idx_club_bbs_id_biz_id) WHERE  club_bbs_id= 442 and  club_delete_flag = 0 and  is_publish = 1  order by biz_id desc limit  0,50\G
SELECT xx,xx,xx FROM club_bbs_all_256partion force index(idx_club_bbs_id_post_date) WHERE  club_bbs_id= 65 and  club_delete_flag = 0 and  is_publish = 1  order by club_topic_lastPostDate desc limit  20,20\G      

为了尽快恢复业务，DBA 和业务方沟通后，业务方将这个哈希表相关的 SQL 全部切回到了 ES ，之后 TiDB 集群恢复正常。 事后，我们复盘了一下问题，应该是 5.1.4 的哈希分区表的 Bug 导致的问题。

我们将出问题的那张哈希分区表和数据分别导入 4.0.9 和 5.1.4 进行测试，发现相同 SQL 在 5.1.4 版本上的性能和稳定性远不如 4.0.9 版本，同一个 SQL 在 5.1.4 上有时耗时 1 秒多，有时耗时 0.01 秒，交替频道出现，即使手动刚收集完统计信息，也会出现这种问题。

我们目前的解决办法是，将这个集群上的所有哈希分区表(幸好不多，只有几个)改造为普通表，之后再上线，没出过类似问题。

3.2feedback-probability 问题

线上有一套集群是从 3.0 版本一路升级到 5.1.4 的(2021 年从 3.0 升级到 4.0 , 2022 年从 4.0 升级到 5.1.4)，当天升级完毕后集群运行正常，第二天上午 7:00~10:00 点之间业务反馈接口抖动，同时观察到 TiDB 集群的 SQL 99 在相同时间段内也有抖动。但是分析 TiDB 集群，没发现什么异常信息。

最后检查到 feedback-probability 参数竟然是 0.05，虽然这个参数在 5.0 版本默认是关闭的，但是由于集群是一路从 3.0 升级过来的，所以如果不显示配置到集群拓扑文件中，这个配置还是 3.0 版本的 0.05 ，这里需要注意一下。官方文档建议关闭这个特性，即设置为 0 。

将 feedback-probability=0 配置到集群拓扑文件中，滚动重启 TiDB Server 节点后，再没出现过类似的抖动现象。

下面是集群出现问题时，TiDB SQL 99 监控和业务 TP 99 监控截图，可以看出抖动一致。

-1651643484687.png>)

3.3write stall 日志问题

这里为什么要特意提一下 write stall 日志的事情，其实这个是一个注意事项，不是问题。

write stall 在 5.0 版本不仅日志文件名发生了变化，连日志所在目录也发生了变化，如果在 5.0 上遇到了 write stall 问题后还是按照 4.0 的分析步骤去分析，可能会被带偏方向，延长了排查问题的时间。

因为我自己就在生产环境中遇到过这个问题，线上一套集群从 4.0.9 升级到 5.1.4 后，过了一个月发生了 write stall 问题，从监控上已经得知了 write stall 的原因，当分析日志去辅助验证时，发现搜不到 Stalling 关键字了，更奇怪的是，LOG 日志最新的内容是升级当天的时间，然后就没日志了。不禁奇怪：为什么升级之后 LOG 这个日志文件就没日志了？是升级导致的问题吗？是某些日志参数默认值发生了变化导致的问题吗？还是其它原因？

以上都不是，可能是日志这块更规范化了，日志文件名和位置都发生了变化，具体如下：

TiDB 4.0 write stall 日志文件名和位置
/data3/tikv20173/data/raft/LOG
TiDB 5.1 write stall 日志文件名和位置
/data3/tikv20173/data/rocksdb.info      

4.总结

新版本的新特性能很好地解决实际业务中的问题，但是版本升级本身存在一定的风险，因此我们和业务方要提前做好沟通、测试、回滚方案等，尽量避免升级操作影响业务或者将业务影响降到最低。