5つのスレーブHadoopクラスター(CDH4を使用)があります---スレーブはDataNodeとTaskNodeが実行される場所です。各スレーブには、HDFSストレージ専用の4つのパーティションがあります。スレーブの1つに再インストールが必要で、これによりHDFSパーティションの1つが失われました。この時点で、HDFSは35Kの欠落ブロックについて不平を言っていました。
数日後、再インストールが完了し、ノードをHadoopにオンラインに戻しました。 HDFSはセーフモードのままであり、新しいサーバーは他のノードのブロック数に近い位置で登録されていません。たとえば、DFS管理では、新しいノードは6Kブロックを持っていることを示し、他のノードは約400Kブロックを持っています。
現在、新しいノードのDataNodeログは、さまざまなブロックで検証(またはコピー?)を実行していることを示しています。その一部は既存のブロックとして失敗します。これは、既存のデータを新しいノードに複製するだけのHDFSだと思います。検証の例:
2013-08-09 17:05:02,113 INFO org.Apache.hadoop.hdfs.server.datanode.BlockPoolSliceScanner: Verification succeeded for BP-143510735-141.212.113.141-1343417513962:blk_6568189110100209829_1733272
失敗の例:
2013-08-09 17:04:48,100 ERROR org.Apache.hadoop.hdfs.server.datanode.DataNode: meez02.eecs.umich.edu:50010:DataXceiver error processing REPLACE_BLOCK operation src: /141.212.113.141:52192 dest: /141.212.113.65:50010
org.Apache.hadoop.hdfs.server.datanode.ReplicaAlreadyExistsException: Block BP-143510735-141.212.113.141-1343417513962:blk_-4515068373845130948_756319 already exists in state FINALIZED and thus cannot be created.
at org.Apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsDatasetImpl.createTemporary(FsDatasetImpl.Java:813)
at org.Apache.hadoop.hdfs.server.datanode.fsdataset.impl.FsDatasetImpl.createTemporary(FsDatasetImpl.Java:92)
at org.Apache.hadoop.hdfs.server.datanode.BlockReceiver.<init>(BlockReceiver.Java:155)
at org.Apache.hadoop.hdfs.server.datanode.DataXceiver.replaceBlock(DataXceiver.Java:846)
at org.Apache.hadoop.hdfs.protocol.datatransfer.Receiver.opReplaceBlock(Receiver.Java:137)
at org.Apache.hadoop.hdfs.protocol.datatransfer.Receiver.processOp(Receiver.Java:70)
at org.Apache.hadoop.hdfs.server.datanode.DataXceiver.run(DataXceiver.Java:221)
at Java.lang.Thread.run(Thread.Java:679)
DFSアドミンでは、ブロック数が他のノードの約2%であっても、この新しいノードの容量は61%(他のノードのおおよその使用量と一致)であることがわかります。これは、HDFSが認識していない古いデータにすぎないと思います。
(a)HDFSは古さのためにこのノードのデータを破棄しました。 (b)再インストールによって一部のシステムパラメータが変更されたため、HDFSはそれを新しいノードとして扱います(つまり、データのある既存のノードではありません)。または(c)どういうわけかドライブマッピングがめちゃくちゃになり、パーティションマッピングが変更され、HDFSが古いデータを見つけることができなくなります(ただし、ドライブにはラベルが付いています。
主な質問:このドライブのデータをHDFSに再認識させるにはどうすればよいですか?
サブ質問1:新しいノードのデータ使用量の私の仮定が正しい場合(61%の使用量はゴーストデータである)、HDFSによってクリーンアップされますか、それとも必要ですか?これを手動で削除するには?
サブ質問2:現在、「レプリケーションキューが初期化されていない」ため、listCorruptFileBlocks
を実行して不足しているブロックを見つけることができません。これを修正する方法はありますか?新しいノードが再調整されるのを待つ必要がありますか(つまり、この検証/コピーフェーズが終了するまで)?
pdate 1: NameNodeを再起動して問題を解決したと思いました。これにより、新しいノードのブロック数が他のノードとほぼ同じ使用量にジャンプし、DFSはメッセージを次のように変更しました。
セーフモードはオンです。報告されたブロック629047は、合計ブロック637856のしきい値0.9990に到達するために、さらに8172ブロックが必要です。セーフモードは自動的にオフになります。
最終的にセーフモードを終了することを期待して、この状態で数時間放置しましたが、何も変わっていません。次に、セーフモードを手動でオフにしたところ、DFSのメッセージが「8800ブロックがありません」に変わりました。この時点で、私はhdfs fsk -list-corruptfileblocks
、欠落しているブロックがあるファイルの大部分を表示します。
現在残っている問題:これらの不足しているブロックを回復する方法...(これを新しい質問でスピンオフする必要がありますか?)
最終的に、不良ブロックのあるファイルを削除する必要がありました。さらに調査したところ、レプリケーションが非常に低いことがわかりました(正しくリコールすれば、rep = 1)。
このSO投稿 は、次の行に沿って何かを使用して、不良ブロックのあるファイルを見つけることに関する詳細情報を持っています。
hadoop fsck / | egrep -v '^\.+$' | grep -v eplica
だから、私自身の質問に答えるには:
dfsadmin
を使用してセーフモードを終了します。今日も同様の問題がありました。ノードの1つ(3つのうち、replication = 3)が停止し、再起動後、影響を受けたデータノードのログでこれを確認し始めました。
18/04/27 14:37:22 INFO datanode.DataNode: Receiving BP-1114663060-172.30.36.22-1516109725438:blk_1073743913_3089 src: /172.30.36.26:35300 dest: /172.30.36.25:50010
18/04/27 14:37:22 INFO datanode.DataNode: g500603svhcm:50010:DataXceiver error processing WRITE_BLOCK operation src: /172.30.36.26:35300 dst: /172.30.36.25:50010; org.Apache.hadoop.hdfs.server.datanode.ReplicaAlreadyExistsException: Block BP-1114663060-172.30.36.22-1516109725438:blk_1073743913_3089 already exists in state FINALIZED and thus cannot be created.
Namenodesのwebuiには、92個のブロックしかないデータノードが表示されます(残りの13400個のうち)。
Namenodeのデータを更新するdatanodeでフルブロックレポートをトリガーすることで修正しました。
hdfs dfsadmin -triggerBlockReport g500603svhcm:50020
結果:データノードにはいくつかのブロックがありませんでしたが、それを受け入れてクラスターを復元しました。