迁往AlmaLinux或Rocky Linux，香港物理机上的CentOS 7如何规划停机与回滚？

将香港物理机上的 CentOS 7 迁往 AlmaLinux 或 Rocky Linux，目标不只是“新系统能够启动”，而是业务依赖、网络入口、数据一致性和恢复能力都达到可验收状态。生产变更应优先评估“新机部署、提前同步、停写切换、旧机保留”的路径，把停机压缩到最终增量同步和入口切换；只有硬件、软件及升级工具的支持条件都已核实时，才考虑原机跨大版本升级。

停机窗口要同时容纳实施、验证和失败恢复，不能全部分配给升级操作。回滚也要区分两个阶段：新系统尚未承接真实写入时，可以恢复旧系统入口；新系统已经产生订单、文件或数据库事务后，必须先处理新增数据，再决定是否退回。没有验证过恢复时间和数据回流方法的备份，不能视为完整的回滚方案。

A5数据提供中国香港及美国、日本、韩国、中国台湾、新加坡、马来西亚等地区的物理服务器资源，覆盖常规建站、数据库、业务后台、接口服务和多任务计算场景。香港服务器可结合Xeon Gold、AMD EPYC、NVMe存储、不同带宽线路及多IP配置，为AlmaLinux或Rocky Linux迁移后的目标环境提供相应的计算、存储与网络基础。

一、现状核对：确定迁移对象、影响范围和目标版本

CentOS 7 已于 2024 年 6 月 30 日结束生命周期，相关说明可查阅 CentOS 生命周期页面。继续运行并不意味着服务会立即中断，但常规维护不能再按过去的安全更新机制规划，第三方软件支持也需要逐项确认。

作为生产变更负责人，我会先冻结迁移范围：本次主要完成操作系统替换，还是同时变更数据库、运行时和应用架构。通常应避免把系统升级、数据库大版本升级、存储重构和业务发布放在同一个窗口。确实无法拆分的依赖，需要单独列出验证步骤与退出条件。

1. 建立资产与依赖清单

至少将以下信息写入变更单，而不是只记录服务器 IP 和系统版本。

以下命令适合在 CentOS 7 上做基础盘点，不修改配置。输出可能包含地址和内部路径，应保存在受控位置，不要直接公开。

cat /etc/centos-release
uname -r
lscpu
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
df -hT
findmnt
ip addr show
ip route show
systemctl --failed
systemctl list-unit-files --state=enabled
rpm -qa | sort

如果安装了 pciutils，可以通过 lspci -nnk 核对网卡、存储控制器及当前驱动。还应检查应用服务文件、计划任务、监听端口和数据库版本，但配置中的密码、令牌、私钥不能进入普通工单。

香港物理机尤其要核对网络与控制台条件。 更换机器不代表公网 IP 可以直接迁移；有些地址需要机房侧重新绑定，有些方案只能通过 DNS 或负载均衡切换。接入网关、掩码、内网 VLAN、端口绑定及源地址白名单，都应与服务商确认。不能默认 A5IDC 或其他服务商的每台物理机都具备相同的远程控制和救援能力。

2. AlmaLinux 与 Rocky Linux 分别如何评估

两者都可以作为企业 Linux 迁移候选，但选择不能仅凭“兼容 CentOS”作判断。需要先选目标大版本，再核对发行版、应用和硬件的组合。

例如选择 9 系列作为目标时，需要核对 CPU 基线、旧网卡驱动和应用所依赖的加密算法，不能认为“CentOS 7 能安装，新系统也一定能安装”。

AlmaLinux 的 ELevate 可用于特定受支持组合的跨版本迁移，实际路径应以其项目文档为准。Rocky Linux 的迁移工具也有适用的源系统和版本范围，应核对其文档。同大版本发行版转换工具，不等于 CentOS 7 到新大版本的通用升级工具。 如果需要分阶段跨越多个大版本，每一阶段都要独立预检查、重启、验证和备份。

3. 选定实施路径

建议按下列顺序判断：

