hadoop系列 第一坑： hdfs JournalNode Sync Status

今天早上來公司發現cloudera manager出現了hdfs的警告，如下圖：

 

解決的思路是：

1、首先解決簡單的問題，查看警告提示的設置的閥值時多少，這樣就可以快速定位到問題在哪了，果然JournalNode Sync Status提示最先消去；

2、然后解決Sync Status問題，首先找到提示語的解釋，在官網上可見。然后查看配置參數有無問題，沒問題就看log，果然在log中看到了報錯信息；

3、最后可定位到該提示是由於JournalNode節點間同步文件沒有保持一致，那么使用修復（優雅）或是拷貝（不優雅）的方式即可解決；

4、針對一個問題，解決的方法有多種，有的是“優雅的辦法”，有的是“不優雅的辦法”，不幸的是我使用了“不優雅的辦法”解決了該問題。

如果哪位朋友知道怎么可以初始化JournalNode下的dfs.journalnode.edits.dir目錄（把某個namenode上的namespace元數據同步到JournalNode節點上），可以告訴我哦，先謝了！

 

下面是解決問題的整個過程：

第一反應是肯定是JournalNode在同步namespace的鏡像和edit log時出現了點問題，很顯然是108和109兩個節點上的JournalNode同步出現了問題。

我這里時配置了五個節點的JournalNode，現在有2個JournalNode出現了問題，理論上應該是warning，而不是critical。

當出現"Sync Status"、"JournalNode Sync Status"這一類提示的時候，在cloudera官網上時能找到相關解釋的，例如：關於namenode的health check在的提示語在下面鏈接中是能找到相關說明的：

英文地址(推薦)：

http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cm_ht_namenode.html

中文地址(有少量缺失)：

http://www.cloudera.com/content/cloudera/zh-CN/documentation/core/v5-3-x/topics/cm_ht_namenode.html

我們可以找到short name為JournalNode Sync Status的描述如下：

接着在CM里找到了相關參數的設置：

HDFS --->  Configuration ---> View and Edit ---> Monitoring，在Search表單里寫入"namenode_out_of_sync_journal_nodes_thresholds"，可以看到配置為

 

現在的配置為從來不提示warning，只要出現JournalNode同步出現問題提示Critical，我們設置如下：

 

現在JournalNode Sync Status的警告沒有了，但是Sync Status的警告還在。剛剛處理的是修改了NameNode health check的警告提示符。

 

下面來處理Sync Status警告問題：

同樣的，我們找到了它的相關描述http://www.cloudera.com/content/cloudera/en/documentation/core/latest/topics/cm_ht_journalnode.html

 

通過查看這個，並沒有解決服務本身問題的描述，同步時間設置為180秒，查看網絡io，並沒有出現負載偏高的情況。下面只有查看服務的log了：

IPC Server handler 3 on 8485, call org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocol.getEditLogManifest from 172.31.13.29:56789: error: org.apache.hadoop.hdfs.qjournal.protocol.JournalNotFormattedException: Journal Storage Directory /hadop-cdh-data/jddfs/nn/journalhdfs1 not formatted
org.apache.hadoop.hdfs.qjournal.protocol.JournalNotFormattedException: Journal Storage Directory /hadop-cdh-data/jddfs/nn/journalhdfs1 not formatted
 at org.apache.hadoop.hdfs.qjournal.server.Journal.checkFormatted(Journal.java:451)
  at org.apache.hadoop.hdfs.qjournal.server.Journal.getEditLogManifest(Journal.java:634)
      at org.apache.hadoop.hdfs.qjournal.server.JournalNodeRpcServer.getEditLogManifest(JournalNodeRpcServer.java:178)
    at org.apache.hadoop.hdfs.qjournal.protocolPB.QJournalProtocolServerSideTranslatorPB.getEditLogManifest(QJournalProtocolServerSideTranslatorPB.java:196)
    at org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocolProtos$QJournalProtocolService$2.callBlockingMethod(QJournalProtocolProtos.java:14094)
  at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:453)
       at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1002)
     at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1760)
     at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1756)
     at java.security.AccessController.doPrivileged(Native Method)
       at javax.security.auth.Subject.doAs(Subject.java:396)
       at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1438)
     at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1754)

