[Hadoop] Secondary name-node, Checkpoint node, Backup node

Secondary NameNode는 이름으로 추측할때 Standby-NameNode로 보이는 문제로 인해 Checkpoint Node 또는 Backup Node로 이름이 변경된 것 같습니다.

(하둡 wiki에서 다음과 같이 말하고 있습니다.

http://hadoop.apache.org/hdfs/docs/current/hdfs_user_guide.html#Secondary+NameNode

The Secondary NameNode has been deprecated. Instead, consider using the Checkpoint Node or Backup Node. )

- Checkpoint: 네임스페이스는 네임노드의 메모리 및 디스크에 그 이미지가 저장되는데 이 이미지를 FsImage라고 부릅니다.

네임노드에서 디스크의 FsImage는 변경되지 않으며, 운영하는 동안 변경된 네임스페이스 정보는 edits log에 기록이 됩니다.

이 FsImage가 변경되는 시점은 네임노드가 시작할 때 뿐이며, 네임노드가 시작될 때 edits log를 디스크의 FsImage에 병합하고 이 이미지를 메모리에 올리게 됩니다. 이런 과정을 checkpoint라고 합니다.

 

- Checkpoint Node(또는 Backup Node, Secondary NameNode):

따라서, 네임노드의 FsImage는 네임노드가 시작될 때만 editLog를 머지하고 새롭게 생성되므로, edits log를 주기적으로 FsImage에 병합해주는 것을 자동으로 해주는 것이 필요했고 그것이 Checkpoint Node라고 보시면 됩니다.

즉, Checkpoint Node(Secondary NameNode)는 주기적으로 네임노드의 FsImage와 edits log를 다운로드 받아 이들을 병합(join)하고, 새롭게 만들어진 FsImage를 네임노드에 돌려(upload)줍니다.

Checkpoint Node(Secondary NameNode)는 네임노드가 죽었을 때 백업용이 아니라 FsImage를 주기적으로 갱신(checkpoint)시켜주는 역할만 합니다.

 

이런 역할을 하는 노드가 필요한 이유는 네임스페이스에 많은 변경이 발생한 경우 edits log가 엄청나게 쌓일 것이고, 네임노드를 재시작 시켜주지 않는 한(checkpoint가 일어나지 않는 한) edits log는 삭제되지 않고, 삭제되어서도 안됩니다.

이 edits log가 많이 쌓이면 네임노드 시작시 시간이 엄청나게 길어지고 메모리도 실제 이미지보다 많이 필요하게 되어 네임노드가 시작되지 않는 문제 등을 유발하게 됩니다. 따라서 Checkpoint Node가 주기적으로 edits log를 FsImage에 병합시켜서 네임노드의 FsImage를 수정시켜주는 것입니다.

http://wiki.apache.org/hadoop/FAQ 에 Secondary NameNode의 목적에 대해 나와 있습니다.

The only purpose of the secondary name-node is to perform periodic checkpoints. The secondary name-node periodically downloads current name-node image and edits log files, joins them into new image and uploads the new image back to the (primary and the only) name-node.
--> Secondary NameNode는 네임노드의 FsImage와 edits log를 다운로드하여 병합(join)하여 네임노드로 upload 하는 일을 주기적으로 합니다.

--> 위 내용에 따르면 Secondary NameNode가 없어도 동작할 것 같네요.
--> 테스트 결과 동작합니다.