其他分享
首页 > 其他分享> > 转载:删了HDFS又能怎样?记一次删库不跑路事件

转载:删了HDFS又能怎样?记一次删库不跑路事件

作者:互联网

一、事发背景

​ 上个月的某一天,由于集群空间不足,公司有一位技术经理级别的大数据leader在通过跳板机在某个线上集群执行手动清理命令,疯狂地执行hadoop fs -rmr -skipTrash /user/hive/warehouse/xxxxx,突然,不知道是编辑器的问题还是换行问题,命令被截断,命令变成了hadoop fs -rmr -skipTrash /user/hive/warehouse,悲剧此刻开始发生!?

​ /user/hive/warehouse目录下存储了所有hive表的数据,关联公司多个业务线,一旦丢失,意味着巨大的损失。由于加了-skipTrash参数,意味着删除的数据不会放入回收站而是直接删除,这个参数不加的话很容易挽回,回收站里直接找,可惜逃不了墨菲定律,最担心的事还是发生了。

​ 领导解决不了的事,只有小弟上,看我接下来怎样四两拨千斤。

二、应急措施

运维跟这位大数据经理第一时间找到我,当时说误删了 /user/hive/warehouse目录。当时我也是一震惊,完了完了!凭我仅有的直觉,立马停掉了HDFS集群!后面证明是很明智的选择。

直观的方案
通过快照恢复?hdfs快照从来没用过,也没创建过快照,所以此路不通
通过回收站恢复?删除时加了-skipTrash参数,不会放回收站,此路也不通
删库跑路成为一代传奇人物?嗯,还不错

三、分析过程

想要恢复数据,首先要理解hdfs删除文件的过程,各个文件系统的删除逻辑都不一样,理解了hdfs的删除过程,才知道上面那一条hadoop fs -rmr xxxx究竟干了什么,究竟还有没有救,怎么去救等等问题。

hdfs文件删除过程下面是hdfs删除路径的方法,源码路径

org.apache.hadoop.hdfs.server.namenode.FSNamesystem.delete()
  boolean delete(String src, boolean recursive, boolean logRetryCache)
      throws IOException {
    waitForLoadingFSImage();
    BlocksMapUpdateInfo toRemovedBlocks = null;
    writeLock();
    boolean ret = false;
    try {
      checkOperation(OperationCategory.WRITE);
      checkNameNodeSafeMode("Cannot delete " + src);
      toRemovedBlocks = FSDirDeleteOp.delete(        // @1
          this, src, recursive, logRetryCache);
      ret = toRemovedBlocks != null;
    } catch (AccessControlException e) {
      logAuditEvent(false, "delete", src);
      throw e;
    } finally {
      writeUnlock();
    }
    getEditLog().logSync();
    if (toRemovedBlocks != null) {
      removeBlocks(toRemovedBlocks);   // @2
    }
    logAuditEvent(true, "delete", src);
    return ret;
  }

代码@1里面做了三件比较重要的事

①从NameNode维护的的目录树里面删除路径,这也是为什么执行删除操作之后就无法在通过hadoop fs -ls xxx或其它api方式再查看到路径的根本原因

②找出被删路径关联的block信息,每个文件包含多个block块,分布在各个DataNode,此时并未真正物理删除DataNode上物理磁盘上的block块

③记录删除日志到editlog(这一步也很重要,甚至是后面恢复数据的关键)

代码@2把将要删除的block信息添加到org.apache.hadoop.hdfs.server.blockmanagement.BlockManager里面维护的InvalidateBlocks对象中,InvalidateBlocks专门用于保存等待删除的数据块副本

以上步骤并未涉及真正的物理删除的操作

BlockManager

BlockManager管理了hdfs block的生命周期并且维护在Hadoop集群中的块相关的信息,包括快的上报、复制、删除、监控、标记等等一系列功能。

BlockManager中有个方法invalidateWorkForOneNode()专门用于定时删除InvalidateBlocks中存储的待删除的快,此方法会在NameNode启动时在BlockManager的内部线程类ReplicationMonitor定时轮循把要删除的块放入DatanodeDescriptor中的逻辑,方法的调用路径如下:

