给大家分享一下我在给公司集群恢复损坏数据的办法

Hadoop-HDFS数据备份与恢复

一、备份的目的

1. 备份场景

由于公司的业务场景限制，在众多场景下的小集群运行环境中，没有UPS等市电中断下的续航设备，导致集群意外停止。在市电恢复后可能出现系统无法启动，系统数据目录损坏等情况，此时可能由于集群HDFS数据损坏导致集群无  法正  (《大数据——HDFS数据备份与恢复》)常启动，因此针对此情况，就必须对HDFS的数据进行一定的备份操作

2. 适用对象

针对CDH 5.10集群的HDFS高可用状态下实现，因为部分操作仅需要在CDH集群下执行。其他HDFS集群备份原理一致，非HDFS高可用状态操作大致一样

二、数据备份

1. 备份策略

HDFS的备份策略采用备份NameNode元数据的方式。

使用备份的NameNode元数据，在DataNode数据完整的情况下，NamenNode保存了哪些数据索引即可恢复哪些数据

对于DataNode的数据文件，只要不是人为删除，即使格式化NameNode也不会删除DataNode的数据文件，且DataNode数据文件一般较大，备份较为麻烦。

2. 存在的问题

> 1. 备份NameNode元数据目录时，NameNode内存中处理的数据还没有及时写入元数据文件，导致备份出来的元数据不是最新的，在恢复时可能导致小部分数据丢失

> 2. 使用NameNode元数据恢复数据时，由于第1步操作中，HDFS恢复完成时丢失了一部分数据，导致Hbase在启动时做Split操作会无限等待。此时需要删除Hbase做Split操作的块，才能使Hbase正常启动。但删除块的过程就表示丢弃这部分数据。这个操作应该只是会影响最新的一部分数据。

3. 备份方法

找到CDH集群的活动NameNode节点，将NameNode元数据的根目录直接COPY即可。一般将备份文件存储到其他服务器

三、数据还原

使用NameNode元数据还原过程如下

1. 恢复HDFS数据

> 1. 停止Hbase服务，停止HDFS的所有NameNode、JournalNode角色，保持DataNode角色启动

> 2. 将JournalNode角色的数据根目录进行备份（重新修改其他名字即可）。如：JournalNode数据根目录为/dfs/jnn ， 重命名为/dfs/jnn.bak

> 3. 在任意一个NameNode节点，修改/etc/hadoop/conf/hdfs-site.xml文件，添加如下内容：

dfs.namenode.name.dirfile:///dfs/nn

dfs.namenode.shared.edits.dirqjournal://e1.worker.com:8485;e5.worker.com:8485;e6.worker.com:8485/nameservice1

第一个配置表示设置NameNode的数据目录位置，第二个配置表示设置NameNode共享edit元数据时，上传给哪些JournalNode。qjournal参数后面是JournalNode的所在节点，nameservice1是HA高可用名称

> 4. 进入NameNode的元数据目录/dfs/nn/current，若该目录下有文件则备份并移除，此时将NameNode的备份元数据（edit、fsimage、seen_txid、VERSION等所有文件）复制到当前的current目录。

> 5. 将当前的NameNode元数据共享给JournalNode，执行命令：

/opt/cloudera/parcels/CDH-5.10.0-1.cdh5.10.0.p0.41/bin/hdfs namenode -initializeSharedEdits

# 若有hdfs命令，直接执行即可。没有则用whereis等命令查找一下

上述步骤执行时，会提示是否格式化JournalNode目录，输入Y即可，确认格式化

> 6. 分别进入各个JournalNode节点，在JournalNode的根目录下使用命令修改所有者：

chown -R hdfs:hadoop /dfs/jnn

# 因为第5步操作，在root用户下执行的，生成的JournalNode目录也是root用户

# CDH启动时，使用的是hdfs用户加载，会报权限问题

# NameNode元数据也需要修改所有者、所有组 为hdfs:hadoop

> 7. 在CDH界面，启动当前节点的NameNode

> 8. 注意查看NameNode的启动日志，可能会出现以下问题，一一解决皆可：

> 1. Name node is in safe mode

显示NameNode处于安全模式，则使用以下命令离开安全模式：

su hdfs -c "hdfs dfsadmin -safemode leave"

> 2. here appears to be a gap in the edit log . We expected txid 16020721, but got txid 16020717

这是因为JounalNode少了16020721这个edit文件，从NameNode的元数据目录将该edits_xxxxxxx16020721-edits_xxxxxxxxxxxx文件拷贝到所有journalNode节点即可

> 9. NameNode正常启动后，打开NameNode的web ui界面，浏览一下HDFS上的数据，找到Hbase的目录，选择一些Hbase的存储数据，尝试Download，看是否能够下载下来。若能够下载则表示数据是恢复成功的，至少有部分数据已经恢复成功

> 10. 在备用的NameNode节点，在/etc/hadoop/conf/hdfs-site.xml配置文件中添加第3步的配置内容。然后执行同步命令：

hdfs namenode -bootstrapStandby

# 该命令将当前活动的NameNode的元数据同步到备用的NameNode

> 11. 启动备用的NameNode节点

> 12 . 此时HDFS数据就恢复完成了

2. 恢复Hbase

Hbase其实不涉及恢复操作，只是因为在启动Hbase过程中会遇到一些问题，以解决问题为主

> 1. 在启动Hbase过程中，通过Master日志发现一直输出SplitManage日志，且对某一个块的Spliat始终无法完成

》解决办法：

1. 通过日志，其实可以看到当前split的块在HDFS上的路径，在HDFS WEB UI去访问这个块，其实是无法下载下来的，也就是该块的数据已经在HDFS上丢失了

2. 此时需要删除无法Split的块：

>1. 首先停止HbaseMaster，在zookeeper上，

删除如下路径：/hbase/splitWAL/ 下的所有文件

> 2. 删除HDFS上，/hbase/WALs/xxxxxxx-splitting 的块文件，如图：

正在splitting的块

3. 重新启动HbaseMaster。若还显示有无法split的块，则重复步骤2即可。

Hbase正常恢复后，可以用hbase shell看一下各个表的数据能否读出来。

---

欢迎大家关注我的头条号，会不定期分享一些大数据、自动化运维、Docker、Python、WIFI技术等文章