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

引入：当我们将数据上传到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文件.

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 >

方式一：将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

安全模式生命周期： 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集群已有上传的数据

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

1、NN工作机制

2、2NN工作机制

3、Fsimage和Edits

4、NN故障处理

5、集群安全模式

6、NN的多目录设置

相关阅读