org.apache.hadoop.hdfs.server.namenode.NameNode#initialize(Configuration conf) 
 org.apache.hadoop.hdfs.server.namenode.NameNode#startCommonServices(Configuration conf)
  org.apache.hadoop.hdfs.server.namenode.FSNamesystem#startCommonServices(Configuration conf, HAContext haContext)
   org.apache.hadoop.hdfs.server.blockmanagement.BlockManager#activate(Configuration conf)
    org.apache.hadoop.hdfs.server.blockmanagement.BlockManager.ReplicationMonitor#run()
     org.apache.hadoop.hdfs.server.blockmanagement.BlockManager#computeDatanodeWork()
      org.apache.hadoop.hdfs.server.blockmanagement.BlockManager#computeDatanodeWorkcomputeInvalidateWork(int nodesToProcess)
       org.apache.hadoop.hdfs.server.blockmanagement.BlockManager#invalidateWorkForOneNode(DatanodeInfo dn)
        org.apache.hadoop.hdfs.server.blockmanagement.InvalidateBlocks#invalidateWork(final DatanodeDescriptor dn)

BlockManager维护了InvalidateBlocks,存放了待删除的 block,BlockManager在NameNode启动时会单独启动一个线程,定时把要删除的块信息放入InvalidateBlocks中,每次会从InvalidateBlocks队列中为每个DataNode取出blockInvalidateLimit(由配置项dfs.block.invalidate.limit,默认1000)个块逻辑在BlockManager.computeInvalidateWork()方法里会把要删除的块信息放入DatanodeDescriptor中的invalidateBlocks数组,DatanodeManager再通过DataNode与NameNode心跳时,构建删除块的指令集,NameNode再把指令下发给DataNode,心跳由DatanodeProtocol调用,方法的调用路径如下:

org.apache.hadoop.hdfs.server.protocol.DatanodeProtocol#sendHeartbeat()
 org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer#sendHeartbeat()
  org.apache.hadoop.hdfs.server.namenode.FSNamesystem#handleHeartbeat()
   org.apache.hadoop.hdfs.server.blockmanagement.DatanodeManager#handleHeartbeat()

DatanodeManager.handleHeartbeat()中构建删除的指令给DataNode,待NameNode发送,的代码如下:


  /** Handle heartbeat from datanodes. */
  public DatanodeCommand[] handleHeartbeat(形参略){
         // ....其余代码逻辑略
       //check block invalidation
        Block[] blks = nodeinfo.getInvalidateBlocks(blockInvalidateLimit);
        if (blks != null) {
          cmds.add(new BlockCommand(DatanodeProtocol.DNA_INVALIDATE,
              blockPoolId, blks));
          }
    	  // ....其余代码逻辑略
           return new DatanodeCommand[0];
      }

定时轮循+limit 1000个块删除的特性决定了hdfs删除数据并不会立即真正的执行物理删除,并且一次删除的数量也有限,所以上面的应急措施中立即停止HDFS集群是最明智的选择,虽然有的数据在轮循中已被删除,所以事发后停止HDFS集群越早,被删的数据越少,损失越小

EditLog

恢复数据的另一个关键是EditLog,EditLog记录了hdfs操作的每一条日志记录,包括当然包括删除,我们所熟知的文件操作类型只有增、删、改,但是在HDFS的领域里,远远不止这些操作,我们看看EditLog操作类型的枚举类org.apache.hadoop.hdfs.server.namenode.FSEditLogOpCodes

在这里插入图片描述

总计40多种操作类型!打破了人们印象中文件只有增删改读的几种操作,有木有突破你的想象?

EditLog长啥样呢?在hadoop的配置参数dfs.namenode.name.dir可以找到路径
在这里插入图片描述

这里EditLog文件是序列化后的二进制文件不能直接查看,hdfs自带了解析的命令,可以解析成xml明文格式,我们解析一个看看

hdfs oev -i edits_0000000000035854978-0000000000035906741 -o edits.xml

查看文件
在这里插入图片描述

对hdfs的每一个操作都会记录一串RECORD,RECORD里面不同的操作包含的字段属性也不同,但是所有操作都具备的属性是OPCODE,对应上面的枚举类org.apache.hadoop.hdfs.server.namenode.FSEditLogOpCodes中40多种操作

hdfs元数据的加载

hdfs启动时,NameNode会加载Fsimage,Fsimage记录了hdfs现有的全量的路径信息,启动过程中仅仅加载Fsimage?这句话不完全正确!启动的同时,还会加载未被合并成fsimage的EditLog。关于fsimage具体细节这里不展开。举个栗子:

假设Hadoop 3分钟checkpoint一次生成Fsimage文件,EditLog 1分钟生成一个文件,下面是依次生成的文件:

fsimage_1
editlog_1
editlog_2
editlog_3
fsimage_2
editlog_4
editlog_5

