また、このディスクのミラーリングスナップショットとして知られ、バックアップポイントと呼ばれるfsimageどちらが名前ノードであります
一つの永続的な方法：もっとゆっくり時系列データのメモリ上の欠点
具体的なプロセス：我々は、名前ノードは、一般的にメモリに格納されて知っている、そしてディスクと相互作用せず、ほとんど非リレーショナルデータベースのこの種をRedisのが、メモリ内のデータは、常に永続的ではないのでどのようにそれを持続するには？私たちの名前ノードのノードデータの永続化プロセスのように：それはIOファイルシステムの形式でコンピュータに保存された後、バイナリバイトストリームへの最初のメモリデータ系列、持続性のプロセスを完了するために、名前ノードのプロセスは、外部メモリにバイトコードファイルを必要とする場合に必要な具体的なデータは、デシリアライズさ、そしてメモリにロードされ、それが名前ノードのために使用することができる場合
注意事項：ポイントスナップショット：外部メモリのみに永続行く時間の所定の間隔の後、このよう13:00、15:00、17:00など。。。。永続中に第2の代わりにすべての、データ取得時間が非常に長くなるように、その場合には、頻繁なディスクと外部メモリは、対話することであろうから
次の2つの方法の持続性：遅くしない外部メモリプロセスに格納されたデータでは欠点が、メモリに保存されたときに、外部メモリの回復が遅くなります
操作ログに記録されたメタデータを編集します。。。> Redisの
そのログ編集： 1）データは、命令内の任意のサーバーにクライアントの村の外に保存されますが、外部メモリからのデータがメモリにロードされる2）の間で、ログファイルの操作ログに書き込まれます。直接再ログを生き残ります命令に。
この方法はまた戻って持続する時間の指定された期間の中で初めてではなく、リアルタイム
一般的には、これらの2つの永続を組み合わせることです
しかし、どのようにそれを使用するために、これらの二つの方法を組み合わせること？まず、あなたが文書を作成fsimage理解する必要があり、ファイルがHadoopクラスタシステムを構築するfsimage時間のために生成されたときに、ファイルを編集し、この時点で生成されたファイルは空です。生成タイミングは編集：、クラスタの起動を編集し、ログファイルを生成し、そのファイルが空で、ブートが完了した後、次に、ファイルとfsimageファイルのマージを記録した後、ログに記録するため、クラスタが起動した後、上昇してきましたこの場合にはより多くの編集がデータを回復することはできませんので、ログファイル、増加しています。クライアントは、この時間がもたらした問題は、ログファイルに記録されますクラスタコマンドに名前ノードによってリアルタイムに送信し続けますそれは非常に長くなりますので、のHadoop fsimageは時々編集しSecondNameNodeを介してファイルをマージします
SecondaryNameNodeコンセプト：ない名前ノードのバックアップが、唯一の合併fsimageファイルおよびログファイルが表示されます
詳細統合プロセス
空fsimageを生成した後、システムを起動した後、fsimageファイルが生成され、クライアントは名前ノードが編集記録する指示を送信し、編集が非常に大きくなるが、第二のメイン：直ちにクラスタ構造の完了後編集が一定のサイズに達したとき、彼らは、しばらく彼は第二主ノードの編集に伝え、名前ノードに配置されたノード（つまり、マスターノード）がマージされた命令を記録するように進ませません、ノードをチェックします編集マスターノードは、まだサイズがゼロから成長するときに再び記録するための命令を受けた後、クリアされます。その中にマスターノードは、クライアントから送信された新しい記録開始命令から編集後に合併した後、名前ノード、fsimageで置換のためのオリジナルのマスターノードに送信された全体のプロセスを繰り返すことができる後。しかし、これはあるhadoop1.0永続的な名前ノードのデータ処理機構の時間。バージョン2.xの後、このSecondaryNameNodeは姿を消しました
データノードは、理解することを学びます
