脚本宝典收集整理的这篇文章主要介绍了NameNode 和SecondaryNameNode的工作机制，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

　　思考：nameNode中元数据的是存在哪里的呢？

　　有两个可能，一个是存在磁盘中，另一个可能是存在内存中。如果存在磁盘中的话，效率比较低  ，因为需要经常的随机访问还要给出对应的响应到客户。如果吃存到内存中，一旦断点元数据就会丢失，集群则无法正常的工作。因此我们可以把两者结合，在磁盘中备份元数据  FSImage.

　　新问题来了。如果内存中数据更新的时候同时在磁盘中备份数据，会导致效率降低，如果不更新就导致数据一致性。一旦NameNode断点会导致数据丢失。

　　HDFS有一个特性是修改比较慢的特征，此时产生一个新的文件  EdITs文件，只追加信息。当元数据有变动的时候，修改内存中元数据并追加到Edits中。如果NameNode节点断电会合并FSImage和Edits文件，如果数据过大断电的时候合并依然由NameNode进行，就会浪费时间，所以会定期的对两个文件进行合并，且这个操作交由SecondaryNameNode来操作。

 第一 阶段：NameNode 启动    （1）第一次启动 NameNode 格式化后，创建 Fsimage 和 Edits 文件。如果不是第一次启         动，直接加载编辑日志和镜像文件到内存。    （2）客户端对元数据进行增删改的请求。    （3）NameNode 记录操作日志，更新滚动日志。    （4）NameNode 在内存中对元数据进行增删改第二 阶段：Secondary NameNode 工作    （1）Secondary NameNode 询问 NameNode 是否需要 CheckPoint。直接带回 NameNode        是否检查结果。    （2）Secondary NameNode 请求执行 CheckPoint。    （3）NameNode 滚动正在写的 Edits 日志。    （4）将滚动前的编辑日志和镜像文件拷贝到 Secondary NameNode。    （5）Secondary NameNode 加载编辑日志和镜像文件到内存，并合并。    （6）生成新的镜像文件 fsimage.chkpoint。    （7）拷贝 fsimage.chkpoint 到 NameNode。    （8）NameNode 将 fsimage.chkpoint 重新命名成 fsimage

脚本宝典总结

以上是脚本宝典为你收集整理的NameNode 和SecondaryNameNode的工作机制全部内容，希望文章能够帮你解决NameNode 和SecondaryNameNode的工作机制所遇到的问题。

如果觉得脚本宝典网站内容还不错，欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。