当NameNode启动时,会加载后缀时间戳最大的那个fsimage文件和它后面产生的editlog文件,也就是会加载fsimage_2、editlog_4、editlog_5进NameNode内存。假设我们执行hadoop fs -rmr xxx命令的操作记录在了editlog_5上面,那么,重启NameNode后,我们查看hdfs无法再查看到xxx路径,如果我们把fsimage_2删掉,NameNode则会加载fsimage_1、editlog_1、editlog_2,此时的元数据里面xxx还未被删除,如果此时DataNode未物理删除block,则数据可以恢复,但是editlog_4、editlog_5对应的hdfs操作会丢失。有没有更好的方法呢?

方案确定

方案一:删掉fsimage_2,从上一次checkpoint的地方也就是fsimage_1恢复,我们集群的实际配置,是一个小时生成一次fsimage文件,也就是说,这种恢复方案会导致近一小时hdfs新增的文件全部丢失,集群日工作流的的量2w左右,这一个小时不知道发生了多少事情,可想而知的后果是恢复之后一堆报错,显然不是最好的方案

方案二:修改editlog_5,把删除xxx那条操作改成其它安全的操作类型,这样重启NameNode后,又可以看到这个路径。good idea!就这么干!

四、灾难重演

为了完整的演示一遍恢复过程,我找了个测试环境重新演示一遍。请勿随意在生产环境演示!!!

bash-4.2$ hadoop fs -ls /tmp/user/hive
Found 1 items
drwxrwxrwx   - hdfs hdfs          0 2020-08-13 15:02 /tmp/user/hive/warehouse
bash-4.2$ hadoop fs -rmr -skipTrash /tmp/user/hive/warehouse 
rmr: DEPRECATED: Please use '-rm -r' instead.
Deleted /tmp/user/hive/warehouse
bash-4.2$ 
bash-4.2$ hadoop fs -ls /tmp/user/hive
bash-4.2$ 
hdfs oev -i edits_0000000000005827628-0000000000005827630 -o editlog.xml

查看editlog.xml,执行删除操作的日志已经记录在里面了
在这里插入图片描述

<RECORD>
  <OPCODE>OP_SET_OWNER</OPCODE>
  <DATA>
    <TXID>5827629</TXID>
    <SRC>/tmp/user/hive/warehouse</SRC>
    <USERNAME>hadoop</USERNAME>
  </DATA>
</RECORD>

在这里插入图片描述
注意:TXID一定要一样!!!

# 反解析更改后的xml文件成editlog
hdfs oev -i editlog.xml -o edits_0000000000005827628-0000000000005827630.tmp -p binary
# 重命名掉之前的editlog
mv edits_0000000000005827628-0000000000005827630 edits_0000000000005827628-0000000000005827630.bak
# 替换反解析后的editlog
mv edits_0000000000005827628-0000000000005827630.tmp edits_0000000000005827628-0000000000005827630
scp edits_0000000000005827628-0000000000005827630 xxx001:/hadoop/hdfs/journal/master/current/
scp edits_0000000000005827628-0000000000005827630  xxx002:/hadoop/hdfs/journal/master/current/
scp edits_0000000000005827628-0000000000005827630  xxx003:/hadoop/hdfs/journal/master/current/
bash-4.2$ hadoop fs -ls /tmp/user/hive
Found 1 items
drwxrwxrwx   - hadoop hdfs          0 2020-08-13 15:41 /tmp/user/hive/warehouse

被删除的/tmp/user/hive/warehouse目录已成功恢复!!

五、经验总结

  1. 从恢复程度来看,会有部分block块已被删除,读取时会报block missed之类的错误,但是已经把损失降到了最低,删除的多少取决于误删后停掉hdfs集群的时间,停的越早,损失越小
  2. 从预防方面,权限必须要控制好,由于线上跳板机权限给的过于随意导致了误操作的产生
  3. hdfs删数据的规范,一定不能加-skipTrash做强制删除,放入回收站,多给自己和公司一些挽回的余地
  4. 这是一次宝贵的经历,头一回感受到处理时的心弦紧绷和成功解决后的兴奋激动,事后奶茶已收到,当事人也保住了饭碗,哈哈

作者:喜剧之皇
原文链接:https://blog.csdn.net/u013289115/article/details/107987496
发布于 2020-09-01

标签:hdfs,editlog,删除,HDFS,hadoop,删库,apache,org,转载
来源: https://www.cnblogs.com/erlou96/p/14648315.html