IPC Server handler 4 on 8485, call org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocol.heartbeat from 172.31.9.109:53202: error: java.io.FileNotFoundException: /hadop-cdh-data/jddfs/nn/journalhdfs1/current/last-promised-epoch.tmp (No such file or directory)
java.io.FileNotFoundException: /hadop-cdh-data/jddfs/nn/journalhdfs1/current/last-promised-epoch.tmp (No such file or directory)
  at java.io.FileOutputStream.open(Native Method)
     at java.io.FileOutputStream.<init>(FileOutputStream.java:194)
 at java.io.FileOutputStream.<init>(FileOutputStream.java:145)
 at org.apache.hadoop.hdfs.util.AtomicFileOutputStream.<init>(AtomicFileOutputStream.java:56)
  at org.apache.hadoop.hdfs.util.PersistentLongFile.writeFile(PersistentLongFile.java:75)
     at org.apache.hadoop.hdfs.util.PersistentLongFile.set(PersistentLongFile.java:61)
   at org.apache.hadoop.hdfs.qjournal.server.Journal.updateLastPromisedEpoch(Journal.java:311)
 at org.apache.hadoop.hdfs.qjournal.server.Journal.checkRequest(Journal.java:414)
    at org.apache.hadoop.hdfs.qjournal.server.Journal.heartbeat(Journal.java:397)
       at org.apache.hadoop.hdfs.qjournal.server.JournalNodeRpcServer.heartbeat(JournalNodeRpcServer.java:148)
     at org.apache.hadoop.hdfs.qjournal.protocolPB.QJournalProtocolServerSideTranslatorPB.heartbeat(QJournalProtocolServerSideTranslatorPB.java:146)
     at org.apache.hadoop.hdfs.qjournal.protocol.QJournalProtocolProtos$QJournalProtocolService$2.callBlockingMethod(QJournalProtocolProtos.java:14086)
  at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:453)
       at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1002)
     at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1760)
     at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:1756)
     at java.security.AccessController.doPrivileged(Native Method)
       at javax.security.auth.Subject.doAs(Subject.java:396)
       at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1438)
     at org.apache.hadoop.ipc.Server$Handler.run(Server.java:1754)

此時可以看見存放同步文件的目錄/hadop-cdh-data/jddfs/nn/journalhdfs1找不到，ssh遠程連入該節點查看果然沒有這個目錄。

到這里，基本上可以定位到問題了，解決的辦法有2種：一是通過相關命令來初始化這個目錄（我覺得這種方法才是解決該問題的正確方法），二是直接拷貝正常journalnode上的文件過來。

本人使用的是方法二，這里有一點需要注意，就是復制的時間不能過長，應該是不能超過journalnode_sync_status_startup_tolerance設置的值（個人理解），因為第一次打zip包下載在傳到其它節點上后使用就超時了，第二次使用scp直接拷貝就可以了，命令如下：

rm -rf journalhdfs1
scp -r -i /root/xxxxxxx.pem root@ip-xxx-xx-xx-111:/hadop-cdh-data/jddfs/nn/journalhdfs1 ./
chown -R hdfs:hdfs journalhdfs1

注：在namespace元數據過大時，需要注意dfs.image.transfer.bandwidthPerSec參數的設置，它是同步數據時的帶寬限制。

然后重啟了這兩個JournalNode（也可以先關閉，文件復制好之后啟動）節點，問題解決。

 

另外，我建了個QQ群：305994766，希望對大數據、算法研發、系統架構感興趣的朋友能夠加入進來，大家一起學習，共同進步（進群請說明自己的公司-職業-昵稱）