扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
小编给大家分享一下HDFS中NN和2NN工作机制的示例分析,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!
成都创新互联公司专注于企业网络营销推广、网站重做改版、前进网站定制设计、自适应品牌网站建设、H5建站、电子商务商城网站建设、集团公司官网建设、外贸营销网站建设、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为前进等各大城市提供网站开发制作服务。
引入:当我们将数据上传到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] --具体设置b.Edites文件记录操作数达到100万,进行checkpoint操作 --2nn并不知道客户端操作了多少次nn,所以设置1分钟询问nn一次 [hdfs-site.xml]添加如下配置: dfs.namenode.checkpoint.period 3600 dfs.namenode.checkpoint.txns 1000000 操作动作次数 dfs.namenode.checkpoint.check.period 60 1分钟检查一次操作次数
方式一:将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.xmldfs.namenode.checkpoint.period 120 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 dfs.namenode.name.dir /opt/module/hadoop-3.1.3/data/name
安全模式生命周期: 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文件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 dfs.namenode.name.dir file:///${hadoop.tmp.dir}/name1,file:///${hadoop.tmp.dir}/name2
以上是“HDFS中NN和2NN工作机制的示例分析”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注创新互联行业资讯频道!
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流