账本持久化：FsImage、EditLog，和那个不是备机的 checkpoint

动机：内存快，但断电就没。 NameNode 把账本放内存里图快，但一断电、一崩溃账本就没了。所以持久化必须把每次变更记到可靠的地方，又不能让每次操作都慢到磁盘速度。

两个结构，一条规则。 FsImage 是某一时刻整本账的快照：那一刻完整的目录树、文件到块的列表、权限。EditLog 是快照之后每次变更的只追加日志，按顺序记。规则是先记日志、再改内存：变更先追加进 EditLog，再应用到内存账本，这样崩在两者之间时，日志永远领先于内存，不会落后。

重启就是重放。 重启时 NameNode 载入 FsImage，再按顺序重放 EditLog，重建出最后一次记账时的账本。这和数据库的 WAL 恢复是同构的：一份快照加一份此后全部变更的日志，按序重放。说到底，NameNode 本质上是一个很大的文件寻址系统——但要修正一下：它是寻址与目录中心，不是总线，数据不经过它，只经过地址。

日志会长，所以要 checkpoint。 不管的话 EditLog 会无限长下去，重启重放越来越慢。定期把 FsImage 和 EditLog 合并成一份新的 FsImage，再开一份空的 EditLog。这个合并工作就叫 checkpoint。

Secondary NameNode 不是备机。 做合并的就是 Secondary NameNode：它取回 FsImage 和 EditLog、合并、把新 FsImage 交回去。它没有实时账本、不服务客户端、NameNode 死它也接管不了。把它叫成备用 NameNode，是对这个部件最经典的误解。HA 下合并由 standby NameNode 做，不再用 Secondary NameNode，见 ha-and-fencing。