HDFS数据恢复模式

时间：2023-01-15 07:25:29

前言

在现有的HDFS中，为了保证元数据的高可用性，我们可以在配置项dfs.namenode.name.dir中配置多个元数据存储目录来达到多备份的作用。这样一来，如果其中一个目录文件损坏了，我们可以选择另外可用的文件。那么问题来了，如果所有备用的元数据都损坏了，不能用了，这个时候怎么办，那么是否就意味着集群就永远启动不起来了呢？这将会是一个多么糟糕的结果啊。在这里，我们就要引出本文的主题：HDFS的数据恢复模式（Recovery Mode）。

HDFS数据恢复模式概述

HDFS数据恢复模式的使用场景如前文中所提到的，当系统遭遇到硬件问题或软件层面的问题导致文件损坏，从而导致NameNode无法正常启动，这个时候数据恢复模式就派上用场了。更全面地来说，HDFS数据恢复模式实质上是一种元数据自我恢复的启动模式。所以它并不是DataNode上真实数据的恢复，这一点可能容易被人误解。

其次，数据恢复针对的情况是损坏状态下的editlog，而不是fsImage，fsImage是恢复后生成的。

HDFS数据恢复模式原理

当editlog文件损坏的时候，如果我们启动了NameNode,很显然NameNode会在apply editlog的时候抛出异常，从而导致NameNode启动失败。而在Recovery Mode模式下，NameNode则会智能地跳过这些错误情况，从而保证NameNode启动成功。在启动完NameNode之后，它会生出一个新的Fsimage，然后再次退出，下次集群管理员就可以正常的方式来启动集群了，因为此时用的是新的fsImage。图示过程如下：


HDFS数据恢复模式
图 1-1 HDFS数据恢复模式原理图

HDFS数据恢复模式核心代码的实现

本节我们从代码层面来学习HDFS数据恢复模式是如何实现的，主要涉及到的类有NameNode，FSNamesystem，FSImage，FSEditLogLoader。

