内核升级后mysql启动失败主因有四：tls初始化失败（旧版mysql不兼容新openssl）、文件系统语义变更致innodb表损坏、systemd cgroup v2不兼容、selinux策略未更新导致mysqld_safe访问受限。
MySQL 服务启动失败：内核升级后 mysqld 报 Failed to initialize TLS
内核升级（尤其是从 CentOS 7 升级到 8 或 RHEL 8+）常伴随 OpenSSL 版本跃迁，而旧版 MySQL（如 5.7.33 之前）静态链接了过时的 libssl，无法兼容新内核默认启用的 TLS 1.3 或更严的密码套件协商逻辑。
- 先验证是否为 TLS 初始化问题：
sudo journalctl -u mysqld -n 50 --no-pager | grep -i "tls\|ssl" - 临时绕过（仅用于诊断）：在
/etc/my.cnf的[mysqld]段添加ssl_mode=DISABLED，重启看是否恢复 - 根本解法不是降级 OpenSSL，而是升级 MySQL —— 官方 5.7.34+ 和 8.0.22+ 已适配 OpenSSL 1.1.1+；若必须用旧版，需手动编译并链接系统 OpenSSL，但不推荐
文件系统语义变更导致 innodb_file_per_table=ON 表损坏
较新内核（如 Linux 5.10+）对 XFS 的 inode64 和 ext4 的 large_dir 默认行为调整，可能让 MySQL 在重放 ib_logfile 时读取到被覆盖的旧 inode 数据，尤其在未关闭 innodb_fast_shutdown=1 就强制关机后迁移。
- 迁移前务必执行干净关闭：
mysql -e "SET GLOBAL innodb_fast_shutdown=0; SHUTDOWN;" - 检查当前表空间路径是否跨挂载点：
SELECT FILE_NAME FROM INFORMATION_SCHEMA.INNODB_DATAFILES;—— 若含/mnt/data/这类非根路径，需确认新内核下该挂载选项（如noatime,inode64）与旧环境一致 - 升级后首次启动加参数验证：
mysqld --innodb-checksum-algorithm=crc32 --innodb-log-checksums=ON，避免静默数据错位
systemd 服务单元文件不兼容新内核 cgroup v2
MySQL 官方 RPM 包自带的 mysqld.service 多数仍基于 cgroup v1 编写，而新版 OS（如 Ubuntu 22.04+/RHEL 9）默认启用 cgroup v2，会导致 MemoryLimit、CPUQuota 等资源限制失效，甚至因 Delegate=yes 冲突引发启动超时。
- 检查当前 cgroup 版本：
cat /proc/1/cgroup | head -1—— 若含0::/是 v2，含0::/system.slice是 v1 - 修改服务文件：
sudo systemctl edit mysqld，加入[Service]段并覆盖MemoryLimit=为MemoryMax=（v2 语法），同时移除或注释掉Delegate=yes - 若使用 Docker 或 systemd-nspawn 部署，确保容器 runtime（如 runc）已更新至支持 cgroup v2 的版本，否则 MySQL 子进程会直接被 kill
SELinux 策略未同步更新，mysqld_safe 被拒绝访问 /proc/sys/kernel/random/uuid
某些内核升级包会更新 SELinux 策略模块（如 selinux-policy-targeted），但 MySQL 相关策略（mysqld_t）未及时适配新 sysfs 接口权限，导致 mysqld_safe 启动时因无法读取随机源而卡死。
- 复现方式：
sudo ausearch -m avc -ts recent | grep mysqld，若出现avc: denied { read } for ... path="/proc/sys/kernel/random/uuid"即为此问题 - 临时修复：
sudo setsebool -P mysqld_read_proc_sys 1（需策略支持该布尔值） - 长期方案：升级
mysql-community-server至最新 minor 版，并确认配套的mysql-selinux包已安装 —— 旧版 RPM 常漏装该子包
内核升级本身不碰 MySQL 数据文件，但会悄悄改写它依赖的底层契约：TLS 握手流程、文件系统元数据语义、进程资源隔离机制、安全策略边界。最容易被忽略的是那些“没报错却读到了错误数据”的场景——比如 InnoDB 用旧 checksum 算法校验新内核写入的日志块，结果校验通过但内容已偏移。
