一次莽撞的 TiDB 升级故障复盘

原文来源：https://tidb.net/blog/aa848c00

本文作者：@lemontree8801

故障描述

• 最近在做 TiDB 集群的版本升级，打算先从测试环境升级开始。

• 有一个测试集群 A ，版本 v4.0.16，打算升级到 v7.1.4。

• 之前测试环境几个集群升级均很顺利，采用了 v4.x->v5.x->v6.x->v7.x 的这种升级路线，看官方文档上说可以直接 v4.x->v7.x，准备尝试下。

• 这个集群上有 drainer 组件。

• 先按文档检查了下 DDL 任务，检查了有无备份、还原任务在进行，检查了所有 region 的状态是否为 health ，均正常。

• 第一次升级 v7.1.4，pd、tikv、pump、tidb 组件均升级成功，升级至 drainer 的时候，提示 2 分钟超时 ，drainer 无法正常被重启。登陆 drainer 服务器，查看日志，提示向 pd 获取 TSO 获取失败。

• 当时没过脑子，直接执行了从 v4.0.16 升级至 v5.4.3 的操作，pd、tikv、pump、tidb 组件均升级成功，升级 drainer 仍然失败。

• 反应过来应该是 drainer 组件的问题，下掉 drainer 组件，尝试升级 v7.1.4，结果提示有 2 个 raft 目录。（因为 v7 版本 tikv 组件 data 目录下，raft 目录改名为了 raft-engine ），直接一个 tikv 节点 disconnect。

• 登陆 tidb 节点，查询数据时偶尔会报 Unknown resource group ‘default’。asktug 上搜索相关报错，提示这个与 v7 的 resource control 功能相关。

• 重新扩了一个 v4.0.16 版本的 tidb 节点，登陆查看，无异常。（重要！！）

• 想尝试扩容 v4.0.16 版本的 tikv 节点，下线老 tikv 节点，通过 rebalance 的方式看能否把数据迁移到 v4.0.16 的节点上。结果扩容的 tikv 节点直接无法启动，日志提示获取 pd 的信息应该是 v4.0.16 的，但是 pd 中相关信息版本为 v7.1.4。

故障修复

• 为避免之后集群无法迁移或者扩容，决定新建一个 v7.1.4 的 TiDB 集群，导入导出的方式把数据迁移过去，过程中的数据默认有损丢失。

• 用 dumpling 导出（v4.0.16 版本的 tidb 节点），tidb-lightning 导入。过程中遇到以下报错：

1. latin1_swedish_ci 在新版本中不支持。

2. max key length is 3072 bytes。

3. tidb-lighting 导入数据时，会去查询 min id 和 max id ，如果 min id 为负值，程序直接退出。

• 对报错 2，tidb 节点调整配置 max-index-length=12288 可以解决。

• 对报错 3，与业务沟通，修改脏数据解决。

• 对报错 1，无解 =。=。

事后总结

• 第一次遇到升级失败时，正确的解法现在回想，应该为登陆 drainer 服务器，查看 savepoint 位点，下线 drainer 组件。升级完成后，重新扩容 drainer 节点，扩容时指定 savepoint 位点信息。

• 因为之前升级都是 v4->v5->v6-v7 路线升级，有以往成功经验，以为可以正常升级至 v5 ，结果因目录发生变化，导致升级失败，进而后续花更多精力修复问题。没有 case by case 的对待升级问题。

• 重新搭建了一个 v4.0.16 的集群，将 latin1_swedish_ci 报错的 schema 导入到这个集群中，然后升级 v7.1.4 ，升级成功，登陆查看，校验规则也为 latin1_swedish_ci，😑