如下图，由于我在hadoop1上启动了namenode和datanode，会产生如下两个文件夹，name是namenode存放的元数据，而data是datanode存放的块的数据。
下面是存放元数据的两种重要文件，日志文件edits，快照文件fsimage
1.NN的作用 NN保存HDFS上所有文件的元数据！ NN负责接受客户端的请求！ NN负责接受DN上报的信息，给DN分配任务(维护副本数)！ 2.元数据的存储 元数据存储在fsiamge文件+edits文件中！ fsimage(元数据的快照文件) edits(记录所有写操作的文件) **如果你看了我之前写的redis教程，以上两个文件应该很好理解。** NN负责集群中所有客户端的请求和所有DN的请求！在一个集群中，通常NN需要一个高配置，保证NN 可以及时处理客户端或DN的请求，一旦NN无法及时处理请求，HDFS就已经瘫痪！ fsimage文件的产生： ①第一次格式化NN时，此时会创建NN工作的目录，其次在目录中生成一个 fsimage_000000000000文件 ②当NN在启动时，NN会将所有的edits文件和fsiamge文件加载到内存合并得到最新的元数据，将 元数据持久化到磁盘生成新的fsimage文件 ③如果启用了secondarynamenode,也会辅助NN合并元数据，会将合并后的元数据发送到NN edits： NN在启动之后，每次接受的写操作请求，都会将写命令记录到edits文件中，edits文件每间隔 一定的时间和大小滚动！当我把namenode格式化以后， 每次格式化NN，会产生一个VERSION文件 VERSION记录的是NN的集群的信息
每次格式化NN时，重新生成clusterID和 blockpoolID(会被DN领取，生成一个同名的目录，每次DN启动时，会将这个同名目录中的块上报NN)当namenode被格式化后，datanode里面的那些块也将失去意义，因为是靠元数据去找这些块的，现在元数据都没了还怎么找块？所以就将三台机子的datanode的data目录删掉，然后将namenode启动，再将三台机子的datanode启动，datanode会根据namenode重新加入集群，clusterid一定要一致。DN在第一次启动时，如果没有VERSION信息，会向配置文件中配置的NN发起请求，生成VERSION，加入到集群！(具体操作看下一个小标题的内容) 然后我们看一下namenode的version文件。 再看一下datanode的BP-128.。。。。 我们会发现namenode里的blockpoolid就是datanode存放块的文件夹的名字。
为了说明edits与fsimage,我将hadoop1的namenode格式化，然后将三台机子的datanode的数据都删掉，重新搭建一个集群。() 然后我们看一下namenode里的元数据，就只有fsimage了，因为恢复到了出场设置，我还没对该hdfs做写操作，所以没有edits文件产生。 下面我们将之前三个datanode的data目录删掉，然后启动datanode，然后会重新同步格式化后的namenode，产生新的data目录。(secondarynamenode的version所在的那个secondname文件夹也删掉吧，要保证集群号一致，所以就让它重新生成) 然后运行namenode。 然后群起三台机子的datanode。 然后看一下namenode的情况，发现已经有edits文件产生了。 然后上传一个文件abc.txt 然后查看edits文件用以下命令，也就是将该edits文件以xml形式输出。 如下图，我们可以很清楚的看到edits文件里做了什么事，它保存了我们做的写操作。 edits手动滚动：(edits可以自动滚动，但是我这数据量少，我就手动滚动来演示一下) 我们可以看到直接滚动到编号为9的edits日志文件上了，也就是所我下一次对hdfs做了写操作，是从第9个edits开始记录的 fsimage也可以手动滚动，也可以自动，我们演示手动。
经过之前的操作，我们发现重启namenode后，会自动把最新的fsimage和edits合并，然后checkpoint就是合并的那一个时间点。 然后我们来看看fsimage里是什么样的。 NN的元数据分两部分： ①inodes : 记录在fsimage文件中或edits文件中 ②blocklist: 块的位置信息（每次DN在启动后，自动上报的） 如上图，红框部分是保存在fsimage里的，而Availability是各节点自动上报的。
NN的启动过程 ①先加载fsimage_000000xx文件 ②将fsimage文件xx之后的edits文件加载 ③合并生成最新的元数据，记录checkpoint，如果满足要求，执行saveNamespace操作，不满足等满足后执行 saveNamespace操作必须在安全模式执行
④自动进入安全模式，等待DN上报块 DN上报的块的最小副本数总和 / 块的总数 > 0.999,自动在30s离开安全模式！ 安全模式只能有限读，不能写！wait命令是进入安全模式后执行，可以将写命令缓存起来当我结束安全模式之后，将缓存的写命令自动执行。
Fsimage：NameNode内存中元数据序列化后形成的文件。 Edits：记录客户端更新元数据信息的每一步操作（可通过Edits运算出元数据）。 NameNode启动时，先滚动Edits并生成一个空的edits.inprogress，然后加载Edits和Fsimage到内存中，此时NameNode内存就持有最新的元数据信息。Client开始对NameNode发送元数据的增删改的请求，这些请求的操作首先会被记录到edits.inprogress中（查询元数据的操作不会被记录在Edits中，因为查询操作不会更改元数据信息），如果此时NameNode挂掉，重启后会从Edits中读取元数据的信息。然后，NameNode会在内存中执行元数据的增删改的操作。 由于Edits中记录的操作会越来越多，Edits文件会越来越大，导致NameNode在启动加载Edits时会很慢，所以需要对Edits和Fsimage进行合并（所谓合并，就是将Edits和Fsimage加载到内存中，照着Edits中的操作一步步执行，最终形成新的Fsimage）。SecondaryNameNode的作用就是帮助NameNode进行Edits和Fsimage的合并工作。 SecondaryNameNode首先会询问NameNode是否需要CheckPoint（触发CheckPoint需要满足两个条件中的任意一个，定时时间到和Edits中数据写满了）。直接带回NameNode是否检查结果。SecondaryNameNode执行CheckPoint操作，首先会让NameNode滚动Edits并生成一个空的edits.inprogress，滚动Edits的目的是给Edits打个标记，以后所有新的操作都写入edits.inprogress，其他未合并的Edits和Fsimage会拷贝到SecondaryNameNode的本地，然后将拷贝的Edits和Fsimage加载到内存中进行合并，生成fsimage.chkpoint，然后将fsimage.chkpoint拷贝给NameNode，重命名为Fsimage后替换掉原来的Fsimage。NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可，因为合并过的Edits中的元数据信息已经被记录在Fsimage中。
（1）通常情况下，SecondaryNameNode每隔一小时执行一次。 <property> <name>dfs.namenode.checkpoint.period</name> <value>3600</value> </property > （2）一分钟检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次。 <property> <name>dfs.namenode.checkpoint.txns</name> <value>1000000</value> <description>操作动作次数</description> </property> <property> <name>dfs.namenode.checkpoint.check.period</name> <value>60</value> <description> 1分钟检查一次操作次数</description> </property >恢复： 如果我把namenode的current目录删了，那么元数据就找不到了，但是我可以将secondarynamenode的current目录原封不动的复制过来，这可以回复一部分元数据。恢复多少取决于你的运气，如果secondarynamenode恰好刚刚做了一次合并，那么就很棒了，你就可以找回所有数据。 备份： 我直接一开始就给namenode多配置一个目录用来存元数据。
