[HADOOP] Hadoop Namenode 메타 데이터 - fsimage 및 편집 로그

Hadoop Namenode 메타 데이터 - fsimage 및 편집 로그

필자는 fsimage가 시작시 메모리에로드되고 더 이상의 트랜잭션이 성능상의 이유로 fsimage가 아닌 편집 로그에 추가된다는 것을 알고 있습니다.

메모리의 fsimage는 namenode가 다시 시작될 때 새로 고쳐집니다. 효율성을 위해 2 차 이름 노드는 주기적으로 검사 점을 수행하여 fsimage를 업데이트하므로 namenode 복구가 빠릅니다. 이 모든 것이 좋습니다.

그러나 내가 이해하지 못하는 한 가지 점은 이것입니다. 파일이 이미 존재하고이 파일에 대한 정보가 메모리의 fsimage에 있다고 가정 해 보겠습니다. 이제이 파일을 편집 로그에서 업데이트되는 다른 위치로 이동합니다. 이제 이전 파일 경로를 나열하려고하면 파일 경로가 존재하지 않거나 뭐든지간에 불만을 제기합니다.

이것은 namenode가 메모리에있는 fsimage의 목적과 모순되는 편집 로그를 보는 것입니까? 또는 파일 위치가 변경된 것을 어떻게 알 수 있습니까?

해결법

1. ==============================

   1.답은 편집 로그의 정보를 보는 것입니다. 편집 로그에서 정보를 사용할 수없는 경우이 질문은 hdfs에 새 파일을 쓸 때 유스 케이스에 해당됩니다. fsimage 파일을 제거하고 hdfs 파일을 읽으려고하면 namenode가 실행되는 동안 읽을 수 있습니다.

   답은 편집 로그의 정보를 보는 것입니다. 편집 로그에서 정보를 사용할 수없는 경우이 질문은 hdfs에 새 파일을 쓸 때 유스 케이스에 해당됩니다. fsimage 파일을 제거하고 hdfs 파일을 읽으려고하면 namenode가 실행되는 동안 읽을 수 있습니다.

   실행중인 namenode에서 fsimage 파일을 제거해도 읽기 / 쓰기 작업에 문제가 발생하지 않습니다. namenode를 다시 시작하면 이미지 파일을 찾을 수 없다는 오류가 발생합니다.

   내가 너를 도울 수있는 좀 더 설명을 해줄 게.

   hadoop을 시작할 때만 fsimage 파일이 보입니다. 거기에 없으면 namenode가 나타나지 않고 namenode의 서식을 기록합니다.

   hadoop format -namenode 명령은 fsimage 파일을 만듭니다 (편집 로그가있는 경우). namenode 시작 파일 메타 데이터가 편집 로그에서 가져온 후에 (fsimage 파일을 통해 검색된 편집 로그의 정보가없는 경우). 그래서 fsimage는 정보가 마지막으로 저장되는 체크 포인트로 작동합니다. 이는 또한 2 차 노드가 편집 로그에서 (1 시간 / 1 밀리언 트랜잭션 후) 동기화를 유지하여 마지막 체크 포인트에서의 시작시 동기화 할 필요가 거의없는 이유 중 하나이기도합니다.

   safemode (명령 : hdfs dfsadmin -safemode enter)를 켜고 saveNamespace (명령 : hdfs dfsadmin -saveNamespace)를 사용하면 아래에 언급 된 로그 메시지가 표시됩니다.

   2014-07-05 15:03:13,195 INFO org.apache.hadoop.hdfs.server.namenode.FSImage: Saving image file /data/hadoop-namenode-data-temp/current/fsimage.ckpt_0000000000000000169 using no compression
   2014-07-05 15:03:13,205 INFO org.apache.hadoop.hdfs.server.namenode.FSImage: Image file /data/hadoop-namenode-data-temp/current/fsimage.ckpt_0000000000000000169 of size 288 bytes saved in 0 seconds.
   2014-07-05 15:03:13,213 INFO org.apache.hadoop.hdfs.server.namenode.NNStorageRetentionManager: Going to retain 2 images with txid >= 0
   2014-07-05 15:03:13,237 INFO org.apache.hadoop.hdfs.server.namenode.FSEditLog: Starting log segment at 170
   

2. ==============================

   2."파일과 블록의 매핑"과 파일 시스템 속성을 포함한 전체 파일 시스템 네임 스페이스는 FsImage라는 파일에 저장됩니다. "블록과 파일의 매핑"은 FsImage의 일부입니다. 메모리와 FsImage와 함께 Hadoop은 메모리에 저장하고, 이름 노드가 (다시) 시작되고 주기적으로 블록 보고서를 통해 데이터 노드 매핑을 차단합니다. 파일을 다른 위치로 이동하면 파일이 다른 위치로 이동합니다. 디스크상의 로그를 편집하고 데이터 노드가 namenode로 블록 보고서를 보내면 namenode는 블록이 클러스터에있는 위치에 대한 최신 뷰를 가져옵니다. 그런 식으로 데이터를 볼 수 없습니다 블록 리포트가 "블록을 데이터 노드에 매핑"을 업데이트했기 때문에 이전 경로에있었습니다.하지만 업데이트가 메모리에서만 발생했음을 기억하십시오. 이제 체크 포인트 또는 이름 노드가 다시 시작될 때 일정 시간이 지나면 디스크의 편집 로그 이미 수행 한 업데이트가 있습니다 (귀하의 사례에서 of file)은 디스크의 오래된 FsImage와 병합되어 새로운 FsImage를 생성합니다.이 업데이트 된 FsImage는 메모리에로드되고 동일한 프로세스가 반복됩니다.

   "파일과 블록의 매핑"과 파일 시스템 속성을 포함한 전체 파일 시스템 네임 스페이스는 FsImage라는 파일에 저장됩니다. "블록과 파일의 매핑"은 FsImage의 일부입니다. 메모리와 FsImage와 함께 Hadoop은 메모리에 저장하고, 이름 노드가 (다시) 시작되고 주기적으로 블록 보고서를 통해 데이터 노드 매핑을 차단합니다. 파일을 다른 위치로 이동하면 파일이 다른 위치로 이동합니다. 디스크상의 로그를 편집하고 데이터 노드가 namenode로 블록 보고서를 보내면 namenode는 블록이 클러스터에있는 위치에 대한 최신 뷰를 가져옵니다. 그런 식으로 데이터를 볼 수 없습니다 블록 리포트가 "블록을 데이터 노드에 매핑"을 업데이트했기 때문에 이전 경로에있었습니다.하지만 업데이트가 메모리에서만 발생했음을 기억하십시오. 이제 체크 포인트 또는 이름 노드가 다시 시작될 때 일정 시간이 지나면 디스크의 편집 로그 이미 수행 한 업데이트가 있습니다 (귀하의 사례에서 of file)은 디스크의 오래된 FsImage와 병합되어 새로운 FsImage를 생성합니다.이 업데이트 된 FsImage는 메모리에로드되고 동일한 프로세스가 반복됩니다.

from https://stackoverflow.com/questions/24288942/hadoop-namenode-metadata-fsimage-and-edit-logs by cc-by-sa and MIT license