Hadoop Ha 检查点原理_hadoop ha checkpoint-CSDN博客

转载来自：https://blog.csdn.net/amber_amber/article/details/47003589

hdfs将文件系统的元数据信息存放在fsimage和一系列的edits文件中。在启动HDFS集群时，系统会先加载fsimage，然后逐个执行所有Edits文件中的每一条操作，来获取完整的文件系统元数据。

Edits & fsimage文件
HDFS的存储元数据是由fsimage和edits文件组成。fsimage存放上次checkpoint生成的文件系统元数据，Edits存放文件系统操作日志。checkpoint的过程，就是合并fsimage和Edits文件，然后生成最新的fsimage的过程。
Edits文件：在配置了HA的hadoop2.x版本中，active namenode会及时把HDFS的修改信息（创建，修改，删除等）写入到本地目录，和journalnode上的Edits文件，每一个操作以一条数据的形式存放。Edits文件默认每2分钟产生一个。正在写入的Edits文件以edits_inprogress_*格式存在。
fsimage文件： fsimage里保存的是HDFS文件系统的元数据信息。每次checkpoint的时候生成一个新的fsimage文件，fsimage文件同步保存在active namenode上和standby namenode上。是在standby namenode上生成并上传到active namenode上的。

checkpoint过程
配置了HA的HDFS中，有active和standby namenode两个namenode节点。他们的内存中保存了一样的集群元数据信息，这个后续我会详细用一篇文章介绍HA，所以这里就不多说了。因为standby namenode已经将集群状态存储在内存中了，所以创建检查点checkpoint的过程只需要从内存中生成新的fsimage。

详细过程如下：（standby namenode=SbNN， activenamenode=ANN）

1. SBNN查看是否满足创建检查点的条件：

（1）距离上次checkpoint的时间间隔 >= ${dfs.namenode.checkpoint.period}
（2） Edits中的事务条数达到${dfs.namenode.checkpoint.txns}限制
这两个条件任何一个被满足了，就触发一次检查点创建。

2. SbNN将内存中当前的状态保存成一个新的文件，命名为fsimage.ckpt_txid。其中txid是最后一个edit中的最后一条事务的ID（transaction ID）。然后为该fsimage文件创建一个MD5文件，并将fsimage文件重命名为fsimage_txid。

3. SbNN向active namenode发送一条HTTP GET请求。请求中包含了SbNN的域名，端口以及新fsimage的txid。

4. ANN收到请求后，用获取到的信息反过来向SbNN再发送一条HTTP GET请求，获取新的fsimage文件。这个新的fsimage文件传输到ANN上后，也是先命名为fsimage.ckpt_txid，并为它创建一个MD5文件。然后再改名为fsimage_txid。fsimage过程完成。

checkpoint相关配置

dfs.namenode.checkpoint.period
--两次检查点创建之间的固定时间间隔，默认3600，即1小时。

dfs.namenode.checkpoint.txns
--未检查的事务数量。若没检查事务数达到这个值，也触发一次checkpoint，1,000,000。

dfs.namenode.checkpoint.check.period
--standby namenode检查是否满足建立checkpoint的条件的检查周期。默认60，即每1min检查一次。

dfs.namenode.num.checkpoints.retained
--在namenode上保存的fsimage的数目，超出的会被删除。默认保存2个。

dfs.namenode.num.checkpoints.retained
--最多能保存的edits文件个数，默认为1,000,000. 官方解释是为防止standby namenode宕机导致edits文件堆积的情况，设置的限制，不是太明白。

dfs.ha.tail-edits.period
--standby namenode每隔多长时间去检测新的Edits文件。只检测完成了的Edits，不检测inprogress的文件。
=========================================================================================

cloudera 的检查点文档：https://blog.cloudera.com/blog/2014/03/a-guide-to-checkpointing-in-hadoop/

Hadoop中的检查点指南

了解检查点在HDFS中的工作原理可以区分健康的群集或失败的群集。

检查点是在HDFS中维护和保存文件系统元数据的重要部分。这对于有效的NameNode恢复和重启至关重要，并且是整个群集运行状况的重要指标。但是，检查点也可能成为Apache Hadoop集群运营商混淆的根源。

在这篇文章中，我将解释HDFS中检查点的目的，检查点如何在不同的群集配置中工作的技术细节，然后完成一系列操作问题和有关此功能的重要错误修复。

HDFS中的文件系统元数据

首先，让我们首先介绍NameNode如何保留文件系统元数据。

HDFS元数据更改将持久保存到编辑日志中。

在较高的层次上，NameNode的主要职责是存储HDFS命名空间。这意味着目录树，文件权限以及文件到块ID的映射。重要的是，将此元数据（及其所有更改）安全地保存到稳定存储以实现容错。