数据恢复模式的启动入口是hdfs namenode -recover命令，相应地就对应到了NameNode的处理方法，代码如下：

  public static NameNode createNameNode(String argv[], Configuration conf)
      throws IOException {
    LOG.info("createNameNode " + Arrays.asList(argv));
if (conf == null)
      conf = new HdfsConfiguration();
    // Parse out some generic args into Configuration.
    GenericOptionsParser hParser = new GenericOptionsParser(conf, argv);
    argv = hParser.getRemainingArgs();
    // Parse the rest, NN specific args.
    StartupOption startOpt = parseArguments(argv);
...

switch (startOpt) {
      case FORMAT: {
...
      case RECOVER: {
        // reconver参数对应的启动模式
        NameNode.doRecovery(startOpt, conf);
return null;
      }
...

然后我们进入doRecovery方法，

  private static void doRecovery(StartupOption startOpt, Configuration conf)
      throws IOException {
    String nsId = DFSUtil.getNamenodeNameServiceId(conf);
    String namenodeId = HAUtil.getNameNodeId(conf, nsId);
    initializeGenericKeys(conf, nsId, namenodeId);
...
try {
      // 进入FSNamesystem内的处理方法，此刻开始正式进入数据恢复过程
      fsn = FSNamesystem.loadFromDisk(conf);
      fsn.getFSImage().saveNamespace(fsn);
...

中间会经过FSNamesystem.loadFSImage(startOpt)，进入此方法，

  private void loadFSImage(StartupOption startOpt) throws IOException {
final FSImage fsImage = getFSImage();

// format before starting up if requested
if (startOpt == StartupOption.FORMAT) {

      fsImage.format(this, fsImage.getStorage().determineClusterId());// reuse current id

      startOpt = StartupOption.REGULAR;
    }
boolean success = false;
    writeLock();
try {
// 构造数据恢复上下文对象
      MetaRecoveryContext recovery = startOpt.createRecoveryContext();
// 进行新的镜像文件的生成过程
final boolean staleImage
          = fsImage.recoverTransitionRead(startOpt, this, recovery);
      ...

这里我们进入最终的FSImage的loadFSImage方法，

  private boolean loadFSImage(FSNamesystem target, StartupOption startOpt,
      MetaRecoveryContext recovery)
      throws IOException {
    final boolean rollingRollback
        = RollingUpgradeStartupOption.ROLLBACK.matches(startOpt);
    final EnumSet<NameNodeFile> nnfs;
...
    Iterable<EditLogInputStream> editStreams = null;

    initEditLog(startOpt);

...
    Exception le = null;
    FSImageFile imageFile = null;
    // 遍历fsImage所存储的多个备份目录
for (int i = 0; i < imageFiles.size(); i++) {
try {
        imageFile = imageFiles.get(i);
        // 加载此镜像文件，加载成功一个即可
        loadFSImageFile(target, recovery, imageFile, startOpt);
break;
      } catch (IllegalReservedPathException ie) {
...
      }
    }
...

if (!rollingRollback) {
      // 然后进行editlog的加载
      long txnsAdvanced = loadEdits(editStreams, target, startOpt, recovery);
      needToSave |= needsResaveBasedOnStaleCheckpoint(imageFile.getFile(),
          txnsAdvanced);
    }
...

OK，到了这里，我们终于找到了editlog加载的入口了，loadEdits也将是我们所要重点关注的，因为在此过程中，实现了Recovery Mode中最为关键的跳过错误记录的逻辑。

FSEditLogLoader的loadEdits过程

我们直接进入loadEdit方法，

  long loadFSEdits(EditLogInputStream edits, long expectedStartingTxId,
      StartupOption startOpt, MetaRecoveryContext recovery) throws IOException {
    StartupProgress prog = NameNode.getStartupProgress();
    Step step = createStartupProgressStep(edits);
    prog.beginStep(Phase.LOADING_EDITS, step);
    fsNamesys.writeLock();
try {
      long startTime = monotonicNow();
      FSImage.LOG.info("Start loading edits file " + edits.getName());
      // 传入期望的起始txid,恢复模式上下文
      long numEdits = loadEditRecords(edits, false, expectedStartingTxId,
          startOpt, recovery);
...

我们继续进入此方法，

  long loadEditRecords(EditLogInputStream in, boolean closeOnExit,
      long expectedStartingTxId, StartupOption startOpt,
      MetaRecoveryContext recovery) throws IOException {
...
try {
while (true) {
try {
          FSEditLogOp op;
try {
            // 从editlog输入流中读取下一个操作记录
            op = in.readOp();
if (op == null) {
break;
            }
          } catch (Throwable e) {
            // 如果出现文件损坏的情况，此处会抛出异常
            //...
            // 如果不是处于数据恢复的启动方式下，则会抛出异常
if (recovery == null) {
               // We will only try to skip over problematic opcodes when in
               // recovery mode.
              throw new EditLogInputException(errorMessage, e, numEdits);
            }
            MetaRecoveryContext.editLogLoaderPrompt(
"We failed to read txId " + expectedTxId,
                recovery, "skipping the bad section in the log");
            // 如果处于Recovery Mode模式，则此处会跳过错误记录，重新定位到下一个有效的操作记录
            in.resync();
            continue;
          }
...

从上面的方法中，我们基本就知道了它是如何跳过错误的editlog记录的。读到了有效的editlog记录之后，就是把它apply到内存的操作了，

          ...
          recentOpcodeOffsets[(int)(numEdits % recentOpcodeOffsets.length)] =
            in.getPosition();
if (op.hasTransactionId()) {
            // 如果当前读到的事务id大于期待的值，说明中间有被忽略的editlog记录，打出提醒信息
if (op.getTransactionId() > expectedTxId) { 
              MetaRecoveryContext.editLogLoaderPrompt("There appears " +
"to be a gap in the edit log. We expected txid " +
                  expectedTxId + ", but got txid " +
                  op.getTransactionId() + ".", recovery, "ignoring missing " +
" transaction IDs");
            } else if (op.getTransactionId() < expectedTxId) { 
              MetaRecoveryContext.editLogLoaderPrompt("There appears " +
"to be an out-of-order edit in the edit log. We " +
"expected txid " + expectedTxId + ", but got txid " +
                  op.getTransactionId() + ".", recovery,
"skipping the out-of-order edit");
              continue;
            }
          }
try {
if (LOG.isTraceEnabled()) {
              LOG.trace("op=" + op + ", startOpt=" + startOpt
                  + ", numEdits=" + numEdits + ", totalEdits=" + totalEdits);
            }
            // Apply此记录到NameNode内存中
            long inodeId = applyEditLogOp(op, fsDir, startOpt,
                in.getVersion(true), lastInodeId);
...

然后以上操作都完成之后，NameNode会执行一次saveNamespace的动作，就会生成一个新的可用的fsImage了，代码如下：

  private static void doRecovery(StartupOption startOpt, Configuration conf)
      throws IOException {
...
    NameNode.initMetrics(conf, startOpt.toNodeRole());
    FSNamesystem fsn = null;
try {
      fsn = FSNamesystem.loadFromDisk(conf);
      // 加载完editlog之后，执行一次saveNamespace生成一个新的fsImage
      fsn.getFSImage().saveNamespace(fsn);
      MetaRecoveryContext.LOG.info("RECOVERY COMPLETE");
...

到了这里，整个代码的执行流程就结束了。执行流程图如下：


HDFS数据恢复模式
图 1-2 HDFS数据恢复模式执行流程图

有效editlog的定位寻找

最后我们再来关注一下之前跳过editlog的具体操作逻辑，就是rsync方法，

  public void resync() {
if (cachedOp != null) {
return;
    }
// 定位到下一个有效的editlog操作记录
    cachedOp = nextValidOp();
  }

然后我们定位到其具体的子类实现，位于类EditLogFileInputStream中，

  protected FSEditLogOp nextValidOp() {
try {
// 这里的true参数代表着要跳过坏的editlog记录
return nextOpImpl(true);
    } catch (Throwable e) {
      LOG.error("nextValidOp: got exception while reading " + this, e);
return null;
    }
  }

上面方法最终将会执行到FSEditLogOp.Reader.readOp方法，执行逻辑如下，

    public FSEditLogOp readOp(boolean skipBrokenEdits) throws IOException {
      // 循环读取Op操作记录，直到找到一个有效的记录
while (true) {
try {
return decodeOp();
        } catch (IOException e) {
          in.reset();
if (!skipBrokenEdits) {
            throw e;
          }
        } catch (RuntimeException e) {
...
          // 判断是否跳过坏的edit记录,如果不跳过，此处将会抛出异常
if (!skipBrokenEdits) {
            throw e;
          }
        } catch (Throwable e) {
          in.reset();
          // 判断是否跳过坏的edit记录,如果不跳过，此处将会抛出异常
if (!skipBrokenEdits) {
            throw new IOException("got unexpected exception " +
                e.getMessage(), e);
          }
        }
...
      }
    }

HDFS数据恢复模式使用

前面已经提到过，HDFS数据恢复模式实质上是一种NameNode的启动方式，我们可以通过指定启动NameNode的参数来选择是否以这样的方式启动NameNode，输入hdfs namenode -help即可获取这些参数，

$ hdfs namenode -help
Usage: java NameNode [-backup] | 
    [-checkpoint] | 
...
    [-bootstrapStandby] | 
    [-recover [ -force] ] | // 以数据恢复模式的启动方式，force参数表示后面所有的提醒都默认选择第一个
    [-metadataVersion ]  ]

此种方式与之前脚本启动方式略有不同的一点在于，此类方式是前台启动的，用户能直观地看到NameNode的启动过程。

参考资料

[1].https://issues.apache.org/jira/browse/HDFS-3004
[2].https://issues.apache.org/jira/secure/attachment/12542798/recovery-mode.pdf
标签：

相关文章