大数据——HDFS数据备份与恢复

发布时间:2018-01-10 12:44:13编辑:丝画阁阅读(369)

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

大数据——HDFS数据备份与恢复

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 的块文件,如图:

大数据——HDFS数据备份与恢复

正在splitting的块

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

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


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

关键字