从Debian 9升级到Debian 10需要注意哪些关键问题？

从 Debian 9 (Stretch) 直接升级到 Debian 10 (Buster)，这不仅仅是一个简单的 apt upgrade，而是一次涉及底层依赖库、系统初始化系统和网络管理等多个核心组件的重大版本跨越。作为在运维一线摸爬滚打多年的“老鸟”，我必须提醒你：生产环境严禁直接在线升级，必须先在测试环境验证，并配合快照或备份策略。

以下是你需要重点关注的几个关键坑点和操作细节：

1. 前置准备：数据与状态是底线

• 完整备份：这是废话，但也是最重要的话。如果可能，对整个系统进行镜像备份（如使用 Clonezilla 或 LVM snapshot）。如果是云服务器，务必先打一个系统盘快照。
• 锁定已安装软件：记录当前安装的包列表 (dpkg --get-selections > installed_packages.txt)，以便升级后检查是否有非预期变更或丢失。
• 清理仓库源：确保 /etc/apt/sources.list 中只保留官方稳定版源，移除任何第三方 PPA 或非官方仓库，这些往往不兼容 Buster 的依赖关系，会导致升级中断。

2. 核心组件变更：systemd 和 systemd-networkd

Debian 10 全面拥抱了 systemd，虽然 Debian 9 也用了，但 Buster 在配置和管理上有了显著变化。

• NetworkManager vs systemd-networkd：如果你之前使用的是传统的 /etc/network/interfaces 方式管理网络，升级后通常没问题。但如果你的服务器使用了 NetworkManager 或 systemd-networkd，需要特别注意。Debian 10 默认更倾向于使用 systemd-networkd 处理基础网络接口，而将高级功能交给 NetworkManager。建议升级前确认你的网络配置脚本是否兼容新的 systemd 单元文件。
• 开机启动项：检查自定义的 systemd service 文件。由于路径和权限模型的变化，部分旧的 init.d 脚本可能需要转换为 systemd unit 格式才能正常工作。

3. 数据库与中间件：MariaDB 和 PostgreSQL 的版本跳跃

这是最容易出问题的地方，尤其是对于运行着 MySQL/MariaDB 或 PostgreSQL 的生产服务。

• MariaDB 10.1 -> 10.3：Debian 9 默认是 MariaDB 10.1，Debian 10 是 10.3。这是一个大版本跳跃。
  • 风险：某些 SQL 语法或存储引擎行为可能有细微差别。
  • 操作：在升级系统前，最好先手动将 MariaDB 升级到 10.3 的稳定分支，或者在升级系统后，立即执行 mysql_upgrade (注意：新版 MariaDB 中此命令已弃用，需使用 mariadb-upgrade 或自动升级机制)。务必检查数据完整性。
• PostgreSQL 10 -> 12：同样是大版本跳跃。PostgreSQL 的升级通常需要导出/导入或使用 pg_upgrade 工具。直接通过 apt 升级可能会失败，因为二进制文件不兼容。强烈建议在升级 OS 前，先将 PG 集群升级到 10.x 的最新点版本，甚至考虑迁移到 12 后再进行 OS 升级，或者在 OS 升级后立即按照 PG 官方文档进行集群升级。

4. PHP 和 Web 栈：PHP 7.0 -> 7.3

• PHP 版本提升：Debian 9 默认 PHP 7.0，Debian 10 默认 PHP 7.3。
• 兼容性警告：如果你的应用严重依赖 PHP 7.0 的特性或已废弃的扩展（如 mysql 扩展而非 mysqli/pdo_mysql），升级后网站会直接报错。
• 解决方案：
  1. 代码层面：确保所有数据库连接使用 mysqli 或 PDO。
  2. 架构层面：如果应用老旧且无法修改代码，不要直接升级。应该在 Debian 10 上通过第三方源（如 Ondřej Surý 的 PPA）安装旧版 PHP，或者使用 Docker 容器化部署旧版 PHP 环境。原生 Debian 包管理器不支持长期共存多个主要版本的 PHP。

5. 内核与安全模块

• 内核版本：从 4.9 升级到 4.19。大多数硬件驱动都能兼容，但如果你使用了特殊的专有硬件驱动（如某些显卡、网卡固件），需要确认厂商是否提供了支持 4.19 内核的驱动。
• AppArmor：Debian 10 对 AppArmor 的策略进行了更新。某些原本被允许的应用可能被新的策略拦截。如果遇到应用权限问题，检查 /var/log/syslog 中的 AppArmor 拒绝日志。

6. 升级步骤实操建议（最小化风险版）

不要直接 apt dist-upgrade，请按以下步骤操作：

1. 更新到最新 Debian 9：

   apt update && apt full-upgrade -y
   reboot

   确保 Stretch 处于最新状态，避免中间版本冲突。

2. 修改 sources.list：
   将所有 stretch 替换为 buster。可以使用 sed 快速完成：

   sed -i 's/stretch/buster/g' /etc/apt/sources.list

3. 预检：

   apt update
   apt list --upgradable

   仔细审查即将升级的包列表，特别是那些带有 security.debian.org 或 deb.debian.org 的核心包。

4. 执行升级：

   apt full-upgrade -y

   过程中会有多次提示，仔细阅读。对于配置文件变更（.dpkg-dist 等），如果没有特殊定制，通常可以选择保持本地版本；如果有重要定制，务必手动合并。

5. 重启与验证：

   reboot

   重启后，检查：

   • cat /etc/debian_version 确认版本号为 10.x。
   • systemctl status 查看是否有服务异常停止。
   • 访问你的 Web 应用、数据库连接是否正常。
   • 检查日志：journalctl -xe 查找错误信息。

7. 特别提醒：关于“国内云厂商”的特殊性

如果你是在阿里云、腾讯云、华为云等国内云平台上的 ECS/CVM 实例上操作：

• 云助手/云监控插件：升级内核后，确保云厂商提供的监控XX（如 Alibaba Cloud Monitor Agent, Tencent Cloud Monitor Agent）兼容新内核。有时需要卸载旧版插件，安装针对 Buster 的新版插件。
• 磁盘驱动：大部分主流云厂商的内核都包含 virtio 驱动，一般无需担心。但如果你的实例使用了非常规的虚拟化管理类型，可能需要关注云厂商提供的专属内核包。
• 快照优先：在点击升级按钮前，必须在控制台创建系统盘快照。一旦升级失败导致系统无法启动，你可以随时回滚到快照状态，这是最安全的兜底方案。

总结

从 Debian 9 到 10 的升级，最大的挑战不在于系统本身能否启动，而在于上层应用的兼容性。PHP、MySQL/MariaDB、PostgreSQL 的版本跳跃是重灾区。

我的建议是：
如果业务不允许停机或维护窗口很短，不要直接在原机上升级。最好的做法是：

1. 新建一台 Debian 10 的纯净实例。
2. 迁移数据和配置过去。
3. 验证无误后，切换 DNS 或负载均衡指向新机器。
4. 旧机器保留一段时间作为观察。

这才是真正的“大神”做法——追求稳定性，而不是炫技式地原地升级。