发布时间:2018-01-10 12:44:13编辑:丝画阁阅读(992)
给大家分享一下我在给公司集群恢复损坏数据的办法
一、备份的目的
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 的块文件,如图:
3. 重新启动HbaseMaster。若还显示有无法split的块,则重复步骤2即可。
Hbase正常恢复后,可以用hbase shell看一下各个表的数据能否读出来。
欢迎大家关注我的头条号,会不定期分享一些大数据、自动化运维、Docker、Python、WIFI技术等文章
关键字:
本站部分内容来源网络及网友上传,本站未必能一一鉴别其是否为公共版权或其版权归属,如果您认为侵犯您的权利,本站将表示非常抱歉!
请您速联系本站,本站一经核实,立即删除。删文删帖联系【2789291421@qq.com】