此文件系统元数据存储在两个不同的结构中：fsimage和编辑日志。fsimage是一个文件，表示文件系统元数据的时间点快照。但是，虽然fsimage文件格式的读取效率非常高，但它不适合进行小的增量更新，例如重命名单个文件。因此，不是每次修改命名空间时都编写新的fsimage，而是NameNode会在编辑日志中记录修改操作的持久性。这样，如果NameNode崩溃，它可以通过首先加载fsimage然后重放编辑日志中的所有操作（也称为编辑或事务）来恢复其状态，以赶上名称系统的最新状态。编辑日志包含一系列文件，称为编辑日志段，

另外，对于传统文件系统来说，在另一种存储格式之上使用日志进行增量更改的这种模式非常常见。日志结构文件系统将这种情况发挥到极致，仅使用日志来保存数据，但更常见的日记文件系统（如EXT3，EXT4和XFS）支持在将日志应用到磁盘上的最终位置之前将更改写入日志。

为什么Checkpointing很重要？

典型的编辑范围从10到100个字节，但随着时间的推移，足够的编辑可能会累积变得难以处理。这些大型编辑日志可能会产生一些问题。在极端情况下，它可以填满节点上的所有可用磁盘容量，但更巧妙的是，大型编辑日志可以在NameNode重新应用所有编辑时显着延迟NameNode启动。这是检查点的来源。

检查点是一个获取fsimage和编辑日志并将它们压缩成新fsimage的过程。这样，NameNode可以直接从fsimage加载最终的内存中状态，而不是重放可能无限制的编辑日志。这是一个更有效的操作，减少了NameNode的启动时间。

Checkpointing从旧的fsimage和编辑日志创建一个新的fsimage。

但是，创建新的fsimage是一种I / O和CPU密集型操作，有时需要几分钟才能完成。在检查点期间，名称系统还需要限制来自其他用户的并发访问。因此，HDFS不会暂停活动的NameNode来执行检查点，而是将其延迟到SecondaryNameNode或Standby NameNode，具体取决于是否配置了NameNode高可用性。检查点的机制取决于是否配置了NameNode高可用性; 我们将涵盖两者。

但在任何一种情况下，检查点都是由两个条件之一触发的：如果自上一个检查点（dfs.namenode.checkpoint.period）以来已经过了足够的时间，或者是否累积了足够的新编辑日志事务（dfs.namenode.checkpoint.txns）。检查点节点定期检查是否满足这些条件中的任何一个（dfs.namenode.checkpoint.check.period），如果满足，则启动检查点过程。

使用备用NameNode检查点

在处理HA设置时，检查点实际上要简单得多，所以让我们先介绍一下。

当的NameNode高可用性配置，活动和备用NameNodes具有一个共享的存储，其中的编辑被存储。通常，这个共享存储是三个或更多JournalNode的集合，但是它从抽象点过程中抽象出来。

备用NameNode通过定期重播由活动NameNode写入共享编辑目录的新编辑来维护命名空间的相对最新版本。因此，检查点就像检查是否满足两个前提条件中的任何一个一样简单，将命名空间保存到新的fsimage（大致相当于hdfs dfsadmin -saveNamespace在命令行上运行），然后通过HTTP将新的fsimage传输到活动的namenode。

配置了NameNode HA的检查点

这里，Standby NameNode缩写为SbNN，Active NameNode缩写为ANN：

SbNN检查是否满足两个前提条件中的任何一个：自上一个检查点以来经过的时间或累计编辑的数量。
SbNN将其名称空间保存到具有中间名称的新fsimage fsimage.ckpt_，其中txid是最新编辑日志事务的事务ID。然后，SbNN为fsimage写入MD5文件，并将fsimage重命名为fsimage_。在此过程中，大多数其他SbNN操作都被阻止。这意味着管理操作，如NameNode故障转移或访问部分SbNN的webui。常规HDFS客户端操作（例如列表，读取和写入文件）不受影响，因为这些操作由ANN提供服务。
SbNN发送一个HTTP GET到活动NN的GetImageServlet在/getimage?putimage=1。URL参数还具有新fsimage的事务ID以及SbNN的主机名和HTTP端口。
活动NN的servlet使用GET请求中的信息反过来自己GET回到SbNN GetImageServlet。与备用数据库类似，它首先使用中间名保存新的fsimage，为fsimage fsimage.ckpt_创建MD5文件，然后将新的fsimage重命名为fsimage_。

使用SecondaryNameNode检查点

