Hdfs学习(edits日志文件和fsimage文件)

edits文件(编辑日志)

文件名前缀：edits
文件名后缀：该文件存储的事务ID
文件系统客户端执行写操作时,这些事务首先会记录到edits日志中

fsimage（镜像文件）

每个fsimage文件存储的都是文件系统元数据信息(文件及目录结构 组成文件的块的信息 副本数量信息)，如果namenode发生故障，最近的fsimage文件会被载入到内存中，用来重构元数据的最近状态，再从相关点开始向前执行edits日志文件中记录的每个事务

数据块Block存储在datanode中，但是fsimage文件中并不描述block和datanode的映射关系，取而代之的是，namenode将这种映射关系存储在内存中，这种映射关系通过datanode向namenode发送最新的块列表信息，使namenode在内存中生成这种映射关系。

安全模式

NameNode启动过的时候，会先将fsimage文件中的元数据加载到内存中，并执行编辑日志中的各项操作。一旦在内存中建立文件系统元数据的映像，则创建一个新的fsimage文件和一个空的edits文件，在这个过程中namenode运行在安全模式下。
系统中数据块的位置并不是由namenode维护的，而是以块列表的形势存储在datanode中，在安全模式中，datanode会向namenode发送最新的块列表信息，namenode在内存中建立一块和datanode的映射关系， namenode了解到足够多的块位置信息之后，namenode会对外提供服务。

fsimage和edits合并实现原理

为什么要合并？

在NameNode运行期间，客户端对HDFS的写操作都保存到edits文件中，久而久之edits文件会变得很大，虽然这对NameNode运行的时候是没有影响的，但是在NameNode重启的时候，NameNode先将fsimage中的内容映射到内存中，然后再一条一条执行edits编辑日志中的操作当edits文件非常大的时候会导致namenode启动的时间非常漫长，而在这段时间中HDFS处于安全模式，所以需要在Namenode运行的时候将edits和fsimage定时进行合并，减小edits文件的大小。

Hadoop1.x版本的合并原理是不同的

达到合并的条件：
1、时间：如果距离上一次合并超过指定时长(3600秒)，就会出发合并
2、大小条件：如果edits文件达到64MB会触发合并
上述两个条件都可以通过配置文件来进行设置

Hadoop1.x版本

1. SecondaryNameNode会定时的和NameNode通信，请求其停止使用edits文件，暂时将新的写操作写到一个新的文件edits.new上，这个操作是瞬时完成的，上层的写日志函数完全感觉不到差别
2. SecondaryNameNode通过HTTP的get方法从NameNode上获取到fsimage和edits文件，SecondaryNameNode将fsimage文件载入内存中，逐一执行edits文件中的事务，创建新的合并后的fsimage文件，使得内存中的fsimage保存最新。
3. SecondaryNameNode执行完2之后，会通过post方法将新的fsimage文件发送到NameNode节点上
4. NameNode将从SecondaryNameNode接收到的新的fsimage文件保存为.ckpt文件
5. NameNode重新命名fsimage.ckpt为fsimage替换旧的fsimage文件，同时将edits.new替换edits文件，通过这个过程edits文件就变小了。

最终，主NameNode拥有一个最新的fsimage文件和一个小的edits文件，edits文件可能不为空，因为在合并期间，namenode可能还接收到了一些编辑请求，被写入新的edits文件中，因此secondaryNameNode也不能作为NameNode的热备份，因为SecondaryNameNode中的fsimage文件中的内容不是最新的，但是也可以在NameNode宕机的时候作为数据恢复，减少数据丢失。

Hadoop2.x版本

在Hadoop 2.x中解决了NameNode的单点故障问题，同时已经不用SecondaryNameNode了。
在Hadoop 2.x版本中提供了NameNode HA机制，通过配置奇数个JournalNode来实现HA,在hdfs-site.xml文件中配置如下
HA机制通过在同一个集群中运行两个NameNode（active和standby）来解决NameNode的单点故障问题，在任何时间只有一台机器处于Active状态；另一个集群则是处于standby状态，Active NameNode负责集群中所有客户端你的操作，而Standby NameNode主要用于备用，它主要位置足够的状态，如果必要可以提供快速的故障恢复。

为了让Standby NameNode的状态和Active NameNode保持同步，即元数据保持一致，它们都将会和journalNodes守护进程通信，当Active NameNode执行任何有关命名空间的修改，它需要持久化到一半以上的JournalNodes上(通过edits log持久化存储)，而Standby NameNode负责观察edits log的变化，它能够从JournalNodes中edits信息，并更新到其内部的 命名空间，一旦Actiuve NN出现故障，Standby 将会保证从JournalNodes中读取出了全部的edits，然后切换成Acitve状态， Standby NN读取完全部的edits可确保发生故障转移前，是和Active NN拥有完全同步的命名空间状态。

这种机制如何实现fsimage和edits的合并？
在standby NN节点上会一直运行一个叫做CheckpointerThread的线程，这个线程调用StandbyCheckpointer类的doWork()方法，而doWork方法会每隔Math.min(checkpointCheckPeriod,checkpointPeriod)秒来做一次合并操作。
合并的过程：

1. Standby NN检查是否达到checkPoint条件
2. 检查达到checkPoint条件后如果成立会合并fsimage和edits文件，以fsimage.ckpt_txid格式保存到SBNN的磁盘上，并且随之生成一个MD5文件。然后将该fsimage.ckpt文件重命名为fsimage。
3. 然后 Standby NameNode通过HTTP练习Active NameNode
4. Active NameNode通过HTTP从 Standby NameNode获取最新的fsimage文件并保持为fsimage.ckpt_txid，然后也生成一个MD5文件，与 Standby NameNode的MD5文件进行比较，确认收到了正确的fsimage文件，然后将文件重命名为fsimage_txid文件，将旧的fsimage和edits文件清理掉；
5. 通过上面的几步，fsimage和edits文件就完成了合并，由于HA机制，会使得Standby NameNode和Active NameNode都拥有最新的fsimage和edits文件（之前Hadoop 1.x的SecondaryNameNode中的fsimage和edits不是最新的）