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

2024年 5月 7日 69.0k 0

专栏/.../

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

一次莽撞的 TiDB 升级故障复盘-1 TiDB社区小助手  发表于  2024-04-25
转载版本升级

本文作者:@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,😑
0
0
1
0

声明:本文转载于 https://mp.weixin.qq.com/s/IWFMcKmjwdRD_Mmwql4bpA

评论
暂无评论
  • 1

相关文章

Oracle如何使用授予和撤销权限的语法和示例
Awesome Project: 探索 MatrixOrigin 云原生分布式数据库
下载丨66页PDF,云和恩墨技术通讯(2024年7月刊)
社区版oceanbase安装
Oracle 导出CSV工具-sqluldr2
ETL数据集成丨快速将MySQL数据迁移至Doris数据库

发布评论