<commit_before>---
layout: post
category: hadoop
date: 2017-04-08 09:30:55 UTC
title: Hadoop基础之ResourceManager重启过程中的恢复机制
tags: [重启恢复，RPC通讯，Znode，Zookeeper高可用]
permalink: /hadoop/resourcemanager-restart
key: 07ad3cd4d543af43685fd86c1cb207b6
description: 本文介绍了ResourceManger重启过程的恢复机制以及具体配置
keywords: [重启恢复，RPC通讯，Znode，Zookeeper高可用]
---

周五的时候，向Hadoop集群提交了一个任务，运行的过程中ResourceManager进程由于某些原因突然中止了。通过**yarn-daemon.sh start resourcemanager**命令重启之后，发现之前的应用仍然顺利执行。猜想可能是由于ResourceManager重启恢复的某种机制才能保证了应用的继续运行。通过[官网中的ResourceManger Restart](https://hadoop.apache.org/docs/r2.7.2/hadoop-yarn/hadoop-yarn-site/ResourceManagerRestart.html)找到一些答案，现整理如下。

##重启过程

为了降低ResourceManager重启带来的影响，它就必须在正常运行时去记录一些状态信息，这样在重启之后才能去获取并且构造对应状态的实例。这个过程经历了两个阶段的发展:

<ul class="item">
    <li>
        <p>
<b>不保留当前应用执行状态的重启(non-work-preserving restart): </b>当ResourceManager重启之后，它必须知道之前的应用(application)处于什么状态(ACCEPTED、RUNNING、FAILED、FINISHED等)。在Hadoop 2.4的时候，ResourceManager会存储应用的元数据(i.e ApplicationSubmissonContext)以及应用状态到某种存储介质中(Zookeeper, HDFS)等。重启之后，它会获取相应的信息，然后重新提交应用而不需要用户再次提交(如果应用在ResourceManager中止之前应用已经完成--FINISHED、FAILED、KILLED--则不会再次提交)。
        </p>
        <p>
        在ResourceManager挂掉之后，NodeManagers和客户端会持续发送心跳来检测它的状态。等到它重启之后，ResourceManager会发送重新同步的命令(re-sync)给所有的NodeManager，而当时的行为就是杀掉所有的NodeManager然后重启，并且重新在ResourceManager中注册。
        </p>
        <p>
        由此可见，之前应用不会在ResourceManager重启之后继续工作，而是重新开始了一次尝试(attempt)，所以该阶段也被称为<b class="highlight">不保留当前应用执行状态的重启</b>
        </p>
    </li>
    <li>
        <p>
        <b>保留当前应用执行状态的重启(work-preserving restart): </b>在ResourceManger重启机制的第一阶段，虽然可以做到应用的重新提交(re-kick application)，但任务的执行状态却没有得到延续。所以在2.6版本中该功能得到进一步加强。
        </p><commit_msg>change word spelling<commit_after>---
layout: post
category: hadoop
date: 2017-04-08 09:30:55 UTC
title: Hadoop基础之ResourceManager重启过程中的恢复机制
tags: [重启恢复，RPC通讯，Znode，Zookeeper高可用]
permalink: /hadoop/resourcemanager-restart
key: 07ad3cd4d543af43685fd86c1cb207b6
description: 本文介绍了ResourceManager重启过程的恢复机制以及具体配置
keywords: [重启恢复，RPC通讯，Znode，Zookeeper高可用]
---

周五的时候，向Hadoop集群提交了一个任务，运行的过程中ResourceManager进程由于某些原因突然中止了。通过**yarn-daemon.sh start resourcemanager**命令重启之后，发现之前的应用仍然顺利执行。猜想可能是由于ResourceManager重启恢复的某种机制才能保证了应用的继续运行。通过[官网中的ResourceManger Restart](https://hadoop.apache.org/docs/r2.7.2/hadoop-yarn/hadoop-yarn-site/ResourceManagerRestart.html)找到一些答案，现整理如下。

##重启过程

为了降低ResourceManager重启带来的影响，它就必须在正常运行时去记录一些状态信息，这样在重启之后才能去获取并且构造对应状态的实例。这个过程经历了两个阶段的发展:

<ul class="item">
    <li>
        <p>
<b>不保留当前应用执行状态的重启(non-work-preserving restart): </b>当ResourceManager重启之后，它必须知道之前的应用(application)处于什么状态(ACCEPTED、RUNNING、FAILED、FINISHED等)。在Hadoop 2.4的时候，ResourceManager会存储应用的元数据(i.e ApplicationSubmissonContext)以及应用状态到某种存储介质中(Zookeeper, HDFS)等。重启之后，它会获取相应的信息，然后重新提交应用而不需要用户再次提交(如果应用在ResourceManager中止之前应用已经完成--FINISHED、FAILED、KILLED--则不会再次提交)。
        </p>
        <p>
        在ResourceManager挂掉之后，NodeManagers和客户端会持续发送心跳来检测它的状态。等到它重启之后，ResourceManager会发送重新同步的命令(re-sync)给所有的NodeManager，而当时的行为就是杀掉所有的NodeManager然后重启，并且重新在ResourceManager中注册。
        </p>
        <p>
        由此可见，之前应用不会在ResourceManager重启之后继续工作，而是重新开始了一次尝试(attempt)，所以该阶段也被称为<b class="highlight">不保留当前应用执行状态的重启</b>
        </p>
    </li>
    <li>
        <p>
        <b>保留当前应用执行状态的重启(work-preserving restart): </b>在ResourceManger重启机制的第一阶段，虽然可以做到应用的重新提交(re-kick application)，但任务的执行状态却没有得到延续。所以在2.6版本中该功能得到进一步加强。
        </p>
{'fraction_non_alphanumeric': 0.11018463371054199, 'fraction_numerical': 0.023823704586063133, 'mean_word_length': 7.13317191283293, 'pattern_counts': {'":': 0, '<': 39, '<?xml version=': 0, '>': 39, 'https://': 2, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2766001', 'n_tokens_mistral': 1952, 'n_tokens_neox': 2182, 'n_words': 107}