1. Job Recovery的有关配置项 

2. Job 如何恢复运行 
1) 日志文件：jobtracker restart之后恢复一个正在运行的job，首先通过解析job日志文件，通过job日志文件恢复job的一些task的运行状况。 
2) JT restart之后TT再次连接上JT时向JT汇报他们运行task的情况。 
3) JT重启之后，对1）和2）中没有恢复的task和还没运行的task重新调度运行。 
3. Job Recovery 相关类 
Job Recover过程主要通过JobTracker.RecoveryManager类进行管理，job日志的记录和解析主要有JobHistory类完成。 
4. Job Recover的详细过程 
1) JobTracker restart之后首先检查是否有需要恢复的job，通过RecoveryManager. checkAndAddJob()实现。 
2) 如果有要恢复的job，在offerService()中启动RecoverManager.recover()开始恢复job： 
(1) 初始化jobs，根据"mapred.system.dir"目录文件信息缓存需要恢复job的JobID以及该job history日志文件路径。 
(2)在日志文件中恢复job：根据job恢复日志的路径得到恢复日志，首先通过 JobHistory.parseHistoryFromFS(String path, Listener l, FileSystem fs)解析job日志文件，提取日志文件的每一行信息（path是指日志文件的路径，Listener是一个监听器），然后通过 JobRecoveryListener.handle()来处理每行日志信息恢复job运行状况。 
3) 所有job日志文件解析恢复完成之后，TaskTracker重新连接上JT的时候，TT会向JT汇报他们上面运行的task状况，实现过程如下（在 JobTracker.updateTaskStatuses(TaskTrackerStatus status)中）： 
if (tip != null || hasRestarted()) { 
if (tip == null) { 
tip = job.getTaskInProgress(taskId.getTaskID()); 
job.addRunningTaskToTIP(tip, taskId, status, false); 
} 
} 
5. 总结：虽然hadoop提供了Jobtracker restart之后job recover过程，最近在做JobTracker HA，发现但该过程还存在着很多问题 
1) Job日志有缓存，刷入日志文件不急时，这个可能导致的问题： 
(1) jobtracker restart 之后job恢复运行的时候会出现task失去连接： 
2012-02-16 17:11:49,224 INFO org.apache.hadoop.mapred.JobTracker: attempt_201202161703_0002_m_000039_0 is 200024 ms debug. 
attempt_201202161703_0002_m_000039_0 is 400036 ms debug. 
attempt_201202161703_0002_m_000039_0 is 600047 ms debug. 
Launching task attempt_201202161703_0002_m_000039_0 timed out. 
这样需要等9分钟之后确定该task timeout之后才会重新再运行该task 
原因：由于日志刷入日志文件不够及时，日志文件中记录有一个task的attempt task启动时的信息，而没记录他运行结束时的信息（其实已经运行成功），job恢复的时候，Jt误认为该task还在运行，然后一直等TT向它汇报该 task的信息，直到该task timeout。（实际该task在JT重启前已经完成了，所有JT重启之后，TT不会再汇报该task的状态） 
(2)一个小job，所有task都在运行，job日志还没刷入日志文件，这时重启JT的时候，job 再运行的时候出现cleanup job在setup job完成之前完成，导致JT一直认为这个job还在运行中。 
(3)JT restart之后重新运行job出现job的reduce task比map task先完成的情况