問題一：Zookeeper節點數量為什么建議是奇數個？

原因是：“Zookeeper集群，當有一半以上的節點數在工作中的時候，集群才對外服務”。

怎么理解上面這句話呢，用實驗數據說話：
實驗一：

設置節點數量為偶數 4， 啟動 2 個節點。觀察結果：集群不對外服務啟動 3 個節點。觀察結果：集群開始對外服務
實驗二：

設置節點數量為奇數個 5啟動3個節點。觀察結果：集群開始對外服務

總結：
Zookeeper的算法邏輯里面，“一半以上的節點”，是不包括等于一半的。所以無論設置集群總數量為 2n+1 個節點 或者 2n 個節點，最少都需要依賴 n+1 個節點，分別可以容納 n 個 或 n-1 個節點掛掉（也就是說就算掛n個節點ZK系統照樣運行）。 （相比之下，設置為 2n+1， 可以比設置為 2n 多掛掉一個節點）。所以這里說的是建議奇數個而不是一定是奇數個節點

問題二：HA機制的Hadoop集群中Journal Node 作用

兩個NameNode為了數據同步，會通過一組稱作JournalNodes的獨立進程進行相互通信。當active狀態的NameNode的命名空間有任何修改時，會告知大部分的JournalNodes進程。standby狀態的NameNode有能力讀取JNs中的變更信息，并且一直監控edit log的變化，把變化應用于自己的命名空間。standby可以確保在集群出錯時，命名空間狀態已經完全同步了。
集群啟動時，可以同時啟動2個NameNode。這些NameNode只有一個是active的，另一個屬于standby狀態。active狀態意味著提供服務，standby狀態意味著處于休眠狀態，只進行數據同步，時刻準備著提供服務，如圖所示：

在一個典型的HA集群中，每個NameNode是一臺獨立的服務器。在任一時刻，只有一個NameNode處于active狀態，另一個處于standby狀態。其中，active狀態的NameNode負責所有的客戶端操作，standby狀態的NameNode處于從屬地位，維護著數據狀態，隨時準備切換。

兩個NameNode為了數據同步，會通過一組稱作JournalNodes的獨立進程進行相互通信（JournalNodes依賴于Zookeeper來實現兩個NameNode之間數據的同步功能）。當active狀態的NameNode的命名空間有任何修改時，會告知大部分的JournalNodes進程。standby狀態的NameNode有能力讀取JNs中的變更信息，并且一直監控edit log的變化，把變化應用于自己的命名空間。standby可以確保在集群出錯時，命名空間狀態已經完全同步了，如圖所示

為了確保快速切換，standby狀態的NameNode有必要知道集群中所有數據塊的位置。為了做到這點，所有的datanodes必須配置兩個NameNode的地址，發送數據塊位置信息和心跳給他們兩個。

對于HA集群而言，確保同一時刻只有一個NameNode處于active狀態是至關重要的。否則，兩個NameNode的數據狀態就會產生分歧，可能丟失數據，或者產生錯誤的結果。為了保證這點，JNs必須確保同一時刻只有一個NameNode可以向自己寫數據。

JournalNode服務器：運行的JournalNode進程非常輕量，可以部署在其他的服務器上。注意：必須允許至少3個節點。當然可以運行更多，但是必須是奇數個，如3、5、7、9個等等。當運行N個節點時，系統可以容忍至少(N-1)/2(N至少為3)個節點失敗而不影響正常運行。

在HA集群中，standby狀態的NameNode可以完成checkpoint操作，因此沒必要配置Secondary NameNode、CheckpointNode、BackupNode。如果真的配置了，還會報錯。

問題三：兩個datanode節點互相排斥怎么解決（集群無法識別新加入的Datanode）？

之前有兩個datanode節點，這里新添加了一個datanode節點，但是在集群中卻未表現出來。
到對應的管理界面只看到兩個存活的節點
Live Nodes 為 2,
Dead Nodes 為 0
然后我切換到Datanodes界面查看:
發現mini2和mini3存活, 我就刷新了幾下, 發現變成了mini3和mini4存活了, 我一直刷呀刷,發現有mini2就沒有mini4,有mini4就沒有mini2, mini2與mini4互相排斥,
然后我上傳了一個文件,結果mini2掛掉了 , 經過排查發現是我的
/root/apps/hadoop/tmp/dfs/data/current目錄下了VERSION文件里:


mini2和mini4的 datanodeUuid是一樣的（在虛擬機中玩集群添加節點的時候直接克隆虛擬機，雖然將新增的節點配置好后，但是由于對應datanode的配置信息（如版本信息）依舊是別的的節點的配置信息，所以才會出現這種情況，這時候只需要將之前節點生成的datanode的配置信息刪除，讓該節點重新生成配置信息即可），原來是datanode的Uuid沖突了。
解決方法：
把mini4的VERSION文件刪除，重啟datanode即可
停止: hadoop-daemon.sh stop datanode
啟動: hadoop-daemon.sh start datanode

問題四：如何修改Zookeeper日志 zookeeper.out輸出路徑

如果不做修改，默認zookeeper的日志輸出信息都打印到了zookeeper.out文件中，這樣輸出路徑和大小沒法控制，因為日志文件沒有輪轉。所以需要修改日志輸出方式。
具體操作如下：
1、修改$ZOOKEEPER_HOME/bin目錄下的zkEnv.sh文件，ZOO_LOG_DIR指定想要輸出到哪個目錄，ZOO_LOG4J_PROP，指定INFO,ROLLINGFILE的日志APPENDER.

2、修改$ZOOKEEPER_HOME/conf/log4j.properties文件的：
zookeeper.root.logger的值與前一個文件的ZOO_LOG4J_PROP 保持一致，該日志配置是以日志文件大小輪轉的，如果想要按照天輪轉，可以修改為DaliyRollingFileAppender

問題五：HDFS block丟失過多進入安全模式（safe mode）的解決方法

因磁盤空間不足，內存不足，系統掉電等其他原因導致dataNode datablock丟失。
解決辦法(Solution)*

安裝HDFS客戶端，并執行如下命令：

步驟 1     執行命令退出安全模式：hadoop dfsadmin -safemode leave步驟 2     執行健康檢查，刪除損壞掉的block。  hdfs fsck  /  -delete

注意: 這種方式會出現數據丟失，損壞的block會被刪掉。

問題六：datanode數據存放位置研究

Datanode中數據實際存放位置：

自定義路徑+dfs/data/current/BP-190247797-192.168.10.220-1460040893538/current/finalized

一、curren

/home/zjsd/hadoopdata/dfs/data/current/BP-190247797-192.168.10.220-1460040893538/current/如圖：

dfsUsed：該文件中存放該DataNode容量被占有的大小&&DataNode總容量
Finalized：數據實際所在的位置
VERSION：數據塊的版本信息
DataNode空間存儲的ID
layoutVersion:軟件所處的版本

二、Datanode的版本信息:

參考：https://blog.csdn.net/wbzhang2594/article/details/53893275
參考：https://blog.csdn.net/kiwi_kid/article/details/53514314
參考：
https://blog.csdn.net/csdm_admin/article/details/63253538?utm_source=itdadao&utm_medium=referral
參考：https://blog.csdn.net/wangshuminjava/article/details/79306358
參考：https://blog.csdn.net/czp11210/article/details/76695745
參考：https://blog.csdn.net/xiaoshunzi111/article/details/51239679