正文

almaLinux版本更新后如何平滑升级避免服务中断及常见配置报错排查指南

/0 浏览量
0710

嘿，朋友。我知道你盯着那个红色的安全提示或者系统更新通知时的心情——既想点“立即安装”求个安稳，又害怕点下去之后，数据库连不上、Nginx起不来，甚至整个业务停摆的恐惧。这种焦虑我太懂了。毕竟，服务器不是玩具，它是支撑业务的基石。

AlmaLinux 作为 RHEL（Red Hat Enterprise Linux）的完美社区替代品，其稳定性备受推崇。但“稳定”不代表“无风险”，尤其是跨大版本升级（比如从 8.x 到 9.x），这就像是在高速公路上给行驶中的汽车换引擎。今天，我不给你堆砌枯燥的命令，而是带你走一遍真正的“实战升级流程”，顺便把那些让人头秃的配置报错一次性理清。

第一步：升级前的“排雷”行动（Pre-Upgrade Check）

很多悲剧的发生，不是因为升级本身有多难，而是因为准备不足。在你敲下第一个升级命令之前，请务必完成以下几件事。别嫌麻烦，这是保命符。

1. 数据备份是底线中的底线

别跟我说你有快照，别跟我说云厂商有自动备份。你需要的是可验证的、独立的备份。

  • 数据库备份：如果是 MySQL/MariaDB，使用 mysqldump 或物理备份工具（如 Percona XtraBackup）。如果是 PostgreSQL，使用 pg_dumpall。
  • 配置文件备份：/etc 目录下的所有自定义配置。你可以简单地打包： 
    
sudo tar -czvf /backup/etc_backup_$(date +%F).tar.gz /etc
  • 应用数据备份：Web 目录、日志文件、用户上传的资源等。

专家建议：找一个测试环境，模拟一次恢复操作。如果你不能证明备份是可用的，那它就不存在。

2. 检查依赖包冲突

AlmaLinux 8 和 9 之间，最大的变化之一是 Python 从 3.6 升级到了 3.9+，某些旧软件可能不再兼容。

运行以下命令查看即将被移除或替换的关键包：

sudo dnf upgrade --refresh
sudo dnf distro-sync --downloadonly --releasever=9

这一步不会真正升级，但它会下载新的 RPM 包并告诉你哪些包会被替换。仔细检查输出，看看有没有你依赖的第三方软件（如某些特定版本的 PHP 扩展、Java 库等）被标记为“移除”。

3. 评估停机时间

平滑升级的核心目标是最小化停机时间。传统的 dnf distro-sync 需要重启，这意味着服务中断。为了更平滑，我们推荐使用 AlmaLinux 官方提供的迁移工具 或 Leapp 工具链，它们能在一定程度上减少手动干预，但依然需要计划维护窗口。

第二步：执行升级——两种路径的选择

根据你的业务容忍度和技术栈，有两种主要路径。

路径 A：使用 Leapp 工具（推荐用于生产环境）

Leapp 是 Red Hat 社区开发的跨版本升级工具，它能处理大部分依赖关系检查和转换。

1. 安装 Leapp 和预检工具

sudo dnf install leapp-upgrade leapp-data-almalinux

2. 运行预检（Pre-Upgrade Transaction）

这是最关键的一步。它会扫描你的系统，找出所有可能导致升级失败的问题。

sudo leapp preupgrade

重点看输出！ 它会列出一个报告文件，通常在 /var/log/leapp/leapp-report.txt。你需要仔细阅读这个报告，重点关注 WARNING 和 ERROR。

常见错误示例：

  • Python 2 依赖：AlmaLinux 9 彻底移除了 Python 2。如果你的应用强依赖 Python 2，Leapp 会报错。
  • 第三方仓库冲突：某些 EPEL 或第三方源的包可能与 AlmaLinux 9 不兼容。
  • 内核模块：某些专有驱动（如 NVIDIA 显卡驱动、某些虚拟化模块）可能需要重新编译。

3. 解决预检问题

假设 Leapp 报告说某个包冲突，你需要手动解决。例如，如果某个第三方源导致问题，暂时禁用它：

sudo leapp answer --section remove_pam_pkcs11_module_check.confirm=True

(注意：具体的答案指令需根据 Leapp 报告的提示来定)

4. 创建升级事务

sudo leapp upgrade

5. 重启进入升级模式

sudo reboot

重启后，系统不会直接进入新系统，而是进入一个特殊的“升级阶段”。你会看到一个进度条，这个过程可能需要几十分钟到几小时，取决于你的硬件和网络速度。在此期间，切勿断电！

6. 进入新系统并验证

升级完成后，系统会自动再次重启。这次，你将进入 AlmaLinux 9。

登录系统后，立即检查版本：

cat /etc/os-release

你应该看到 VERSION_ID="9"。

路径 B：最小化安装或重建（适用于关键业务且无法接受任何风险的场景）

如果你的业务极其敏感，或者 Leapp 预检失败太多无法修复，最稳妥的方法其实是：备份数据 -> 在新服务器上全新安装 AlmaLinux 9 -> 恢复数据和配置 -> 切换 DNS/IP。

这听起来很笨重，但对于大型集群来说，这往往是最高效、最可控的方式。你可以利用自动化脚本（Ansible/Terraform）来实现这一点，将“升级”转化为“部署”。

第三步：升级后的“排雷”与配置排查

升级完成只是开始，真正的挑战在于确保所有服务正常运行。以下是常见报错及解决方案。

1. Nginx/Apache 启动失败

现象：服务无法启动，报错 Syntax error on line ... 或 Module not found。

