2013-07-22 2 views
5

EDIT:問題の内容を最終的に把握しました。いくつかのファイルは非常に高いレプリケーションファクタセットを持っていました。私はクラスタを2ノードに減らしていました。これらのファイルに対するレプリケーションファクタを減らしてしまえば、廃止は正常に終了しました。Hadoopノードが廃止に時間がかかります

私はdfs.hosts.excludemapred.hosts.excludeファイルに退役するノードを追加し、このコマンドを実行してきました:

bin/hadoop dfsadmin -refreshNodesを。

NameNodeのUIでは、このノードがDecommissioning Nodesになっていますが、時間がかかり過ぎて、ノードの使用を中止するデータがあまりありません。

ノードを切り離すには非常に時間がかかりますか、探している場所がありますか?私は正確に何が起こっているのか分かりません。

私は、このノード上でも、任意の破損ブロックが表示されない:

$ ./hadoop/bin/hadoop fsck -blocks/
Total size: 157254687 B 
Total dirs: 201 
Total files: 189 (Files currently being written: 6) 
Total blocks (validated):  140 (avg. block size 1123247 B) (Total open file blocks (not validated): 1) 
Minimally replicated blocks: 140 (100.0 %) 
Over-replicated blocks:  6 (4.285714 %) 
Under-replicated blocks:  12 (8.571428 %) 
Mis-replicated blocks:   0 (0.0 %) 
Default replication factor: 2 
Average block replication:  1.9714285 
Corrupt blocks:    0 
Missing replicas:    88 (31.884058 %) 
Number of data-nodes:   3 
Number of racks:    1 
FSCK ended at Mon Jul 22 14:42:45 IST 2013 in 33 milliseconds 


The filesystem under path '/' is HEALTHY 

$ ./hadoop/bin/hadoop dfsadmin -report 
Configured Capacity: 25357025280 (23.62 GB) 
Present Capacity: 19756299789 (18.4 GB) 
DFS Remaining: 19366707200 (18.04 GB) 
DFS Used: 389592589 (371.54 MB) 
DFS Used%: 1.97% 
Under replicated blocks: 14 
Blocks with corrupt replicas: 0 
Missing blocks: 0 

------------------------------------------------- 
Datanodes available: 3 (3 total, 0 dead) 

Name: 10.40.11.107:50010 
Decommission Status : Decommission in progress 
Configured Capacity: 8452341760 (7.87 GB) 
DFS Used: 54947840 (52.4 MB) 
Non DFS Used: 1786830848 (1.66 GB) 
DFS Remaining: 6610563072(6.16 GB) 
DFS Used%: 0.65% 
DFS Remaining%: 78.21% 
Last contact: Mon Jul 22 14:29:37 IST 2013 


Name: 10.40.11.106:50010 
Decommission Status : Normal 
Configured Capacity: 8452341760 (7.87 GB) 
DFS Used: 167412428 (159.66 MB) 
Non DFS Used: 1953377588 (1.82 GB) 
DFS Remaining: 6331551744(5.9 GB) 
DFS Used%: 1.98% 
DFS Remaining%: 74.91% 
Last contact: Mon Jul 22 14:29:37 IST 2013 


Name: 10.40.11.108:50010 
Decommission Status : Normal 
Configured Capacity: 8452341760 (7.87 GB) 
DFS Used: 167232321 (159.49 MB) 
Non DFS Used: 1860517055 (1.73 GB) 
DFS Remaining: 6424592384(5.98 GB) 
DFS Used%: 1.98% 
DFS Remaining%: 76.01% 
Last contact: Mon Jul 22 14:29:38 IST 2013 

答えて

6

廃止措置は、あなたが多くのデータを持っていない場合でも、本プロセスではありません。

最初に、データをかなりブロックする必要があり(ブロックサイズの大きさによって異なります)、クラスタを圧倒して操作上の問題を引き起こす可能性があることを意味します。やや抑制された。

また、使用しているHadoopのバージョンによっては、分解を監視するスレッドだけが頻繁に起動します。これまでのHadoopのバージョンでは5分程度かかっていましたが、今は1分以内です。

進行内の使用停止は、ブロックが複製されていることを意味し、私は、これは本当にあなたが持っているどのくらいのデータ依存しており、あなただけがこのタスクのために完全にあなたのクラスタを利用されることはありませんので、待たなければならないと思います。

+3

あなたの答えに感謝します。私はついにその問題が何かを考え出した。いくつかのファイルは非常に高いレプリケーションファクタセットを持っていました。私はクラスタを2ノードに減らしていました。これらのファイルに対するレプリケーションファクタを減らしてしまえば、廃止は正常に終了しました。 – Srikanth

1

廃止中は、一時ファイルまたはステージングファイルが自動的に消去されます。これらのファイルは今や見つからず、hadoopはそれがどのように失われたのかを認識していません。したがって、実際の廃棄が他のすべてのファイルに対して行われても、廃炉プロセスはそれが解決されるまで待機し続けます。

Hadoop GUIの場合、パラメータ「Under-Replicated Blocks」が時間の経過とともに減少していないか、ほぼ一定していることがわかった場合は、これが原因です。

だから、あなたはそれらのファイルが必要な一時とされない表示された場合、その後、それらのファイルやフォルダ

例を削除するHadoopのfsck/-files -blocks -racks

コマンド以下

を使用してファイルをリスト: hadoop fs -rmr /var/local/hadoop/hadoop/.staging/*(ここで正しいパスを指定してください)

これはすぐに問題を解決します。 De-Commissioned Nodeは5分でDead Nodesに移動します。

0

ファイルレベルまたはデフォルトレベルのレプリケーションファクタより多くのアクティブなデータノードがない場合、ステータスは変更されず、時間がかかります(最終的には失敗します)。

関連する問題