Hadoop-HDFS之Namenode操作及原理

Namenode

Namenode的元数据存储

如下图，由于我在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文件

为了说明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是各节点自动上报的。

Namenode的安全模式

NN的启动过程
①先加载fsimage_000000xx文件
②将fsimage文件xx之后的edits文件加载
③合并生成最新的元数据，记录checkpoint，如果满足要求，执行saveNamespace操作，不满足等满足后执行
saveNamespace操作必须在安全模式执行

④自动进入安全模式，等待DN上报块
		DN上报的块的最小副本数总和 / 块的总数  > 0.999,自动在30s离开安全模式！
		
		安全模式只能有限读，不能写！

wait命令是进入安全模式后执行，可以将写命令缓存起来当我结束安全模式之后，将缓存的写命令自动执行。

SecondaryNamenode原理

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多配置一个目录用来存元数据。