Article Directory
5. Do you understand the Secondary NameNode and how does it work?
The Secondary NameNode merges the edit logs of the NameNode into the fsimage file; its specific working mechanism:
(1) The Secondary NameNode asks whether the NameNode needs a checkpoint. Bring back the result of NameNode check directly
(2) Secondary NameNode requests to execute checkpoint
(3) NameNode scrolls the edits log being written
(4) Copy the edit log and mirror file before rolling to the Secondary NameNode
(5) Secondary NameNode loads the edit log and Mirror file to memory and merge
(6) Generate a new mirror file fsimage.chkpoint
(7) Copy fsimage.chkpoint to NameNode
(8) NameNode rename fsimage.chkpoint to fsimage So if the metadata in NameNode is lost, it is okay Part of the metadata information is recovered from the Secondary NameNode, but not all, because the edits log being written by the NameNode has not been copied to the Secondary NameNode, and this part cannot be recovered.
Another easy-to-understand version:
1. secnonaryNN informs NameNode to switch editlog and generate edits.new
2. SecondaryNN obtains FSImage and editlog from NameNode (via http), loads FSImage into memory, and then starts to merge editlog, which will become the new fsimage
3. SecondaryNN will be new Send the fsimage.ckpt back to NameNode
4. NameNode replaces the old fsimage
with the new fsimage.ckpt 5. NameNode replaces the old edits with the new edits.new