[HADOOP] 네임 스페이스 이미지 및 로그 편집

네임 스페이스 이미지 및 로그 편집

Namenodes 및 Datanodes 주제 아래에있는 "Hadoop The Definitive Guide"책에서 언급되는 내용은 다음과 같습니다.

이 파일 네임 스페이스와 로그를 편집하는 데 혼란이 있습니다.

네임 스페이스 이미지는 메타 데이터를 저장하기위한 것이다.

그래서 내 질문은

해결법

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

   1.처음에는 NameNode가 처음 시작될 때 fsimage 파일 자체가 비게됩니다. NameNode가 생성 / 업데이트 / 삭제 요청을 받으면 편집 파일에 지속 된 후에 내성을 위해 편집 파일에 해당 요청을 먼저 기록하고 메모리 내 업데이트도 수행합니다. 모든 읽기 요청은 메타 데이터의 메모리 내 스냅 샷에서 제공되기 때문입니다.

   처음에는 NameNode가 처음 시작될 때 fsimage 파일 자체가 비게됩니다. NameNode가 생성 / 업데이트 / 삭제 요청을 받으면 편집 파일에 지속 된 후에 내성을 위해 편집 파일에 해당 요청을 먼저 기록하고 메모리 내 업데이트도 수행합니다. 모든 읽기 요청은 메타 데이터의 메모리 내 스냅 샷에서 제공되기 때문입니다.

   따라서이 시점에서 편집 파일이 범위를 벗어나 계속 커지는 것을 볼 수 있습니다. 이제 NameNode가 다시 시작되거나 어떤 이유로 든 다시 작동하여 가져온 경우 메타 데이터의 메모리 표현이 없으므로 편집 파일을 읽고 메모리 내 스냅 샷을 다시 작성해야합니다. 파일 크기를 편집합니다.

   편집 자체는 WAL (미리 쓰기 로그)이므로 모든 이벤트가 차례로 기록되어야하므로 (추가 만) 임의의 디스크 탐색을 방지하기 위해 파일에 업데이트가 없을 수 있습니다.

   이 오버 헤드를 방지하기 위해 (또는 편집 파일을 관리 가능한 상태로 유지하기 위해) SecondaryNameNode가 도입되었습니다. SNN의 유일한 목적은 편집 파일이 범위를 벗어나지 않도록하는 것입니다. 따라서 기본적으로 SNN은 파일을 편집 할 때마다 64MB에 도달하거나 매시간 (1 시간에 한 번) 진행될 때 검사 점이라는 프로세스를 트리거합니다.

   체크 포인트 프로세스는 간단합니다. SNN은 NN에 현재 편집 된 로그를 알려주고 edits.new라는 새로운 편집 파일을 작성한 다음 SNN이 fsimage를 복사하고 NN에서 파일을 편집하고 편집 파일의 이벤트를 적용하기 시작합니다. 이미 존재하는 fsimage 파일 (NN에서 가져옴)은 일단 새 fsimage 파일이 완료되면 NN으로 보내지고 NN은 기존 fsimage를 SNN이 보낸 새 파일로 대체하고 edits.new의 이름을 편집으로 바꿉니다. 이제 NN에는 편집 파일에서 이벤트가 적용된 fsimage의 최신 버전이 있습니다.

   Checkpointing이 완료된 후 NameNode가 다시 시작되면 NameNode는 메모리에 fsimage를로드하고 편집 로그에서 recents 업데이트 만 적용해야합니다 (체크 포인트가 완료된 후 채워짐). 보다 효율적인 네임 스페이스 뷰를 제공합니다.

from https://stackoverflow.com/questions/26943161/namespace-image-and-edit-log by cc-by-sa and MIT license