HDFS中NN和2NN工作机制的示例分析

小编给大家分享一下HDFS中NN和2NN工作机制的示例分析，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！

1、NN工作机制

引入：当我们将数据上传到HDFS分布式系统进行存储时，通过NN存储HDFS系统中数据的元数据，DN存储真实数据，那NN中的
元数据存储在哪？

假设：a.考虑数据安全性和可靠性，NN中元数据存储在节点的磁盘中。
	--问题：访问效率很低（ 因为修改元数据是在磁盘进行修改的~IO操作）
	
      b.考虑数据操作速率，将NN中元数据存储在内存中。
	--问题：服务器宕机，停电等故障，导致元数据丢失（元数据丢失，整个集群无法工作）
	
问题：那该怎么实现高效操作元数据的情况下，还能实现内存+磁盘的维护方案
解决：HDFS通过备份fsimage(镜像文件) + edits(滚动编辑日志)的方案来解决问题
	--fsimage:NameNode内存中元数据序列化后形成的文件
	镜像文件：某个时刻对NN内存中元数据的一个快照. 镜像文件 <= NN内存中数据
	
	--Edits:记录client改元数据信息的每一步操作（可通过Edits运算出元数据）。
	 Edits文件(只进行追加操作,效率很高),将对NN中元数据的操作，以日志记录的方式存入Edits文件
		a.Edits文件随着操作的增加会越来越大，需要定期进行FsImage和Edits的合并
		b.SecondaryNamenode（2NN）专门用于FsImage和Edits的合并.

结论：磁盘和内存中均存

NN主要操作：
	 --第一次启动NN格式化后，在/opt/module/hadoop-3.1.3/data/name/current下会创建fsimage和eidts文
 件，如果不是第一次启动，则直接加载镜像文件和滚动编辑日志文件到内存
	 seen_txid:记录正在使用的编辑日志文件
	 
1) NN启动时，需要自己先将磁盘的fsimage_current+edits001_progress 文件进行一次合并. 在内存中构建好元数据信息

2) 当对HDFS进行改操作， 首先会在edits001_progress(正在使用的编辑日志)记录对应的操作，然后对NN内存中的元数据
进行相应的修改.

3) 2NN会每隔1个小时或者当 edits001_progress中已经记录了100万次的操作后，开始进行fsimage_current 和ed
its001_progress的合并

4) NN会将edits_progress进行所谓的滚动，说白了就是该文件不能再进行写入操作，会生成另外一个编辑日志文件用
于记录后续的写操作.
	  滚动正在使用的编辑日志: edits001_progress --> edits001
	  新的编辑日志: edits002_progress
   
5) 2NN 将NN中的fsimage_current 和 edits001 拷贝过来。加载到内存中进行合并. 合并完成后会生成新的fsimage_new.

6) 2NN 将fsimage_new 推送到NN中， fsiamge_current --> fsimage_old 会保留，fsimage_new -->fsiamge_
current .相当于会保留一份新的fsimage 和一份旧的fsiamge.

7) 总结: NN内存中的数据 = 磁盘上正在使用的fsimage + 正在使用的edits文件.

2、2NN工作机制

2NN主要操作：大致流程
	 a.将NN机器对应磁盘上的fsimage 和 Edits文件拉取到2NN的机器中
	 b.在2NN的机器中将fsimage + Edits都读取到内存中进行合并，然后生成新的fsimage.chkpint
在合并时，edits日志文件会重新生成一个新的，用来记录在合并时的操作
	 c.再推送到NN机器中的磁盘上，重命名成fsimage,NN中旧的fsimage会保留，新的fsimage对应的
是正在使用 

checkpoint时间设置：（触发条件）
   a.2NN每隔1小时就发送请求给NN是否需要进行checkpoint
	 [hdfs-default.xml]		--具体设置
	 
        <property>
          <name>dfs.namenode.checkpoint.period</name>
          <value>3600</value>
        </property>
		
   b.Edites文件记录操作数达到100万，进行checkpoint操作
	--2nn并不知道客户端操作了多少次nn，所以设置1分钟询问nn一次
	[hdfs-site.xml]添加如下配置：

	 <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 >

3、Fsimage和Edits

4、NN故障处理

方式一：将secondaryNameNode中的数据cp到NameNode存储数据的目录(会缺少edits_inprocess中记录的那部分数据)
	--NN存储的目录（/opt/module/hadoop-3.1.3/data/name/current）

