NNと作業メカニズム2NN
思考:名前ノードのメタデータがどこに保存されていますか?
- 仮定名前ノードノードは、必要に応じてハードディスク、ランダムアクセスに保存されていると、多くの場合、顧客の要求に応え、必然的に非効率的な、それがメモリに保存されています
- しかし、停電後は、メタデータが失われ、メモリに保存されている場合は、クラスタ全体が動作しません、それはハードディスクにFsimageバックアップメタデータが生成されます
- しかし、これはそうでない場合は整合性の問題が発生する可能性があり、メタデータのメモリが更新されたとき、発生し、Fsimageを更新する必要があり、新たな問題が発生します。
- 更新したい場合はしかし、低効率につながります
- したがって、クライアントのメタデータを記録するために使用される編集文書の導入は、すべての操作(操作のみ、高効率を追加)、メタデータの更新、編集に入れ、更新操作の記録、編集するたびに更新されますまた、ハードディスクに保存されています
- したがって、Fsimageによってノード名前ノードオフ、および編集一度、最新のメタデータが生成された合成
- 長い時間が編集運用データに追加されている場合は、ファイルデータが大きすぎる原因となり効率が低下し、回復時間が発生します電源障害が長すぎると、そのため、定期的に編集をFsimageするマージする必要があります。
- これらの操作が完了した名前ノードのノードに引き渡されている場合と、それは効率の低下につながります
- 具体合わせFsimage及び編集のための新しいセカンダリノードSecondaryNameNode名前ノードのよって導入
NNと作業メカニズム2NN
- 第一段階:名前ノード開始
- それは名前ノードを始めたときに最初のスタート名前ノードフォーマットした後、Fsimageを作成、編集ファイルが生成され、最初に作成されていない場合は、メモリの編集とFsimageに直接ロードされ、編集とFsimageがあるだろう操作は、HDFSに開始マージこの時、名前ノードのメモリには、最新のメタデータ情報を保持します
- クライアントメタデータ伝送CRUD(クエリがメタデータを変更していないため、クエリ操作は、記録されません)要求
- 名前ノードは、最初の操作ログを記録し,,ローリングログを更新します
- メモリ内のメタデータの操作に名前ノードの追加および削除
- 第二段階:SecondaryNameNode仕事
- 名前ノードは、チェックの直接の結果かどうか戻って名前ノードに、チェックポイントが必要な場合SecondaryNameNodeは定期的に尋ねました
- 場合は、完全な、SecondaryNameNode要求実行Checkpointにタイマー時間のCheckPoint編集やデータ
- 名前ノードのスクロールが編集を書かれた、新しい空のedits.inprogress_002を生成しているすべての更新がedits.inprogress_002に書き込まれた後、スクロール目的は、マークを作るために編集を与えることです
- 編集とFsimage元のファイルがSecondaryNameNodeノードにコピーされ、それらは、新たな画像ファイルfsimage.chkpointを生成するために組み合わされたメモリSecondaryNameNodeにロードされます
- 新しいイメージファイルは、名前ノードをfsimage.chkpoint Fsimageの名前を変更し、元の画像ファイルを置き換えるためにコピーされます
- したがって、最後の名前ノードの開始は、だけでなく、合併前にロードする必要があるとFsimageは、最新のメタデータ情報に更新するように編集します
Fsimageと解決編集
- 名前ノードフォーマット後、う
/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current/
ディレクトリに以下のファイルを生成します。
-rw-rw-r--. 1 kocdaniel kocdaniel 945 9月 25 20:27 fsimage_0000000000000000000
-rw-rw-r--. 1 kocdaniel kocdaniel 62 9月 25 20:27 fsimage_0000000000000000000.md5
-rw-rw-r--. 1 kocdaniel kocdaniel 4 9月 25 20:27 seen_txid
-rw-rw-r--. 1 kocdaniel kocdaniel 205 9月 25 10:25 VERSION
- fsimage:永久的なチェックポイントHDFSのファイルシステムのメタデータ、すべてのディレクトリとファイルのinodeのシーケンスは、ファイルシステム情報HDFSを含み
- 編集(あなたが名前ノードを起動したときに発生する):すべての更新を保存するHDFSファイルシステム、クライアントによって実行されるファイルシステムの書き込み操作は、最初のファイルの編集に記録されます
- seen_txis:デジタル保存は、最新のedits_後数です
- すべては時間がFsimageファイルになります開始名前ノードのメモリに読み込まれ、負荷が同期され、メモリ内のコンテンツのメタデータが最新であることを保証するために、ファイルの更新操作を編集
- OIVビューFsimageファイル
- 基本的な構文:
hdfs oiv -p 文件类型 -i 镜像文件 -o 转换后文件输出路径
- OEVビューは、ファイルを編集します
- 基本的な構文:
hdfs oev -p 文件类型 -i 编辑日志 -o 转换后文件输出路径
チェックポイント時間の設定
デフォルトでは、SecondaryNameNodeは一度時間ごとに行ったり100万回以上の操作の数が、統計的SecondaryNameNode行うことはできません所有の操作の数が、それは名前ノードを必要とするときがあるので、パラメータセットは、一回毎分の名前ノードをチェックされています動作周波数動作周波数が1,000,000 SecondaryNameNodeチェックポイントが開始さに達したとき、パラメータは、3つのhdfs_site.xmlプロファイルに設定され、次のような構成です。
# SecondaryNameNode每隔一个小时执行一次
<property>
<name>dfs.namenode.checkpoint.period</name>
<value>3600</value>
</property>
# SecondaryNameNode当操作次数超过100万次时执行一次
<property>
<name>dfs.namenode.checkpoint.txns</name>
<value>1000000</value>
<description>操作动作次数</description>
</property>
# NameNode一分钟检查一次操作次数
<property>
<name>dfs.namenode.checkpoint.check.period</name>
<value>60</value>
<description> 1分钟检查一次操作次数</description>
</property >
名前ノードのトラブルシューティング
名前ノード障害後の2つの方法があります。
名前ノードのトラブルシューティングモード:直接ディレクトリの名前ノードのディレクトリにコピーし、直接SecondaryNameNode内のデータは、その後、名前ノードを再起動します
トラブルシューティングの名前ノードの道:名前ノードデーモンを起動するために使用-importCheckpointオプション、直接ディレクトリの名前ノードにSecondaryNameNodeディレクトリ内のデータをコピーします
- まず、hdfs_site.xmlで次の設定ファイルを追加する必要があります
# SecondaryNameNode每隔两分钟执行一次
<property>
<name>dfs.namenode.checkpoint.period</name>
<value>120</value>
</property>
# 指定namenode生成的文件目录
<property>
<name>dfs.namenode.name.dir</name>
<value>/opt/module/hadoop-2.7.2/data/tmp/dfs/name</value>
</property>
- その後、SecondaryNameNode名前ノードではなく、ホストノードならば、ディレクトリSecondaryNameNodeは、データを格納し、同じレベルの名前ノードのディレクトリにコピーされたデータを保存し、ファイルを削除する必要がin_use.lock
- (端を待っている間に、Ctrl + C)最後のチェックポイントデータを導入
[kocdaniel@hadoop102 hadoop-2.7.2]$ bin/hdfs namenode -importCheckpoint
なお、私たちは自分の手の名前ノードから、その後、停止するために+ C Ctrlキーを押しながら、(暫定スタート)コマンドを実行した後、観察名前ノードが開始された、そしてデータが復元されていると判断された場合、一回2分ごとにチェックします。
Ctrl + Cした後、データを回復するために名前ノードを再起動し、しかし完全には回復しない、最新のアクションが編集ファイルを失われます
クラスタセキュリティモード
セーフモードとは何ですか
- 名前ノードは、最初のFsimageがメモリにロードされ、起動して操作を実行するときで編集し、メモリイメージ内のファイルシステムのメタデータの確立に成功した場合は、新しい文書と空Fsimage編集ログを作成し、待機を開始データノードの要求、このプロセス中に、名前ノードはセーフモードで実行されて、それは、クライアントが読み取り専用で、名前ノードであります
- データノードの起動は、システムは、システムの通常の動作中維持されるデータブロックの名前ノードの位置が、によって決定されていない場合、名前ノードはデータノードのブロックリストによって記憶されたメモリマッピング情報内のすべてのブロックを保持します。セーフモードでは、各データノードは、ブロックリストの名前ノードに最新の情報をお送りします後、名前ノードは、十分な情報ブロックリストを理解し、あなたが効率的にファイルシステムを実行することができます
- セーフモードの終了裁判官:彼らは満たしていればコピーの最小条件を、名前ノードは、30秒後にセーフモードを終了します。最小条件は、ファイルシステム全体のブロックのコピーがコピーレベルの99.9%(デフォルト1)の最小値、少なくとも1つのコピーブロック、すなわち99.9%が存在している満足することです。
- 名前ノードが安全モードに入らないように、システムは、任意のブロックを持っていないので、ちょうどあなたは、フォーマットされたHDFSクラスタを起動したとき
基本的な構文
- クラスタが安全モードになっているときは、任意の重要な操作(書き込み操作)を実行することはできません。
- クラスタの起動が完了すると、自動終了セーフモード
(1)bin/hdfs dfsadmin -safemode get (功能描述:查看安全模式状态)
(2)bin/hdfs dfsadmin -safemode enter (功能描述:进入安全模式状态)
(3)bin/hdfs dfsadmin -safemode leave (功能描述:离开安全模式状态)
# wait是指,如果在脚本中写入此命令,则脚本将等待安全模式退出后自动执行
(4)bin/hdfs dfsadmin -safemode wait (功能描述:等待安全模式状态)
名前ノードのマルチディレクトリ構成
- 名前ノードのローカルディレクトリは複数あり、各ディレクトリとして構成することができる同じコンテンツ、信頼性の向上、改善された高可用性
- 次のようにhdfs_site.xmlの特定のニーズを追加しました:
# 指定目录的路径
<property>
<name>dfs.namenode.name.dir</name>
<value>file:///${hadoop.tmp.dir}/dfs/name1,file:///${hadoop.tmp.dir}/dfs/name2</value>
</property>