关于HDFS的持久化

Secondary — 持久化

流程图

---

为什么持久化
在集群中datanode接收客户端的数据时，由于一些突发事件而中断数据流，这时数据会流失，所以我们要在重选启动后恢复之前的数据，持久化会定时或者按照大小将元数据保存在磁盘中，当重新启动后namenode会自动从磁盘中读取之前的数据并恢复。

---

执行持久化

持久化是由secondaryNamenpde去操作

原因：

1. 当需求较小，且占用内存少，又不影响计算效率时，可以由namenode去做，但是最好不要namenode去做。
2. namenode本身的工作已经很多，极有可能会在操作持久化的过程中宕机，进而引发更大的隐患。

SecondaryNamenode

永远也不能取代Namenode，他是Namenode的一个热备（当Namenode运行的时候还能工作）。

持久化的进行

  在系统运行的时候会产生一个操作信息的日志edits.log（操作日志）以及元数据的镜像文件fsimage

   当操作信息达到64M（默认，可修改）或者3600s后（默认，可修改），namenode会生成一个操作日志，生成后会与镜像文件（fsimage）一起被拖到SecondaryNamenode中，Secondary Namenode将这2个文件合并成一个新的日志文件（edits），在返回到name node中，循环进行这个操作

  特殊情况：

1.个别现象：在SecondaryNamenode合并edtis与fsimage时，edtis又因为超过默认的64M而又生成了，这个时候SecondaryNamenode还没有合并完成之前的，此时，namenode会在生成一个新的空操作日志（edits）接收后面的操作日志，SecondaryNamenode会将为合并完全的操作日志与镜像文件强行返回namenode与之前生成的edtis合并，合并完成后的fsimage在返回到namenode。

2.常态现象：如果经常发生特殊情况时，请及时更改edits的默认大小

   突发事件发生在持久化之前--- 再次启动,读取系统日志

   突发事件发生在持久化之后--- 读取磁盘中的数据，恢复状态

## 心跳机制

   心跳机制：每隔3s，dataname会向namenode发送一次心跳，长达1分钟没有心跳时，则默认为datanode挂掉

---

重复的突发事件

安全模式

1. 恢复系统的状态
2. 检查datanode的信息
3. 有问题的dataname进行修复
   1. 在传输的过程中断电—数据丢失（如果数据特别的重要，要进行预判，进行相应的调整与保存）
   2. 传输完成后断电—当我的集群重选恢复后，namenode回去读取元数据，队状态进行相应的恢复
   3. 在dataname恢复后，有新的任务，根据情况，确认是否将新的文件上传

重新启动后有dataname挂掉

  栗子：   上传block时候datanode3挂掉，这个时候之前的上传任务不会在上传，当datanode3恢复后会被namenode识别成是一个新的节点（此时不会在这个节点中写入block），重新传文件的时候才会在这个datanode3中写入block，而之前datanode3挂掉的数据，会在datanode1,2中寻找备份

---

仅供参考