hadoop面试100道收集（带答案） – Jimmy Huang 的专栏 – 博客频道 – CSDN.NET
http://blog.csdn.net/kingmax54212008/article/details/51257067
9、你在项目中遇到了哪些难题，是怎么解决的？
某些任务执行时间过长，且失败率过高，检查日志后发现没有执行完就失败，原因出在
hadoop 的 job 的 timeout 过短（相对于集群的能力来说），设置长一点即可

一次Hadoop集群宕机事故总结 – sdn_prc的专栏 – 博客频道 – CSDN.NET
http://blog.csdn.net/sdn_prc/article/details/49802673
10月27日下午，机房中心交换机坏掉，导致HDFS集群和MR（YARN）集群宕掉。当时的日志现在已查不到，只能推断整个集群宕掉的原因。HDFS和YARN的集群，都是master/slave模式，其中处于master角色的组件有：NameNode，ResourceManager。某种角度，只要master没有挂掉，可以认为集群没有挂掉。同时，我们的HDFS集群和YARN集群都配置了HA，所以master角色可以认为还包括standby NN和standby RMs。在HDFS HA集群中，JournalNodes也是很重要的角色，因为JN group一旦挂掉或仅仅无法与NNs通信，NNs都不能正常工作。HDFS HA和YARN HA也都依赖Zookeeper集群。10月27日下午，交换机坏掉后，active NN与其他所有机器都不能通信，包括JNs，这导致active NN shutdown。因为之前standby NN是stop的状态，所以无法进行HA切换。实际上，即使能切换，standby NN所在的机器与其他集群不能通信。所以，这导致HDFS集群整个挂掉。一个相关的issue：https://issues.apache.org/jira/browse/HDFS-8298。因为YARN集群配置了HA（实际之前ops没有配置完整，仅仅是相当于打开了RM HA的开关，其他必要的与RM Restart相关的配置都没有），当天下午交换机坏掉后，active RM与ZK失联，自动切换到standby RM，但由于配置不完善（这个很致命），同时standby RM与ZK也是失联的，导致没有RM可以正常工作，YARN集群整个挂掉。这是当时ops收到的一条报警：Info:Critical! Yarn ResourceManager host 192.168.146.64 status have problem, status is ACTIVE! Time: Tue+Oct+27+19:06:41+CST+201。当天下午交换机临时回复后，我们对Hadoop集群依次进行了以下操作：1、启动active NN2、启动DataNodes3、启动active RM4、启动standby NN第一步active NN正常启动，但由于standby NN已经停了两个多月，active NN在启动时，对fsimage和edits进行checkpoint耗时过多，导致active NN启动时间过长。第二步没有问题。第三步基本没有问题，但由于没有配置RM Restart，导致所有未完成的jobs需要重新提交和执行。第四步也是正常启动，但也由于standby NN已经停了两个多月，JNs上需要checkpoint的edits过多，导致启动时间超长，而且checkpoint占用大量时间。

关于机房交换机故障导致HDFS NameNode挂掉的问题（续） – sdn_prc的专栏 – 博客频道 – CSDN.NET
http://blog.csdn.net/sdn_prc/article/details/49887537
过程是痛苦的，后面的结论是令人不安的。

上一篇的分析，确定了至少两个个结论：
一、如果总体上active NN写JNs出问题，那么active NN就主动调用terminate，进程退出；
二、JNs的相关的一个配置项：dfs.namenode.shared.edits.dir，这个配置项中出现的JN的信息，对NN来说一定是“required”的。

这篇后续的分析，解释“总体上active NN写JNs出问题”，是怎么回事。以上一篇相反的另一个方向的思路，分析问题是怎么导致的，以及解释代码与QJM的quorum机制是否一致（答案必然是肯定的了）。

还是从active NN FATAL log说起。

到这里，结合上面结论就很明显了：active NN往JNs写edit log时，不能够在quorum中写成功（写超时），导致抛出异常（TimeoutException）。更深层次的原因，可能是网络原因，或者JVM GC的原因。GC日志找不到了，不好确定。网络方面，并不能说网络不好，应该说，是网络状况没有达到上面的配置项（dfs.qjournal.write-txns.timeout.ms）所要求的程度。所以，最直接的解决办法，就是增大这个配置项的值，现在是默认的20000毫秒。保险起见，最好把QuorumJournalManager.java中涉及的关于timeout的配置项都增大。同时，必须意识到，在极端情况下，HA的两个NN都可能因为这个原因退出，导致整个HDFS集群不可用。

Namenode写Journalnode超时，导致Namenode挂掉的问题 – 豪放婉约派程序员 – 博客园
http://www.cnblogs.com/xyliao/p/5755438.html
其实在实际的生产环境中，也很容易发生类似的这种超时情况，所以我们需要把默认的20s超时改成更大的值，比如60s。
我们可以在hadoop/etc/hadoop下的hdfs-site.xml中，加入一组配置:
<property> <name>dfs.qjournal.write-txns.timeout.ms</name> <value>60000</value></property>

这也是我从别人博客中看到的配置方法，神奇的是，我在hadoop的官网中的关于hdfs-site.xml介绍中，居然找不到关于这个配置的说明。。。
http://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/hdfs-default.xml