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