hdfs 故障切换

hdfs 集群为我们提供分布式的存储资源，hdfs 主要由namenode 和 datanode 组件构成，文件在hdfs中是以块来存储的，根据文件大小占用一个block或多个block。namenode 主要记录着文件目录信息，block映射信息等元数据，而datanode则真正负责文件的读写。hdfs 集群中存在着多个datanode，文件可以以多个副本存储在不同的datanode节点中，因此，当某个datanode故障不能提供服务时，存储在该datanode的文件数据可由其文件数据副本所在的datanode代替故障datanode提供服务。而当namenode故障时，那么hdfs集群将不能正常的提供服务。因此，本文主要讲解namenode 的故障切换。

hadoop 1.x namenode 故障切换主要是secondary namenode,而到了hadoop 2.x则提供了hdfs ha 故障自动切换机制。本篇主要讲解 secondary namenode 架构以及实现方式。

在讲解secondary namenode 之前，首先先讲解下fsimage 镜像文件以及edit文件，fsimage 文件记录这namenode的数据，包括所有的目录和文件以及序列化信息，而edit则记录着所有写或更新信息。当hdfs启动时，namenode首先会先加载fsimage文件，然后在加载相应的edit文件。两个数据合并后共同组成了namenode全量信息。

secondarynamenode的作用

secondarynamenode 按一定规则将edits文件和fsimage文件合并，合并后namenode会启用新的edits文件，这样会减小edits文件的文件大小，控制edits文件的大小会减少namenode在启动阶段解析加载edits文件的时长。

secondarynamenode合并文件规则

配置 fs.checkpoint.period 执行检查点合并文件检查时间 默认3600s

fs.checkpoint.size 实行检查点合并文件阀值大小 默认64M

两个条件满足其一则合并文件

工作原理示意图

image.png

架构分析

fsimage与edits文件对于namenode存储数据有什么区别，为什么要分开两个文件进行存储?

fsimage存储着所有目录和文件的序列化信息，而edits保存了所有写或更新的信息，在namenode运行过程中只向edits文件中写相关的操作信息和文件信息

分两个文件存储是因为fsimage由于保存了所有namenode的信息，所以文件大小通常比较大，这样在一个大的文件中进行写操作比较费系统资源而且延迟了系统的反应时间，而edits文件由于有secondarynamenode进行合并，通常大小要小于fsimage，所以在edits文件中进行更新写操作会降低系统资源的消耗。

为什么会引入sencondarynamenode，只用namenode会有什么问题?

由于namenode进行分文件保存，但又不能使edits文件过大，所以需要进行文件合并，但进行文件合并会占用系统内存等资源，如果直接使用namenode进行文件合并，会导致在合并文件期间，系统文件管理能力下降卡顿等。另外由于secondarynamenode与namenode进行分离，可以将namenode和secondarynamenode分开部署到不同机器上，提高系统的稳定与安全性。除此之外，secondarynamenode由于进行了检查点，在namenode完全宕机数据丢失的情况下，secondarynamenode可以在检查点上恢复系统数据，当然，也会造成检查点之后的数据丢失。