一、問題描述 某生產環境中發現YupDB執行的Hadoop叢集中有個datanode不能正常啟動，檢視datanode的日誌發現：

org.apache.hadoop.util.DiskChecker$DiskErrorException: Too many failed volumes - current valid volumes: 11, volumes configured: 12, volumes failed: 1, volume failures tolerated: 0

原因是該datanode有一塊磁碟不能正常讀寫，而叢集中配置了每個節點最大允許磁碟損壞的數量為0，導致不能正常啟動。hdfs-site.xml中相關配置如下：

<property>
        <name>dfs.datanode.failed.volumes.tolerated</name>
        <value>0</value>
</property>

因為上面的配置為0，當datanode節點有磁碟損壞時，認為此datanode不可用。

二、排查過程

為了儘快恢復出問題的datanode，修改dfs.datanode.failed.volumes.tolerated為1，設定最大允許損壞的磁碟數量為1。重啟集群后發現既作為namenode又作為datanode的節點上datanode的程序不能正常啟動，檢視日誌發現：

org.apache.hadoop.util.DiskChecker$DiskErrorException: Invalid volume failure  config value: 1

原因是既作為namenode又作為datanode的節點只配置了1塊盤作為datanode的資料儲存，而我們又把dfs.datanode.failed.volumes.tolerated這個引數配置成了1，所以datanode程序不能正常啟動。將既作為namenode又作為datanode節點上hdfs-site.xml檔案中的dfs.datanode.failed.volumes.tolerated引數改為0。 進行上面的修改後，重啟hdfs，結果一直處於安全模式。檢視是有資料丟失。因為叢集設定的是兩副本，就算有一塊磁碟損壞也不會造成資料丟失，困惑中。 為什麼會造成資料丟失呢，難道是有人手動修改副本數？去50070頁面檢視檔案副本數，發現檢視的資料都只有一份副本。決定自己put一個檔案試試看有幾個副本。執行hadoop fs -put命令put一個檔案到hdfs上，再去檢視竟然只有一份副本。好吧，磁碟損壞，還沒有備份，資料一定會丟失。 三、問題分析及解決 為什麼配置是兩副本而實際放到hdfs之後只有一個副本呢？這就要涉及到rack（機架）的概念了。 資料存到hdfs上時，如果配置的是兩副本，先根據叢集中節點的繁忙程度選定第一個副本存在哪個datanode節點，如果datanode處於不同的rack中，根據就近原則選定跨交換機最少的rack中datanode儲存第二份副本。下面舉例說明為什麼會出現配置兩份副本，但是實際儲存只有一份副本的情況。 叢集共四臺機器：

• hm（主namenode兼職datanode並且只有一塊盤用作datanode資料儲存，位於rack0）
• hb（備namenode兼職datanode並且只有一塊盤用作datanode資料儲存，位於rack1）
• hs1（datanode1，位於rack1）
• hs2（datanode2，位於rack1）

正常情況一份資料寫到hdfs，理論上第一個副本會有兩種情況，寫到rack0中的hm節點，或者寫到rack1中的hb、hs1、hs2之中的某個節點。相應的第二份副本則會存到另外一個機架的節點中。如果僅僅是這樣還不會出現只有一份副本的情況，那麼為什麼會出現缺少副本的情況呢，原因在於配置的dfs.datanode.du.reserved引數，給非hdfs使用的空間保留的過大，導致hm節點不能寫入資料。所以資料就都只有一個副本了。

基於上述的配置，資料的第一份副本寫入到rack1中的hs1、或者hs2中，正常會去rack0中的hm寫第二份副本，但現在hm節點給非hdfs使用的空間保留的過大，不能寫入資料，所以只有一副本。 解決上述問題的辦法有兩個： 1. 將所有伺服器都放到一個機架內。 2. 將能寫入資料的節點放到不同的機架內。

做好了修改之後，再次put一個檔案到hdfs上之後，發現副本數恢復正常配置的兩份，證明修改生效。