TiDB 集群升级到8.5.0踩坑记：从 GLIBC_2.15 升级到 GLIBC_2.28YUM 仓库问题的全面解决

1. 引言

作为部门的负责人，我常常觉得自己是个“救火队员”。昨天 TiDB 集群又出问题了：查询卡顿、响应时间变长，重启之后问题依旧。临近下班，来这一手，全面检查无果之后，决定对 TiDB 集群进行升级。然而，升级的过程就像打怪升级一样，一关接着一关，从 GLIBC 升级到 YUM 仓库问题，简直是“运维人的九九八十一难”！

这篇文章将记录我从发现问题到解决问题的全过程，顺便吐槽一下运维服务器的辛酸。

2. 问题描述

2.1 TiDB 集群性能问题

TIDB集群一致很稳定，但是昨天，查询突然变慢，内存、CPU显示都正常。简单的查询甚至超时。查看集群后台的状态，发现大量的SQL处在查询状态，无法杀死也无法查出结果，我尝试重启集群，但问题依旧。于是，我决定升级 TiDB 集群，希望能通过新版本修复问题。

2.2 升级依赖问题

然而，升级 TiDB 集群并不是一件简单的事情。首先，服务器上的核心组件（如 make、gcc、glibc-2.28）需要升级。结果，升级这些组件的过程中，又遇到了 YUM 仓库的各种报错，简直是“一波未平，一波又起”！

TIDB集群升级到8.5.0之后，需要依赖GLIBC_2.28版本，不升级则会一致启动失败。

2.3 YUM 仓库报错

在升级过程中，YUM 仓库频繁报错，导致无法正常下载和安装软件包。每次报错都让我心头一紧，仿佛在玩“扫雷”游戏，不知道下一步会踩到什么坑。

3. 报错详情

以下是升级过程中遇到的主要报错信息：

1. /lib64/libc.so.6: version 'GLIBC_2.28' not found

   • 这个错误告诉我，系统缺少 GLIBC 2.28 版本，而 TiDB 依赖的库需要这个版本才能正常运行。

2. These critical programs are missing or too old: compiler

   • 这个错误表明，编译器 gcc、make版本过低或缺失，无法满足升级需求。我升级的是make-4.3，gcc-8.3.1

3. Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os&infra=stock error was 14: curl#6 - "Could not resolve host: mirrorlist.centos.org; 未知的错误"

   • YUM 无法从 CentOS 官方镜像源获取仓库列表，可能是网络问题或镜像源不可用。

4. failure: repodata/repomd.xml from kubernetes: [Errno 256] No more mirrors to try.

   • YUM 无法从 Kubernetes 仓库下载元数据文件，可能是仓库地址失效或网络问题。

5. http://mirrors.aliyun.com/mongodb/yum/redhat/7Server/mongodb-org/6.0/x86_64/repodata/primary.xml.gz: [Errno 14] curl#63 - "Callback aborted"

   • YUM 在下载 MongoDB 仓库的元数据文件时失败

4. 问题分析

4.1 GLIBC 版本过低

TiDB 集群依赖的库需要 GLIBC 2.28 版本，而服务器上的 GLIBC 版本过低，导致无法正常运行。

4.2 编译器版本过低

升级 GLIBC 需要较新的编译器（如 gcc），而服务器上的 gcc 版本过低，无法满足编译需求。

4.3 YUM 仓库问题

YUM 仓库报错的主要原因是镜像源不可用或网络问题。CentOS 官方镜像源和阿里云镜像源都可能出现临时不可用的情况。

5. 解决方案

5.1 升级 GLIBC 2.28

GLIBC 是 Linux 系统的核心库，升级它需要谨慎操作。我通过下载源码并编译的方式完成了升级。
升级2.28版本的文章

5.2 升级 gcc 和 make

为了编译 GLIBC，我需要升级 gcc 和 make。通过安装 devtoolset，我成功获取了较新的 gcc 版本。
升级make的文章

5.3 解决 YUM 仓库报错

YUM 仓库报错的问题通过更换镜像源和清理缓存得以解决。我使用了阿里云的镜像源，并手动清理了 YUM 缓存。
解决yum makecache报错问题

5.4 解决 mongodb-org "Callback aborted"仓库报错

打开 MongoDB 仓库配置文件（如 /etc/yum.repos.d/mongodb-**.repo）。

确保 enabled 参数的值为 0 或 1，并删除多余的注释或字符。

6. 总结与建议

这次 TiDB 集群升级的过程让我深刻体会到运维工作的不易。从 GLIBC 升级到 YUM 仓库问题，每一步都充满了挑战。然而，正是这些挑战让我不断学习和成长。

如果你也遇到了类似的问题，不要灰心！通过仔细分析和耐心排查，问题总能解决。当然，如果你有更好的解决方案，欢迎在评论区分享！

希望这篇文章能帮助到正在踩坑的你！运维之路虽然艰辛，但每一次解决问题的成就感都是无可替代的。加油！💪