namenode standby checkponit时间过长导致的问题

我们当前使用的版本是cdh-4.2.1，standby namenode默认每小时生成一个editlog文件，由于操作很多，这个保存时间超过了1分钟。这里面使用了一些读写锁，导致阻塞了其他的一些请求。

HDFS HA的实现

要理解整个过程，先来看看是如何实现hdfs ha的，我自己不懂，只能看其他大神的文章了。 Hadoop 2.0 NameNode HA和Federation实践 Hadoop目前的HA(High Availability)机制分析和源代码研究(1) 基于QJM/Qurom Journal Manager/Paxos的HDFS HA原理及代码分析 还有一些fsimage、editlog的文章见: http://yanbohappy.sinaapp.com/?tag=hdfs 概括一下：

• fsimage是历史的元数据，会定期把editlog合并进来，editlog是最近一段时间对namenode的操作，当前的文件状态等于fsimage+editlog
• Datanode会同时向两个Namenode汇报块信息
• 保证在一个时间内，客户端只会连接active Namenode，由active Namenode负责写editlog（写入QJM），standby Namenode从QJM中获取editlog，更新自己内存中的块信息。这样当standby 变成active时，只用合并最近一小段时间的editlog就可以提供服务了。
• 客户端根据抛出的异常(StandbyException)来切换连接的namenode
• 隔离(fence)，需要避免同时存在两个active Namenode，同时服务，同时往QJM写editlog
• 为了避免namenode启动时合并fsimage和editlog时间过长，standby Namenode 负责定期合并editlog，生成新的fsimage，并且同步给active Namenode。(StandbyCheckpointer) cdh4.2.1 回到原来的问题，在checkpoint时，FSNamesystem有一个ReentrantReadWriteLock fslock，它包含一个读写锁。 读锁时，允许其他线程读，但写操作会被阻塞。 写锁时，其他线程的读写都会被阻塞。 cdh4.2.1版本的代码在checkpoint时，会加上writelock，导致一些rpc操作需要readlock被阻塞。当时检查日志发现failover controller的心跳RPC请求被阻塞了，但没找到它用到这个锁。后来发现NameNodeRpcServer里public synchronized void monitorHealth()方法使用了synchronized，同时还有public synchronized HAServiceStatus getServiceStatus()等方法，在这个类中，同时只允许进入一个synchronized的方法内。在checkpoint期间，getServiceStatus使用了readLock，导致monitorHealth也被阻塞住。

HDFS-5064

Standby checkpoints should not block concurrent readers 找到的第一个补丁是这个，主要修改是在checkpoint的过程中，不应该阻塞那些读操作（如getServiceStatus、monitorHealth）。专门给checkpoint增加了一个读锁fsLongReadLock，在writeLock方法先锁定fsLongReadLock

HDFS-7097

但是这样修改后，依然会阻塞一些需要writeLock的操作，然后有了新的patch

Allow block reports to be processed during checkpointing on standby name node