合并元数据的原因

首先要知道磁盘和内存中都保存有元数据，磁盘中的原数据是由正在编辑的日志文件(edits_inprogress)和镜像文件(fsimage)组成。

当客户端发送增删改的请求，由于磁盘的读写比较慢，不能及时地修改镜像文件中的目录树结构，所以会先将请求写入到edits_inprogress文件中(追加写入)，记录下请求。然后将请求发送到内存中，这时会及时地修改元数据中的目录结构，所以内存中的元数据永远是最新、最完整的。

时间一长，内存中的元数据信息就和磁盘中的元数据信息相差越来越大，所以需要将磁盘中的镜像文件和正在编辑的日志文件定期合并。

元数据合并流程

1. 客户端发送增删改请求，比如：hadoop fs -mkdir /test。会先将请求写入磁盘的正在编辑的日志文件中(edits_inprogress)。

2. 然后将请求写入内存，这时，内存中的元数据会及时地被修改。即会在根目录下创建一个test目录，这时我们刷新hdfs的文件系统界面就会看到生成了一个test目录。

3. SecondaryNameNode定期地向NameNode发送合并元数据的请求，这时，NameNode会检查合并元数据的条件是否满足，如果满足就开始合并元数据。触发元数据合并的条件如下：

   <!--时间间隔：3600s=1h-->
   <property>
     <name>dfs.namenode.checkpoint.period</name>
     <value>3600</value>
     <description>The number of seconds between two periodic checkpoints.
     </description>
   </property>
   
   <!--元数据条数：1000000条-->
   <property>
     <name>dfs.namenode.checkpoint.txns</name>
     <value>1000000</value>
     <description>The Secondary NameNode or CheckpointNode will create a checkpoint
     of the namespace every 'dfs.namenode.checkpoint.txns' transactions, regardless
     of whether 'dfs.namenode.checkpoint.period' has expired.
     </description>
   </property>
   

   以上两个条件只要满足一个就开始合并元数据。

4. 如果合并元数据的条件满足，NameNode会将正在编辑的日志文件回滚，形成历史日志文件。比如上图中，将edits_inprogress_07回滚为edits_07文件。

5. SecondaryNameNode会从NameNode节点将历史日志文件和镜像文件拉取到自己的节点。
   这里要注意的一点是，如果不是第一次进行元数据合并，那么这次拉取的日志文件是编号从合并点记录的日志文件编号开始到最新回滚的日志文件编号之间的所有日志文件，不需要全部将日志文件拉取过来，并且也不需要再拉取镜像文件。

   举个栗子，假如合并点文件(seen_txid)记录的编号是7，那么就只需要把回滚出来的edits_07文件拉取到SecondaryNameNode节点。

   如果是第一次合并元数据，那么就需要将所有的日志文件数据和镜像文件一起拉取到SecondaryNameNode。

6. SecondaryNameNode将日志文件和镜像文件拉取到内存中进行元数据合并。合并的过程其实就是根据日志文件中记录下来的增删改操作改变镜像文件中的元数据信息(目录结构)。

7. 合并完成之后，SecondaryNameNode将合并完成的镜像文件(fsimage.checkpoint)发送给NameNode，并且自己也会保留一份到磁盘。

8. NameNode会将fsimage.checkpoint文件重命名为fsimage文件，并且替换掉原来的fsimage文件。

元数据合并的注意事项

在没有达到checkpoint条件的这段时间，如果集群正常关闭，那么这个时候内存中的元数据在集群关闭前会dump到磁盘。举个栗子，当我们在hdfs根目录下创建了test目录之后正常关闭集群，再次启动之后，会发现我们创建的test目录仍然存在，就是因为内存中的元数据dump到了磁盘。