在非HA部署中，检查点是在SecondaryNameNode而不是备用NameNode上完成的。由于没有共享编辑目录或编辑日志的自动拖尾，因此在继续执行相同的基本步骤之前，SecondaryNameNode必须首先执行几个步骤来刷新其命名空间视图。

具有注释步骤的2NN和NN的时间图

这里，NameNode缩写为NN，SecondaryNameNode缩写为2NN：

2NN检查是否满足两个前提条件中的任何一个：自上一个检查点以来经过的时间或累计编辑的数量。
- 在没有共享编辑目录的情况下，需要通过显式RPC向NameNode（NamenodeProtocol#getTransactionId）查询最新的编辑日志事务ID 。
2NN触发编辑日志滚动，结束当前编辑日志段并启动新的日志段。NN可以继续编写对新段的编辑，而SNN压缩所有以前的段。这还返回当前fsimage的事务ID和刚刚滚动的编辑日志段。在HA配置中不需要显式触发编辑日志卷，因为备用NameNode会定期将编辑日志滚动到与检查点正交。
给定这两个事务ID，2NN将根据需要获取新的fsimage并编辑文件 GET到NN GetImageServlet。2NN可能已经有一些来自先前检查点的文件（例如当前的fsimage）。
如有必要，2NN将从新下载的fsimage重新加载其命名空间。
2NN重播新的编辑日志段以赶上当前的事务ID。

从这里开始，其余部分与具有StandbyNameNode的HA情况相同。

2NN将其命名空间写入新的fsimage。
2NN通过HTTP GET与NN联系/getimage?putimage=1，导致NN的servlet自己做 GET2NN以下载新的fsimage。

运作影响

与检查点相关的最大操作问题是它何时未能发生。我们已经看到NameNode累积了数百GB编辑日志的情况，在磁盘完全填满并崩溃NN之前没有人注意到。当发生这种情况时，除了重新启动NN并等待它重放所有编辑之外没有太多事情要做。由于此问题的潜在严重性，Cloudera Manager将警告当前fsimage是否已过期，检查点2NN或SbNN是否已关闭，以及NN磁盘是否接近容量。

检查点是一种非常I / O和网络密集型操作，可能会影响客户端性能。在具有数百万个文件和多GB fsimage的大型群集上尤其如此，因为将新的fsimage复制到NameNode会占用所有可用带宽。在这种情况下，传输速度可以受到限制dfs.image.transfer.bandwidthPerSec。如果您确实调整了此参数，则可能还需要dfs.image.transfer.timeout根据预期的传输时间进行调整。

如果您使用的是较早版本的CDH，则还有一些与检查点相关的问题可能会使升级变得有价值。

HDFS-4304（在CDH 4.1.4,4.2.1和4.3.0中修复）。以前，可以编写一个如此大的编辑日志操作，以便在重放编辑日志时无法读取。这将导致检查点和NameNode启动失败。这对于包含大量块的文件来说是一个问题，因为关闭文件涉及将所有块ID写入编辑日志。修复方法是简单地增加允许的最大编辑日志操作的大小。
HDFS-4305 （在CDH 4.3.0中修复）。 与上面的HDFS-4304相关，具有大量块的文件通常是由于配置错误造成的。例如，用户可能会意外地将块大小设置为128KB而不是128MB，或者可能仅将单个reducer用于大型MapReduce作业。通过让NameNode强制执行最小块大小以及每个文件的最大块数来解决此问题。
HDFS-4816（在CDH 4.5.0中修复）。以前，从备用NN到活动NN的映像传输保持备用NN的写锁定。因此，如果活动NN在图像传输期间失败，则备用NN将无法在传输完成之前进行故障转移。由于传输fsimage实际上并不修改任何命名空间数据，因此传输只是移动到临界区之外。
HDFS-4128（在CDH 4.3.0中修复）。如果2NN在编辑日志重放期间遇到内存不足（OOM）异常，它可能会陷入一种不一致的状态，即在将来的检查点尝试期间尝试从不正确的偏移重放编辑日志。因为即使我们修复了日志重放，这个OOM很可能会继续发生，所以如果2NN无法重播日志几次，它现在就会中止。但是，底层修复是使用与NameNode相同的堆大小配置2NN。
HDFS-4300（在CDH 4.3.0中修复）。如果2NN或SbNN在传输编辑文件时遇到错误，则以后不会重试下载完整文件。此过程将停止检查点，因为无法重播部分编辑文件。首先将编辑文件传输到临时位置，然后在传输完成后将其重命名为其最终目标，从而解决了此问题。
HDFS-4569（在CDH4.2.1和CDH4.3.0中修复）。将图像传输超时从1分钟提高到10分钟。默认超时导致使用多GB fsimages进行检查点问题，尤其是在启用限制时。