1. 有备用物理机：优先新装迁移。 保留旧系统和原始数据，兼容问题可以提前暴露，回滚路径也较清晰。
2. 只有一台机器，但可以安排临时资源：先建立临时承载环境。 验证备份恢复和业务启动后，再重装原机。
3. 必须原机升级：先证明工具支持与恢复能力。 没有带外控制台、整机恢复方案或可接受的恢复时间，就不应按短窗口批准升级。
4. 旧软件无支持版本：先处理应用依赖。 不要通过长期关闭安全机制或大量混装旧包来强行适配。

二、变更准备：备份、演练与停机预算

1. 备份应覆盖三层，而不只是业务目录

第一层是业务数据，包括数据库、用户上传文件、对象存储关联信息及必要的队列状态。数据库应使用与版本相容的备份工具，或通过经过验证的复制机制同步；不能把运行中数据库的数据目录直接复制，当作一致性备份。

第二层是配置和身份，包括服务配置、证书、应用环境变量、UID/GID、文件权限、ACL、SELinux 自定义规则和商业授权材料。新系统应重新安装软件，再迁移经过核对的配置，不建议整体覆盖旧机的 /etc。

第三层是系统恢复材料，包括分区表、启动模式、RAID 配置记录、安装介质及必要的整盘镜像。物理机通常没有可直接使用的云快照；在线制作镜像也不自动保证文件系统和数据库一致。

备份必须满足三个条件：

• 存放在与源机故障域分离的位置，避免唯一副本仍在同一组磁盘上。
• 有时间点、完整性校验记录和明确的恢复方法。
• 至少做过一次隔离恢复，验证数据库可打开、文件可读取、应用能启动。

恢复演练不仅证明“备份存在”，还要测出恢复耗时。如果整机恢复需要数小时，就不能将原机重装的回滚时间写成十几分钟。

2. 用真实链路估算同步时间

香港物理机的同步速度取决于备份位置、可用带宽、磁盘读写和文件数量，不能只看端口标称速率。同机房内网同步和跨地区公网同步，应分别测量。

以十进制单位估算：首次复制 300 GB 数据，实际有效载荷吞吐为 500 Mbps，则：

• 数据量为 300 × 1000 × 8 = 2,400,000 Mb；
• 理论传输时间为 2,400,000 ÷ 500 = 4,800 秒；
• 即约 80 分钟，尚未计入校验、文件扫描和数据库恢复时间。

因此，大部分数据应提前复制。停机窗口内只处理最终增量。若最终变化量为 12 GB，有效复制速度为 40 MB/s，则传输约需 12,000 ÷ 40 = 300 秒，即 5 分钟；仍需增加停止写入、一致性检查和切换验证的时间。

大量小文件往往受元数据操作限制，数据库还可能需要重放日志。上述结果只能作为预算，最终应采用演练数据，并留出波动余量。

3. 为回滚保留不可挪用的时间

停机预算可以按以下关系编制：

停机窗口 = 停写与排空时间 + 最终同步时间 + 切换时间 + 验证时间 + 失败恢复预留。

例如一个 90 分钟的维护窗口，正常路径计划用时 35 分钟：

若回滚执行需要 30 分钟，回滚后验证需要 10 分钟，并要求保留 5 分钟余量，那么最迟必须在第 45 分钟作出回滚决定。这不是允许继续尝试到第 89 分钟，而是明确停止排障的时间边界。

同时定义恢复时间目标和可接受数据损失。要求不丢失已确认事务时，必须验证提交位置及新增数据的恢复能力，不能仅凭“有昨晚备份”宣称可以无损退回。

三、分步实施：先消除兼容问题，再进行业务切换

1. 在目标机完成系统与应用预部署

新机迁移应先安装已选定的 AlmaLinux 或 Rocky Linux 版本，再完成补丁、时间同步、存储挂载、监控和访问控制。

这一阶段不应让目标机提前成为生产写入端。定时任务、队列消费者、自动结算和通知发送功能应保持禁用，避免两台机器同时处理同一业务。

重点检查以下变化：