具体操作演示：
	1、杀掉NameNode进程
		jps 查看NN运行的进程号
		kill -9 NN进程号
	2、删除name下所有内容
		rm -rf /opt/module/hadoop-3.1.3/data/name/*
	3、拷贝2NN服务器节点name下的所有内容到NN中的name目录下
		scp -r luck@swk5:/opt/module/hadoop-3.1.3/data/namesecondary/* ./name/

方式二：使用-importCheckpoint选项启动NameNode守护进程，从而将SecondaryNameNode中数据拷贝到NameNode目录中.
具体操作：
   1、修改hdfs-site.xml
	<property>
          <name>dfs.namenode.checkpoint.period</name>
          <value>120</value>
        </property>
        <property>
          <name>dfs.namenode.name.dir</name>
          <value>/opt/module/hadoop-3.1.3/data/name</value>
        </property>
		
   2、kill -9 NameNode进程
   
   3、删除NameNode存储的数据（/opt/module/hadoop-3.1.3/data/name）
   
   4、如果2NN不和NN在一个主机节点上，需要将2NN存储数据的目录拷贝到NN存储数据的平级目录，并删除in_use.lock文件
		scp -r atguigu@swk5:/opt/module/hadoop-3.1.3/data/namesecondary ./
		rm -rf in_use.lock
		pwd   --->   /opt/module/hadoop-3.1.3/data
		
   5、导入检查点数据（等待一会ctrl+c结束掉）
		bin/hdfs namenode -importCheckpoint
		
   6、启动NameNode
		hdfs --daemon start namenode

5、集群安全模式

安全模式生命周期：
1、init
	当NN刚启动~加载fsimage+edites日志文件~内存中元数据构建成功~NN开始监听DN请求，此过程中，NN处于安全
模式下，NN的文件系统对于client是只读的

2、run
	当DN启动~DN向NN发起内部通信，告知NN自己节点上DN真实块数据列表信息（安全模式下），NN收到各DN的块位
置信息之后，开始运行文件系统
	--NN中的真实数据存放位置不是由NN维护的，而是以块的形式存储在各DN节点上
	
3、safe quit：(HDFS集群系统启动完成后，自动退出安全模式)
	满足‘最小副本条件’ 安全模式退出
	--最小副本:整个文件系统中99.9%的块满足最小副本级别（默认值：dfs.replication.min=1）

安全模式具体操作：
1、--查看安全模式状态
	bin/hdfs dfsadmin -safemode get
2、--进入安全模式
	bin/hdfs dfsadmin -safemode enter
3、--离开安全模式
	bin/hdfs dfsadmin -safemode leave
4、--等待安全模式
	bin/hdfs dfsadmin -safemode wait

案例演示：
1、在/opt/module/hadoop-3.1.3/ 路径下创建脚本safemode.sh
	touch safemode.sh
2、编辑safemode.sh
	sudo vim safemode.sh    --内容是安全模式进入等待状态，并上传一个文件到HDFS系统
	
    #!/bin/bash
    hdfs dfsadmin -safemode wait
    hdfs dfs -put /opt/module/hadoop-3.1.3/README.txt /
	
3、给与safemode.sh执行权限
	chmod 777 safemode.sh
4、运行safemode.sh脚本
	./safemode.sh
5、重新打开一个xshell控制台，执行离开等待状态
	bin/hdfs dfsadmin -safemode leave
6、观察原窗口，查看原窗口hdfs的安全模式状态
	bin/hdfs dfsadmin -safemode get
	Safe mode is OFF
	safemode.sh中的上传代码执行，hdfs集群已有上传的数据

6、NN的多目录设置

--NN的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性，name1和name2可以挂载到不同磁盘（linux支
持），这样就可以保证元数据的可靠性，多目录挂载单个磁盘，没有意义，磁盘坏掉，目录也就坏掉了

--生产环境中，要提前就考虑好每个NN目录要挂载的磁盘，保证一个磁盘坏掉，其它仍然可进行读写操作
具体操作：
1、配置hdfs-site.xml文件
<property>
    <name>dfs.namenode.name.dir</name>
    <value>file:///${hadoop.tmp.dir}/name1,file:///${hadoop.tmp.dir}/name2</value>
</property>
2、停止集群，删除data和logs中所有数据(多台机器均要执行以下操作，保证数据一致性)
	stop-dfs.sh
	rm -rf /opt/module/hadoop-3.1.3/data
	rm -rf /opt/module/hadoop-3.1.3/logs	
3、格式化集群启动
	bin/hdfs namenode -format
	bin/hdfs --daemon start namenode（单个起）    start-dfs.sh(群起集群)
4、查看结果
	ll  /opt/module/hadoop-3.1.3/data

以上是“HDFS中NN和2NN工作机制的示例分析”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！