分析edits、fsimage、edits_inprogress、文件系统元数据维持原理，这一篇文章就够了~
本文较长的日志分析，运行分析，请耐心观看，仔细观看每一张图片中的文件后缀名
截图较小，请放大网页观看，快捷键ctrl＋鼠标滚轮缩放网页大小
格式化集群，启动集群
此时的文件状态
执行了-put和-ls操作后关闭集群
此时的文件状态
再次开启集群时文件状态
现在执行一次滚动操作
现在的文件状态
效果不太明显 再传一份文件上去
现在的文件状态不变 所以我们执行一次滚动操作，查看文件状态
现在只是在滚动Edits文件，fsimage还没有进行合并
我们再滚动一次查看文件状态
现在要进行手动合并操作，这里合并失败了，原因是没有开启安全模式
这个安全模式：是hadoop自带的安全模式，相当于给hadoop部分文件上了一把锁，保证了合并数据的时候，数据的完整性。只有开启安全模式才可以执行手动合并操作，我们先看一下安全模式的状态
开启安全模式
我们再次执行手动合并
再次查看文件状态
我们看一下secondaryNameNode查看文件状态，发现人为滚动和合并的操作并没有存储在SNN，只有由SNN主动合并的edits和fsimage才存在该节点上，
建议不要进行手动合并和滚动日志的原因：如果NameNode Down掉了，SNN上是没有最新的镜像和日志的，不能将其作为恢复完全文件系统状态的根本
进行数据恢复的操作，将NameNode上的Name文件夹删除，再次之前，我们为了避免风险，将name文件夹上传至HDFS系统（须解除安全模式）
然后我们将name文件夹转移至~目录做两手保险，在做这步之前应当将集群停掉
而后开启集群会发现 我们的NameNode没有启动
然后我们进入secondaryNameNode节点将secondaryName拷贝至name原来的位置
Exit 回到 node101节点 将secondaryName改名为name，将name里面的.lock文件删除
关闭集群再启动集群
集群的所有进程正常启动，我们访问一下webUI
发现在刚才这段时间内创建的/home/bduser和传上去的name文件夹都不见了
原因：在secondaryNameNode中一直没有进行合并日志的操作，所以secondaryNameNode中的edits和fsimage文件还停留在我们进行第一次滚动日志之前的状态
下面的这张current文件夹的内容截图和上面最开始第二次启动集群的截图相同
所以这样做数据恢复是会有丢失的指的是滚动日志和手动合并的edits和fsimage文件，但如果我们在前面没有进行滚动日志和手动合并操作的话，一样还是会丢失一部分edits文件和edits_inprogress文件。
把集群停了之后把name删掉，把以前的name还原回来
查看edits和fsimage文件状态
在这里我觉得应该是少截了一张在将name文件删除之前的图，那张图应该是有名为edits_inprogress_000000000030的文件，这个文件里的日志是我们在进行更改name为SecoName之前的一系列操作，包括将name上传至集群等等，所以在这次还原后开启集群，之前的edits_inprogress_000000000030的文件滚动为edits_000000030-000000118，同时新建edits_inprogress_0000000000119，这个30-118文件和最新的fsimage00000000029会一起读到内存中呈现最新的文件系统
看webUI即可得知。
看一下seen_txid
（看到这先停一下，思考如果现在的SecondaryNameNode做了一次chekpoint操作，文件状态应该是什么样的）
这时我们进行一次手动合并试一下
大家一定会有这个疑惑，这次合并应该是edits_00030-edits000118，edits_inprogress000119
fsimage_00029合并为fsimage120啊 为什么会有122呢，原因其实很简单 我们看一下secondaryNameNode上的文件
得出结论，我们在这次手动合并之前，secondaryNameNode已经进行了一次chkpoint操作
当secondaryNamenode进行完chkpoint操作之后，NameNode的文件状况应当是
（ editsxxx-xxx
editsxxx-xxx
edits119-120
exits_inprogress_000121
fsimage120）
，所以我们这次手动合并的文件会是fsimage_120，edits_000121，所以才会有以下的结果
（执行手动合并，edits_inprogress000121将滚动更名为edits_000122）