• 网卡名称和网络管理方式是否变化，不能照搬旧网卡配置。
• 文件挂载是否采用稳定标识，是否存在缺失的数据盘或启动顺序问题。
• PHP、Python、Java、OpenSSL 等版本是否满足应用要求。
• 数据库客户端与服务端的认证、字符集、排序规则是否兼容。
• SELinux、系统加密策略和防火墙是否阻止必要访问。
• 应用用户的 UID/GID、目录权限与安全标签是否正确。

配置验证可以使用目标系统实际安装的软件提供的检查命令，例如 Nginx 的 nginx -t。若 SELinux 阻止访问，应排查日志并修正标签或策略；不要将永久关闭 SELinux 作为默认迁移步骤。

2. 预同步数据并完成隔离测试

文件同步应核对属主、权限、软链接、ACL 和扩展属性；数据库同步应记录备份时间、日志位置或复制进度。目标端的临时文件、缓存和运行时目录，不应随业务数据无差别覆盖。

隔离测试至少覆盖登录、查询、上传、下载及一条完整业务流程。测试请求必须明确进入目标机，不能因为公网域名仍指向旧机而误判成功。涉及支付、邮件、短信或外部回调时，应使用隔离配置，避免产生真实业务副作用。

还要从主要用户所在网络和实际使用的回源路径检查连通性。香港机房内访问正常，不能替代用户侧链路验收。

如果通过 DNS 切换，应提前调整 TTL，并等待原 TTL 周期过去。降低 TTL 只能减少部分缓存等待，不能保证全部客户端立即切换；如具备负载均衡入口，通常更容易控制连接排空和后端切换。

3. 到达窗口后，执行写入冻结

推荐的新机迁移顺序如下：

1. 发布维护状态，停止接收新的写请求。
2. 暂停定时任务、队列消费者、后台批处理和外部写入入口。
3. 等待已有请求与数据库事务结束，确认没有遗漏的写入来源。
4. 记录数据库提交位置、队列状态和最终数据检查点。
5. 完成最终增量同步，并核验一致性。
6. 隔离旧机的生产写入能力，防止旧连接继续落数据。
7. 切换业务入口，在目标机执行受控验证。
8. 验收通过后，按顺序恢复真实写入和后台任务。

维护页不是数据库写入屏障。内部任务、管理后台和第三方回调仍可能写数据，应逐项确认。访问限制涉及防火墙、数据库权限或网络配置时，需要先保存原配置、保留管理通道，并准备反向恢复步骤。

切换期间必须保持单一权威写入端。不能让部分客户端写旧机、部分客户端写新机，再期待事后自动合并。

4. 原机升级必须增加中间检查点

原机跨版本升级不能照搬上述“切换回旧机”的回滚方式，因为旧系统可能已经被覆盖。

应先运行对应工具的预检查，解决阻断项，并在同型号设备或可代表生产依赖的环境中演练。每跨越一个大版本，都要检查启动、驱动、存储、网络和应用状态，不能连续运行多个升级脚本后再统一验收。

安装新系统、重分区、写入镜像或修复引导都可能覆盖原数据。这类操作必须以已验证的异机备份为前提，明确操作磁盘，并准备带外控制台恢复流程。包管理器的历史记录不等于跨大版本系统回滚能力。

四、验证观察：不仅看服务启动，还要看业务恢复

1. 切换验收按由外到内执行

验收顺序应从用户入口进入系统内部，避免只看到进程存在就宣布完成。

1. 入口层： DNS、负载均衡或 CDN 回源是否指向预期目标，TLS 证书和域名匹配是否正常。
2. 网络层： 主要用户路径、必要端口、外部依赖和回调是否可达。
3. 应用层： 登录、查询、写入、文件处理及核心业务流程是否成功。
4. 数据层： 数据库提交位置、关键记录、抽样文件校验及队列状态是否符合切换检查点。
5. 系统层： 服务失败、磁盘错误、内核日志、挂载状态和资源使用是否异常。

目标系统上可以执行以下只读检查，服务名称则按实际部署调整：

