斷電導致hdfs服務不正常，並顯示塊損壞
檢查hdfs系統檔案健康
$>hdfs fsck /
注：通過web ui也可以進行檢視
檢查是對應的哪些block發生了損壞
$>hdfs fsck -list-corruptfileblocks
出來的結果是損壞的block及對應的file所在的路徑
業務場景如下：mysql ----同步資料----> 大資料平台
只需要從mysql中***x這張表的資料重新刷乙份到hdfs平台即可
因為從上述的檢查結果來看我們是知道了***x這張表的資料出現了問題
目前是只知道對應file所對應的block名字是什麼，但是並不知道這些block是分布在哪些機器上面的，我們是未知的
塊、檔案、機器的關係：
1個檔案對應多個塊，每個塊分布在不同的機器上面
我們可以使用命令：
$>hdfs fsck *** -files -locations -blocks -racks
對應引數的含義：
對於損壞塊的檔案，是無法進行顯示的
對於好的沒有損壞的檔案，是能夠顯示塊分布情況的
如果我們知道塊分布在哪台機器上，我們就直接去對應機器的目錄上面，刪除對應的linux檔案即可，最終的效果就是將該損壞的塊給刪除了，路徑為/dfs/dn…
而使用hdfs fsck / -delete命令是直接將損壞的檔案給刪除了，那麼該檔案對應的所有的塊也就刪除了
最終刪除損壞塊的檔案，然後對應的業務系統資料重刷
$>hdfs fsck / -delete
注：該命令僅僅只是刪除損壞塊所對應的檔案，而不是刪除損壞的那個塊
帶來的三點思考：
使用debug命令進行手動恢復
直接命令列輸入hdfs，並敲擊回車之後，所顯示的一串命令當中，是沒有debug命令的
但是實際上hdfs debug是有這個組合命令的
手動修復block的命令(最多重試10次)：
$> hdfs debug recoverlease -path /blockrecover/ruozedata.md -retries 10
這樣做是基於這樣的思考：1個block有對應的三個副本，其中乙個副本損壞了，但是有另外兩個副本存在，是可以利用另外兩個副本進行修復的，因此我們可以使用debug命令進行修復
在hdfs中實際上也可以配置塊的自動修復的
當資料塊損壞後，datanode節點在執行directoryscan操作之前，都不會發現損壞
directoryscan操作是間隔6h進行的
dfs.datanode.directoryscan.interval : 21600
在datanode向namenode進行blockreport之前，都不會恢復資料塊;
blockreport操作是間隔6h進行的
dfs.blockreport.intervalmsec : 21600000
當namenode收到blockreport才會進行恢復操作
關於HDFS Block損壞恢復
在hdfs中，提供了fsck命令，用於檢查hdfs上檔案和目錄的健康狀態 獲取檔案的block塊資訊和位置資訊等。具體命令介紹 move 移動損壞的檔案到 lost found目錄下 delete 刪除損壞的檔案 openforwrite 輸出檢測中的正在被寫的檔案 list corruptfile...
Cassandra解決單個磁碟損壞的情況
cassandra乙個節點的磁碟壞了，分兩種情況，一種是節點還可以正常啟動。另外一種是節點無法啟動。第一種情況 節點還可以正常啟動 1 把壞的盤換掉，如果你沒有新的盤去更換，你可以在cassandra.yaml裡直接把壞的盤注釋掉 2 啟動cassandra，如果啟動的過程中報錯，說找不到keysp...
SPFILE引數檔案損壞及解決
rac oracle 11g spfile引數檔案損壞，導致資料庫節點10.8.25.240起不來，且無法關閉與連線 原因是 恢復db recovery file dest size預設值0 操作導致，引數檔案內容如下 spfile data zdzrac spfilezdzrac.ora 解決辦法...