HDFS之namenode 与secondarynamenode元数据checkpoint机制

2019独角兽企业重金招聘Python工程师标准>>>

  对于hdfs中的namenode，是非常重要的一环。今天闲来，深入了解一下namenode和 secondary namenode机制和原理。

1.     NAMENODE职责：

        负责客户端请求的响应

        元数据的管理（查询，修改）

    2.    元数据管理

        namenode对数据的管理采用了三种存储形式：

        内存元数据(NameSystem)

        磁盘元数据镜像文件

        数据操作日志文件（可通过日志运算出元数据）

    3.    元数据存储机制

            A、内存中有一份完整的元数据(内存meta data)

            B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)

            C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits文件）注：当客户      端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功          后，相应的元数据会更新到内存meta.data中。

        可以通过hdfs的一个工具来查看edits中的信息

    bin/hdfs oev -i edits -o edits.xml

  bin/hdfs oiv -i fsimage_0000000000000000087 -p XML -o fsimage.xml

    4.      元数据的checkpoint

        每隔一段时间，会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程称为checkpoint）。

    checkpoint 的详细过程

    

        详细解读这个过程：

        1.如果客户端涉及到元数据的更新（读数据不算更新，比如更改文件的名称、路径等、删除文件，增删改操作）。注意客户端不能更改文件内容，顶多可以追加操作。会有操作日志到NameNode的记录日志中。

        2.随着元数据的操作记录日志增多，secondary NameNode 也会定期的去请求NameNode是否需要checkpoint.

        3.如果得到应答，namenode会滚动当前的日志edits.inprogress,将当前记录的edits和namenode中的fsimage下载到secondary namenode中。

      4.secondary namenode会将其两者加载到内存合并，dump成新的image文件，重新上传到namenode中，重命名为新的fsimage.

       5.这里要注意的是，checkpoint时，会把正在写的edits滚动一下，然后将fsimage和日志下载到secondary namenode机器，只有第一次hdfs初始化时才下载fsimage,这时的文件操作没有那么大的数据量。以后只负责下载日志文件，合并旧的fsimage。

         6. 这样两者之间的元数据镜像差距始终保持在范围很小的差距。

        我通过实验，在NameNode工作时，将日志和fsimage都删除，依然都能工作。

        结论：NameNode工作的时候元数据的查询都是找内存。并不会找fsimage和edits。

        那这两个数据都是用来干嘛？

        答案：主要是用来持久化，如果说NameNode宕机，内存中没有元数据，那hdfs重新启动的时候。数据就从fsimage和edits这两个文件中加载。

        namenode和secondary namenode的工作目录存储结构完全相同，所以，当namenode故障退出需要重新恢复时，可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录，以恢复namenode的元数据。

        checkpoint出发条件：

                        1.设置默认时间

                        2.edits中记录数据

        

    

转载于:https://my.oschina.net/LiuLangEr/blog/856847