HDFS：元数据持久化

补充

• 日志文件
  • 操作

    • 记录实时发生的增删改的操作：mkdir /abc

  • 优点
    • 完整性比较好
  • 缺点
    • 加载恢复数据：慢、占空间
  • 方式
    • append 向文件追加内容、实时
  • 比如
    • 内存4G、运行10年
    • 断电后进行恢复可能需要5年
    • 内存不会溢出
  • 注
    • 日志容量过大，可能需要5年时间恢复，明显不适合单独使用日志
• 镜像、快照、dump、db
  • 操作

    • 内存全景数据基于某一个时间点做的向磁盘的溢写

  • 优点
    • 恢复速度快过日志文件
  • 缺点
    • 由于是间隔，容易丢失一部分数据
  • 方式

    • 间隔（小时、天）（相对合适，需要考虑 I/O 慢）

  • 比如
    • 假设容量400MB上限，当满的时候就删

HDFS采用两种日志合并方式

• 日志文件
  • EditsLog
    • 当体积、记录少时有优势
• 镜像/快照
  • FsImage
    • 若能更快的滚动更新时点的数据有优势（半小时、1小时）
• SecondaryNameNode（合并日志）
  • 优势
    • 最近时点 FsImage + 增量 EditsLog
    • 方式
      • 当前10点，FsImage 9点 + 9点 - 10点的增量 EditsLog，断电后
        • 加载 FsImage
        • 加载 EditsLog
    • 问题

      • FsImage  时点是怎么滚动更新的？

        • NameNode 8点溢写，1小时后，9点溢写（但会导致 I/O出现问题）

        • 假设8点时，第一次开机，只写一次 FI，到9点时，只需要将 EL 8点到9点的日志记录写入到 FI 中，FI 的数据就会更新成9点 

      • 读取一个 EL 日志，再读 FI，内存再进行追加，再重新写一个完整的 FI，其实并没有效率

    • 解
      • 需要寻求另一台机器进行合并的工作，此时 NameNode 可专注自身服务当中
  • 备注
    • 在非 Ha 模式下，SNN 一般是独立的节点，周期完成对 NameNode 的 EditLog 向 Fslmage 合并，减少 EditLog 大小，减少 NameNode 启动时间
    • 根据配置文件设置的时间间隔 fs.checkpoint.period 默认3600秒
    • 根据配置文件设置 editslog 大小 fs.checkpoint.size 规定 edits 文件的最大值默认是64MB
    • 图解说明（方式过于简易，企业不使用）
    •