secondary namenode元数据checkpoint机制

将机制前先明确下面的几点

namemode保存的元数据是在内存中的

namenode一般有128G

一个元数据大小为150B，记录一个块（0-128M）。所以hadoop不适用存储一个小文件。

secondary  namenode也是在内存中操作

 

secondarynamenode元数据checkpoint机制

当客户端不断发出命令的时候，namenode都做了什么？

打个比方说：现在客户端发出一串下面的命令

上传文件：/aaa.txt

修改文件   /aaa.txt    to  /bbb.txt

修改文件   /bbb.txt    to  /ccc.txt

修改文件   /ccc.txt    to  /ddd.txt

上传文件：/1.d

1：namenode记录/aaa.txt的元数据

2： namenode记录/1.d的元数据

3：namenode将上面的命令记录在操作日志中（edits）。

为什么是edits？下面的图可以解释

 

在上面的操作中secondary  namenode做了什么？

1 secondary  namenode和namenode之间存在一种类似心跳检查机制，secondary  namenode会时常问namenode要不要来一次edits文件合并（checkpoing）。

2 namenode收到secondary  namenode的提问，刚好现在namenode需要来一次edits文件合并(checkpoing),就告诉对方说，我需要，为了这个事情，我们同时把管道建立起来吧。

3 namenode生成一个新的edits(滚动实现)，将所有旧的edits文件和镜像文件（fsImage）一起打包通过管道发给secondary  namenode。

4 secondary  namenode收到来自于namenode的所有edits文件和镜像文件（fsImage）。这个时候，他在内存中做了合并操作。

怎么合并？比如说刚刚什么的一系列命令

上传文件：/aaa.txt

修改文件   /aaa.txt    to  /bbb.txt

修改文件   /bbb.txt    to  /ccc.txt

修改文件   /ccc.txt    to  /ddd.txt

上传文件：/1.d

合并后

上传文件：/aaa.txt

修改文件   /aaa.txt    to  /ddd.txt

上传文件：/1.d

这样操作后，大幅度减少edits文件的多余命令，放在down机重启的时候，要解析很多edits文件和fsImage文件。因为做了合并操作

5合并后，生产一个fsImage文件，通过管道覆盖namenode的fsImage文件。

6结束，继续间隔一段时间问namenode是否需要做合并操作（说白了和redis AOF的重写AOF文件一样）