Hadoop(二)——HDFS

一、 主从结构

1.1主节点：NamenNode 

• 接收用户操作请求

• 维护文件系统的目录结构

• 管理文件与block之间关系，block与datanode之间关系

1.2 从节点：DataNode

• 存储文件

• 文件被分成block存储在磁盘上

• 为保证数据安全，文件会有多个副本

1.3 Secondary NameNode：

• 合并fsimage和edits文件来更新NameNode的metedata
• fsimage：它是在NameNode启动时对整个文件系统的快照
• edit logs：它是在NameNode启动后，对文件系统的改动序列

1.3.1 Secondary NameNode的作用

1.3.2 产生原因

• 只有当NameNode重启时，edit logs才会合并到fsimage文件中，从而得到一个文件系统的最新快照。
• 但是在产品集群中NameNode是很少重启的，这也意味着当NameNode运行了很长时间后，edit logs文件会变得很大。这种情况下，就会出现下面一些问题：

        1)edit logs文件会变的很大，怎么去管理这个文件是一个挑战。
        2)NameNode的重启会花费很长时间，因为有很多改动要合并到fsimage文件上。
        3)如果NameNode挂掉了，那我们就丢失了很多的改动，因为此时的fsimage文件非常旧。

• 因此为了克服这些问题，我们需要一个易于管理的机制来帮助我们减小edit logs文件的大小和得到一个最新的fsimage文件，这样也会减小NameNode的压力.
• Secondary NameNode就是来帮助解决上述问题的，他的职责是合并NameNode的edit logs到fsimage文件中。

1.3.3 流程

1. 首先，它定时到NameNode去获取edit logs，并更新到自己的fsimage上。
2. 一旦它有了新的fsimage文件，将其拷贝会NameNode中。
3. NameNode在下次重启时会使用这个新的fsimage文件，从而减少重启的时间。

1.3.4 总结    

总得来说，Secondary NameNode是在HDFS中提供一个检查点，是NameNode的一个助手，用来定时更新fsimage，可以称它为检查点节点。

1.3.5 利用secondary namenode来恢复挂掉的namenode

• 模拟：kill 掉namenode，然后删掉namonode下面数据/opt/mydata/hadoop/tmp/dfs/name
• 启动start-dfs.sh

报错：
org.apache.hadoop.hdfs.server.common.InconsistentFSStateException: Directory /opt/mydata/hadoop/tmp/dfs/name is in an inconsistent state: storage directory does not exist or is not accessib

• 解决：

    1）压缩secondarynamenode上的数据 
          tar -czvf namesecondary.tar.gz namesecondary
    2）拷贝到namenode上 
          scp namesecondary.tar.gz master:/opt/mydata/hadoop/tmp/dfs/
    3）解压 
          tar -xf namesecondary.tar.gz
    4）重命名 
          mv namesecondary name
    6）启动 
         start-dfs.sh 

    7）注意

        不一定会保存最新的一次改动，因为secondarynamenode是根据时间或者edit log超过指定大小才(可在配置文件中配置)来更新才来同步数据更新的

1.3.6 参考链接：

1. Secondary NameNode的作用 

     https://blog.csdn.net/jenrey/article/details/80738389

1. 模拟利用secondary namenode来恢复挂掉的namenode 

      https://www.cnblogs.com/prayer21/p/4835272.html