Ubuntu HDFS版本升级需要注意什么

Ubuntu 环境下 HDFS 版本升级注意事项

一 升级方式与前置条件

• 明确升级路径：HDFS 支持滚动升级（Rolling Upgrade）与停机升级（Express）。要实现不停机，集群需启用 HA；非 HA 场景需接受 NameNode 重启带来的短暂停机。滚动升级自 Hadoop 2.4.0 起提供。升级前务必阅读目标版本的发行说明与不兼容变更，并在测试环境充分演练。升级前用 fsck 全面检查文件系统健康，并清理 MapReduce 系统目录与本地临时文件，保留 fsck 报告以便升级后对比。为降低风险，先备份 NameNode 元数据目录等关键数据。

二 兼容性与版本边界

• 滚动升级的兼容性前提：需要 HA 与线路兼容（wire compatibility）。若升级中启用新特性，需遵循“先禁用 → 升级 → 再启用”的顺序，避免新旧版本功能不兼容。
• 2.x 小版本间常见情况：部分相邻小版本（如 2.7.2 → 2.8.5）在 RPC 版本与存储布局版本保持一致，通常可热替换并重启；但仍需避免高版本 NN + 低版本 DN的组合，例如 2.8.5 NN + 2.7.2 DN 会因新增字段导致 blockReport 异常。
• 2.x → 3.x 的关键差异：HDFS 3.x 引入 Erasure Coding（EC） 等新特性，涉及 EditLog/Fsimage 格式与协议变更。社区实践表明，跨大版本直接滚动升级可能遇到 EditLog 不兼容、Fsimage 不兼容等问题；部分厂商与团队在 2.x→3.x 场景更倾向采用停机升级或先做小版本过渡与充分测试。升级前务必评估是否使用 EC、Router-Based Federation、More than 2 NN 等特性，并据此制定方案。

三 回滚降级与 Finalize 的取舍

• 基本概念：升级过程中保留前一版本的元数据与数据副本（DataNode 通过硬链接指向同一块，节省空间），在确认稳定前可回滚或选择定妥升级（finalize）。一旦执行 finalize，将删除旧版本副本且不可回滚；HDFS 不支持多版本回滚，只能回滚到上一次升级前状态。
• 滚动升级的回退选项：支持滚动降级（仅回退软件版本、数据不动）与回滚（回到升级前版本与状态，可能丢失升级后数据）。注意：回滚需要停机，且只能在“已启动滚动升级且未完成”的窗口内执行；降级可以滚动进行，但必须在降级 NameNode 之前先降级 DataNode（协议通常向后兼容，反之不成立）。

四 关键操作清单与命令示例

• 滚动升级（HA 集群）要点：
  • 准备：执行 hdfs dfsadmin -rollingUpgrade prepare 并查询至状态为“Proceeding with Rolling Upgrade”。
  • 升级 NN：依次升级 Standby NN → 切换 Active → 升级原 Active NN，启动参数加 -rollingUpgrade started。
  • 升级 DN：按机架/批次滚动执行：hdfs dfsadmin -shutdownDatanode host:IPC upgrade → 升级重启 → hdfs dfsadmin -getDatanodeInfo 确认；全部完成后执行 hdfs dfsadmin -rollingUpgrade finalize。
• 停机升级（非 HA）要点：
  • 备份 NameNode 目录；使用新版本以 -upgrade 启动（如 start-dfs.sh -upgrade），通过 hdfs dfsadmin -upgradeProgress status 观察进度；验证无误后再 finalize。如需回滚，停新进程，用旧版本以 -rollback 启动。
• 常用命令速查：
  • 查询/准备/完成滚动升级：hdfs dfsadmin -rollingUpgrade query|prepare|finalize
  • 关闭 DN 并进入升级模式：hdfs dfsadmin -shutdownDatanode host:IPC upgrade
  • 查看 DN 关闭进度：hdfs dfsadmin -getDatanodeInfo host:IPC
  • NN 滚动升级启动选项：hdfs namenode -rollingUpgrade started|rollback
  • 升级进度与状态：hdfs dfsadmin -upgradeProgress status

五 客户端与生态兼容及上线节奏

• 客户端策略：HDFS 3.x 通常对 2.x 客户端保持读/写兼容，但计算组件（如 Spark/Hive/Flink）可能需同步升级依赖；可先在 2.x 客户端下验证读写，再按依赖关系逐步升级客户端与服务。
• 上线节奏建议：先在测试/预发集群演练完整流程（含回滚/降级），再在生产低峰窗口执行；升级后对关键目录做 fsck 与业务侧回归，观察 NameNode RPC 延迟、吞吐、块报告等指标，确认稳定后再执行 finalize。