6.4 备份恢复与升级维护


文档摘要

6.4 备份恢复与升级维护 本节摘要:三副本防硬件故障,但防不了"账本损坏"与"人为删除"。本节给出分层备份策略(元数据每日、关键数据异地、不可变冷备)、恢复演练的完整流程、滚动升级的次序编排,以及把例行维护做成 SOP 的清单化方法。 三副本不是备份 先纠正一个危险的错觉。2.2 节的三副本应对的是磁盘与节点故障——意外的、局部的、可自愈的。真正的数据事故往往是: 敲错路径(人为、全局、瞬间扩散到所有副本);NameNode 账本损坏(元数据层,副本再多个也没用);机房级灾难。三副本对这三类全部无能为力。备份策略必须按"账本"与"数据"两层分别设计。

6.4 备份恢复与升级维护

本节摘要:三副本防硬件故障,但防不了"账本损坏"与"人为删除"。本节给出分层备份策略(元数据每日、关键数据异地、不可变冷备)、恢复演练的完整流程、滚动升级的次序编排,以及把例行维护做成 SOP 的清单化方法。

三副本不是备份

先纠正一个危险的错觉。2.2 节的三副本应对的是磁盘与节点故障——意外的、局部的、可自愈的。真正的数据事故往往是:hdfs dfs -rm -r 敲错路径(人为、全局、瞬间扩散到所有副本);NameNode 账本损坏(元数据层,副本再多个也没用);机房级灾难。三副本对这三类全部无能为力。备份策略必须按"账本"与"数据"两层分别设计。

图 6-4 分层备份与恢复路径全景

图 6-4 分层备份与恢复路径全景

元数据备份:账本每日三件套

账本丢了,磁盘上再多数据也是"无主孤儿"。每日备份三件:FsImage 加 EditLog(Checkpoint 产物加增量日志,从 NameNode 或 Secondary 拉到备份机);Hive Metastore 数据库导出(表定义、分区映射——重建成千上万张表的定义比重算数据更痛苦);配置与 keytab(含 Oozie 工作流定义,6.3 节的 keytab 需异地保管)。保留窗口至少 7 天,且要有至少一份落在集群物理机之外。

# 元数据备份脚本要点(cron 每日) hdfs dfsadmin -fetchImage /backup/nnimage-$(date +%F).img # 备份机执行: mysqldump -h metastore-db hive > /backup/metastore-$(date +%F).sql rsync -a /backup/ offsite-host:/hadoop-backup/

数据层按可再生性分级:报表产出(L1)每日 DistCp 复制到异地集群;中间明细层(L2)不备份——源数据在,重算管道在(5.5 节 Oozie 重跑),备份它纯属浪费;合规归档(L3)用 2.4 节纠删码冷存,一次写入不可变。另外把回收站保留期调大:

<property> <name>fs.trash.interval</name> <value>10080</value> <!-- 7天 分钟为单位 --> </property>

误删后的黄金 10 分钟里,回收站就是最便宜的恢复手段——前提是它开着且没被 -skipTrash 绕过。

顺带算一笔"值多少"的账:备份存储虽是纯成本,但对照 6.4 开头那三类事故的损失(监管罚款、报表中断、重建耗时)几乎总是划算的——冷备用纠删码后,为全部分区结果加一层异地兜底的增量开销通常不到总存储的一成,却把 RPO 从"永远"压到"一天"。

恢复演练:没演练过的备份等于没有

备份的有效性必须靠演练证明。元数据恢复流程:新机器部署空 NameNode → 放入备份的 FsImage 与 EditLog → 启动(自动回放日志)→ fsck 逐步核对 → DataNode 逐批注册(数据都在磁盘上,账本对上号即可读)。演练要计时并回答三个问题:恢复耗时多久(决定 RTO)?丢多久数据(决定 RPO,取决于备份频率)?哪些环节依赖单人记忆(写成 SOP 消除)?季度演练挑一个分区走全流程,比任何文档都有效。

滚动升级:不停机的维护艺术

升级 Hadoop(如 3.3 升 3.4)或打安全补丁,标准方式是滚动升级——逐节点摘除、升级、回池,全程服务不断。次序有讲究,先升 NameNode(备)再升 DataNode,计算层同理先 RM 后 NM:

1 备NameNode升级 → 验证 → 主备切换 → 升原主 2 DataNode分批(每批10%)摘除升级回池 fsck抽查 3 ResourceManager同法 4 NodeManager分批 注意任务自然排空后再摘 5 全集群健康观察24小时

两个安全网。HDFS 数据布局升级是单独步骤(hdfs 无 datanode -upgrade),先在测试环境验证;生产升级前核对发行说明里的不兼容清单(配置改名、默认值变化——4.1 节 vmem 检查禁用就是版本默认值变化的典型)。回退预案:每批升级保留旧版本安装目录,问题出现时单批可回退;升级窗口选择业务低峰(通常周日夜批后),并冻结同时段的其他变更——多个变更叠加是排障的地狱。

例行维护 SOP 化

高频维护动作清单化,把"老师傅的经验"变成"任何人可执行的步骤":坏盘更换(定位 DN 日志中的卷路径 → 拔盘换盘 → 观察块自动补齐)、节点下线(dfsadmin -refreshNodes 走 exclude 文件优雅退役,让块先搬走再关机——直接断电会把副本风暴留给集群)、证书与 keytab 轮换(6.3 节主体票据到期前的日历提醒)、季度演练。SOP 的检验标准:值班工程师凌晨三点照单执行不出错。

本节要点回顾

  • 三副本防硬件不防人祸,账本损坏与误删需要独立的备份体系;
  • 账本三件套每日备:FsImage 加 EditLog、Metastore、配置与 keytab,至少一份异地;
  • 数据按可再生性分级:产出每日异地、明细不备、归档纠删码冷存;回收站保留期调到 7 天;
  • 没演练过的备份等于没有:季度演练计时定 RTO 与 RPO;
  • 滚动升级先控制面后数据面、分批可回退,窗口冻结其他变更;
  • 高频维护 SOP 化,坏盘、退役、轮换照单执行。

运维篇收官。最后一章抬起头看远方:这段数据旅程的下一站在哪里。


作者与出处
原作者: 灏天文库
来源:灏天文库
整理: 灏天文库整理
由灏天文库平台收录,内容或由平台用户上传,仅供学习交流
发布者: 作者: 灏天文库 转发
评论区 (0)
U