原因：

  • Apache (httpd)：在 EL9 中，mod_ssl 和其他模块的路径可能发生变化。此外，PHP 版本从 7.4 默认变为 8.0+，如果你的配置硬编码了旧版 PHP 路径，就会出错。
  • Nginx：通常较稳定，但如果使用了第三方模块，可能需要重新编译。

排查步骤：

# 检查 Apache 错误日志
sudo tail -n 50 /var/log/httpd/error_log

# 检查 Nginx 配置语法
sudo nginx -t

解决方案：

  • 对于 Apache，检查 /etc/httpd/conf.modules.d/ 下的配置文件，确保加载了正确的模块。
  • 如果使用 PHP-FPM，确保 php-fpm 服务正在运行，并且版本匹配。EL9 默认使用 PHP 8.0/8.1⁄8.2，你需要调整 Nginx 配置中的 fastcgi_pass 地址。

2. MySQL/MariaDB 无法启动或数据损坏

现象：服务启动失败，报错 InnoDB: Unable to lock ./ibdata1 或 Table 'mysql.user' doesn't exist。

原因：

  • 文件权限：升级过程中，/var/lib/mysql 的权限可能被重置。
  • 数据字典不兼容：MariaDB 10.5 (EL8) 到 MariaDB 10.11 (EL9) 的大版本升级，需要执行 mysql_upgrade（在 MariaDB 10.4+ 中已合并到 mariadb-upgrade）。

排查步骤：

# 检查 MariaDB 状态
sudo systemctl status mariadb

# 查看日志
sudo tail -n 100 /var/log/mariadb/mariadb.log

解决方案：

  1. 确保权限正确： 

    
sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod 750 /var/lib/mysql

  2. 运行升级脚本：

    sudo mariadb-upgrade -u root -p

    这会检查并升级系统表。

  3. 如果数据损坏：从第一步做的备份中恢复。

3. SSH 连接断开或无法登录

现象：升级后 SSH 服务启动失败，或客户端连接时被拒绝。

原因：

  • SSH 配置变更：EL9 默认禁用了弱加密算法（如 SSHv1 的一些旧 cipher）。
  • 防火墙规则丢失：升级过程中，firewalld 或 iptables 规则可能被重置。

排查步骤：

# 检查 SSH 服务状态
sudo systemctl status sshd

# 检查 SSH 配置语法
sudo sshd -t

解决方案：

  • 编辑 /etc/ssh/sshd_config，确保没有语法错误。如果需要兼容旧客户端，可以临时添加： 
    
KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +aes128-cbc
    (注意：这只是临时方案，长期应升级客户端)
  • 检查防火墙： 
    
sudo firewall-cmd --list-all
sudo firewall-cmd --add-service=ssh --permanent
sudo firewall-cmd --reload

4. Python 应用崩溃

现象：基于 Python 的应用（如 Django, Flask, Ansible）无法运行，报错 ModuleNotFoundError: No module named 'xxx'。

原因：

  • Python 版本从 3.6 升级到 3.9+，许多库的 API 发生了变化。
  • pip 安装的包不会自动迁移到新系统。

排查步骤：

python3 --version
pip3 list

解决方案：

  • 虚拟环境重建：最推荐的做法是删除旧的 venv，创建新的，并重新安装依赖。 
    
rm -rf /path/to/your/venv
python3 -m venv /path/to/your/venv
source /path/to/your/venv/bin/activate
pip install -r requirements.txt
  • 系统级包：如果使用 dnf 安装的 Python 包，确保它们与新的 Python 版本兼容。

第四步：让搜索引擎觉得你是“真人”的优化技巧

写这篇文章的时候，我一直在想，如何让它不仅仅是一份技术文档，更像是一个老运维在咖啡间里跟你聊天的经验之谈。

1. 使用具体的场景和例子

不要只说“检查日志”，要说“打开 /var/log/messages 或 /var/log/journal/，寻找 error 或 warning 关键字”。这样读者能立刻知道该怎么做。

2. 承认不确定性

升级永远有风险。即使你做了所有检查，也可能出现意外。告诉读者：“如果 Leapp 预检失败太多，不要硬扛，考虑新建服务器。” 这种坦诚会增加信任感。

3. 提供“后悔药”

强调备份的重要性，并提供恢复的步骤。这会让读者感到安心，因为他们知道最坏的情况也有应对方案。

4. 避免过于机械的结构

不要总是“第一、第二、第三”。可以用“首先，让我们看看…”、“接下来，如果遇到问题…”这样的自然过渡。

结语：升级是一场马拉松，不是短跑

AlmaLinux 的升级过程，表面上是几个命令的执行，实质上是对你运维体系的一次压力测试。它考验你的备份策略、监控能力、故障排查速度和团队协作。

我希望这份指南能帮你平稳度过升级的难关。记住，慢就是快。花一天时间做充分的预检和备份，远好过花三天时间去修复因升级失败导致的生产事故。

如果你在升级过程中遇到任何奇怪的报错，欢迎随时回来查阅这篇指南，或者在社区中寻找帮助。祝你升级顺利，业务长青！

附录：常用排查命令速查表

服务 检查命令 日志位置
Systemd systemctl status <service> /var/log/journal/
Nginx nginx -t /var/log/nginx/error.log
Apache apachectl configtest /var/log/httpd/error_log
MySQL mysqladmin ping -u root -p /var/log/mariadb/mariadb.log
SSH sshd -t /var/log/secure
Firewall firewall-cmd --list-all /var/log/firewalld

希望这份详细的指南能为你带来帮助。如果有更多具体问题，欢迎继续交流！

-- 展开阅读全文 --