cat /etc/os-release
uname -r
systemctl --failed
journalctl -b -p err --no-pager
df -hT
findmnt
ss -lntup

发现问题时先判断范围：入口不可达但本机服务正常，应优先检查入口和网络；接口失败而端口正常，应查看应用及数据库日志；如果出现磁盘 I/O 错误或文件系统异常，应停止新增写入，避免把故障扩大。

记录数量或文件数量相同，只能证明部分一致性。数据库应结合事务位置和业务规则校验，文件应对关键内容进行校验，不宜用单一总数代替完整验收。

2. 用基线和阈值决定是否继续

变更前应保存至少一个代表性业务周期的监控基线，覆盖接口耗时、错误率、连接数、队列积压和磁盘延迟。迁移后的判断应结合请求量，避免在低流量时误认为性能正常。

以下可作为变更单的示例条件，实际数值应按业务调整：

数据不一致和重复扣费等问题应直接触发停写，不必等待性能观察结束。单次监控抖动则应结合用户影响和持续时间判断，避免频繁切换造成更大风险。

五、回滚条件：区分“切回入口”和“恢复数据”

1. 尚未开放真实写入时，执行快速回退

如果目标机未接收真实业务写入，旧机数据仍停留在有效检查点，通常可以按以下顺序退回：

1. 停止目标机服务及后台任务，确认其不能继续写入。
2. 恢复旧机的必要访问和原入口配置。
3. 验证旧机的数据库、应用与文件状态。
4. 在确认单一写入端后，恢复请求、定时任务和消费者。
5. 保留目标机日志和现场，另开窗口排查。

测试产生的临时数据应事先隔离。若测试修改了真实账务或库存，就不能直接按“尚无写入”处理。

2. 已经承接真实写入时，先处理新增数据

一旦目标机接受了真实写入，切回旧机就成为数据恢复变更，而不只是网络调整。此时必须先冻结写入，记录目标端最后提交位置，再判断：

• 是否已有经过验证的反向复制或日志回放路径；
• 旧数据库是否能接收新版本的数据格式；
• 新上传文件、删除操作和队列确认状态能否同步；
• 是否存在无法撤销的外部业务结果。

数据库大版本变更尤其需要谨慎：新版本备份或日志未必能被旧版本使用。没有验证过的数据回流方案时，通常应优先在新环境修复，或恢复到兼容的新环境，而不是强行退回旧版本。

回滚成功的标准，是业务恢复到一致、可持续运行的状态，不是旧系统重新启动。 如果应急恢复会损失部分已确认数据，必须经过明确授权，并记录影响范围。

3. 原机升级失败，按恢复方案执行

原机升级后启动失败，应优先使用带外控制台确认是引导、驱动还是文件系统问题。只允许尝试预案内、可逆且有时间限制的修复。

若关键磁盘无法识别、网络无法恢复，或已到回滚截止时间，应停止临场试错，进入镜像恢复或重装后恢复数据的流程。没有验证过整机恢复的环境，不应把“重新装回 CentOS 7”当作可靠兜底。

回到 CentOS 7 只能用于临时恢复业务，不会消除其生命周期风险。恢复后仍需重新安排迁移，而不是无限期保留原状。

4. 观察窗口结束前，不销毁旧环境

对于一般网站和业务系统，可将切换后的前 1～2 小时设为重点观察期，再安排 24～72 小时覆盖日常流量、备份和批处理。这是参考安排；存在周结算、特殊报表或长周期任务时，应延长观察。

旧机应保持受控、禁止业务写入，同时保留可恢复的数据和配置。只有新系统完成有效备份、备份恢复抽检通过、关键周期任务正常，且回滚需求已正式解除后，才安排旧盘清理或设备回收。

本次变更应明确三条执行边界：到回滚截止时间仍未通过核心验收，立即停止继续尝试；发现数据不一致，立即停写；新系统已产生真实写入后，未经数据处理不得直接切回旧机。 将这些条件连同负责人、恢复耗时和观察窗口写入变更单，才能使 AlmaLinux 或 Rocky Linux 迁移成为可控制的生产变更。