GLIBC_215__GLIBC_228YUM__0">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. 报错详情
以下是升级过程中遇到的主要报错信息：
-
/lib64/libc.so.6: version 'GLIBC_2.28' not found- 这个错误告诉我，系统缺少 GLIBC 2.28 版本，而 TiDB 依赖的库需要这个版本才能正常运行。
-
These critical programs are missing or too old: compiler- 这个错误表明，编译器
gcc、make版本过低或缺失，无法满足升级需求。我升级的是make-4.3，gcc-8.3.1
- 这个错误表明，编译器
-
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 官方镜像源获取仓库列表，可能是网络问题或镜像源不可用。
-
failure: repodata/repomd.xml from kubernetes: [Errno 256] No more mirrors to try.- YUM 无法从 Kubernetes 仓库下载元数据文件，可能是仓库地址失效或网络问题。
-
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. 问题分析
GLIBC__54">4.1 GLIBC 版本过低
TiDB 集群依赖的库需要 GLIBC 2.28 版本，而服务器上的 GLIBC 版本过低，导致无法正常运行。
4.2 编译器版本过低
升级 GLIBC 需要较新的编译器（如 gcc），而服务器上的 gcc 版本过低，无法满足编译需求。
4.3 YUM 仓库问题
YUM 仓库报错的主要原因是镜像源不可用或网络问题。CentOS 官方镜像源和阿里云镜像源都可能出现临时不可用的情况。
5. 解决方案
GLIBC_228_70">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 仓库问题，每一步都充满了挑战。然而，正是这些挑战让我不断学习和成长。
如果你也遇到了类似的问题，不要灰心！通过仔细分析和耐心排查，问题总能解决。当然，如果你有更好的解决方案，欢迎在评论区分享！
希望这篇文章能帮助到正在踩坑的你！运维之路虽然艰辛，但每一次解决问题的成就感都是无可替代的。加油！💪
