Secondary NameNode
At the time when NameNode starts it reads HDFS state from an image file (FsImage) at first, then from the edits log file, it applies edits and further, the NameNode writes new HDFS state to the FsImage. and afterward, it starts normal operation with an empty edits file. Moreover, NameNode merges FsImage and edits files, at the time of start-up, hence the edit log file could get very large over time. Well, next restart of Namenode takes longer, as a side effect of a larger edits file.
Secondary Namenode solves this issue
As its job, it simply downloads the FsImage and EditLogs from the NameNode then merges EditLogs with the FsImage (FileSystem Image). Though, it keeps edits log size within a limit only. Further, it keeps the modified FsImage into persistent storage. So, in the case of NameNode failure, we can use it.
In addition, it performs a regular checkpoint, in HDFS.
l