HBase写被block的分析
来源:互联网 发布:电视盒子破解软件 编辑:程序博客网 时间:2024/05/16 12:55
一个线上集群出现莫名奇妙不能写入数据的bug,log中不断打印如下信息:
我们知道每次put时会检查当前的memstore大小,当大于flush值的一个系数时(系数默认为2倍),就会block住这次写请求,并提交一个flush任务。但是很奇怪的是,用户此时再也不能往这个region写数据了,并在大约10多个小时以后又神奇地自然恢复了。
原因是什么呢?
经过一番检查,发现了hbase的一个bug,我们准备修改后提交到社区,不过因为实在太有趣了,体现了分布式事务的很有趣特征,所以先在此分享一下原因吧。
这个问题是由以下四个事件共同组成的,我把代码简单化后作如下整理:
1 put:
2 memstoreFlusher:
3 split:
4 rollback:
故障还原:当该region执行一次flush时,flushRequested被put线程置为了true,并push一个flush任务。然后memstoreFlusher检查到该任务时,刚好split开始进行,进行到了CLOSED_PARENT_REGION那一步,处于closing状态,于是memstoreflusher跳过任务,但在这里,memstoreflusher仍然报告该任务完成了,于是flush队列被清空。
但split在执行splitStoreFiles时,因为hdfs的问题失败了(具体原因是namenode在close一个文件的时候失败,不停地retry并超时),此时split开始执行回滚,即该region恢复到split之前的状态,于是我们发现该region又重新onlined。
虽然split在rollback的时候会将closing和closed状态置回来,但因为flush队列己然被清空了,于是陷入以下循环:
以上悲催的情况将一直持续,直到迎来cleanOldLogs任务。因为cleanOldLogs会每小时执行一次,它会将最早的.logs目录下的文件移到.oldlogs目录下,但移之前先检查该文件中所有的数据是否己经flush到磁盘了,如果还没有就将该region执行一次flush。所以在经过n小时以后,.logs终于滚动到了用户之前卡住的那一段,这时就强制执行flush任务,因此flushQueue队列就不为空了,死循环被打破。系统也就自愈了。
引用
2011-11-09 07:35:45,911 INFO org.apache.hadoop.hbase.regionserver.HRegion: Blocking updates for 'IPC Server handler 32 on 60020' on
region xxx,333-2395000000032117,1320773734010.9a7ae39b5a42ccfa1fa6118aa8f79195.: memstore size 128.0m is >= than blocking 128.0m size
region xxx,333-2395000000032117,1320773734010.9a7ae39b5a42ccfa1fa6118aa8f79195.: memstore size 128.0m is >= than blocking 128.0m size
我们知道每次put时会检查当前的memstore大小,当大于flush值的一个系数时(系数默认为2倍),就会block住这次写请求,并提交一个flush任务。但是很奇怪的是,用户此时再也不能往这个region写数据了,并在大约10多个小时以后又神奇地自然恢复了。
原因是什么呢?
经过一番检查,发现了hbase的一个bug,我们准备修改后提交到社区,不过因为实在太有趣了,体现了分布式事务的很有趣特征,所以先在此分享一下原因吧。
这个问题是由以下四个事件共同组成的,我把代码简单化后作如下整理:
1 put:
- put{
- checkResources{
- while (this.memstoreSize.get() > this.blockingMemStoreSize) {
- if(flushRequested==true)
- continue;
- flushRequested = true;
- flushQueue.add(this);
- }
- ...
- }
- ...
- }
2 memstoreFlusher:
- while(!serverstop){
- task = flushQueue.poll();
- if(task == null)
- continue;
- if(closing)
- continue;
- try{
- if(closed)
- continue;
- if(flush(task))
- continue;
- else
- break;
- }finally{
- flushRequested = false;
- }
- }
3 split:
- ...
- closing = true;
- closed = true;
- ...
4 rollback:
- ...
- closing = false;
- closed = false;
- ...
故障还原:当该region执行一次flush时,flushRequested被put线程置为了true,并push一个flush任务。然后memstoreFlusher检查到该任务时,刚好split开始进行,进行到了CLOSED_PARENT_REGION那一步,处于closing状态,于是memstoreflusher跳过任务,但在这里,memstoreflusher仍然报告该任务完成了,于是flush队列被清空。
但split在执行splitStoreFiles时,因为hdfs的问题失败了(具体原因是namenode在close一个文件的时候失败,不停地retry并超时),此时split开始执行回滚,即该region恢复到split之前的状态,于是我们发现该region又重新onlined。
虽然split在rollback的时候会将closing和closed状态置回来,但因为flush队列己然被清空了,于是陷入以下循环:
- put数据的线程,发现需要flush,但flushRequested为true,说明还有flush任务没完成,于是继续等待,并不会提交flush任务
- memstoreFlush的线程,每次取flushQueue都为空,于是循环等待put线程提交flush任务,因此写数据就被block住了
以上悲催的情况将一直持续,直到迎来cleanOldLogs任务。因为cleanOldLogs会每小时执行一次,它会将最早的.logs目录下的文件移到.oldlogs目录下,但移之前先检查该文件中所有的数据是否己经flush到磁盘了,如果还没有就将该region执行一次flush。所以在经过n小时以后,.logs终于滚动到了用户之前卡住的那一段,这时就强制执行flush任务,因此flushQueue队列就不为空了,死循环被打破。系统也就自愈了。
- HBase写被block的分析
- HBase的Block Cache实现机制分析
- HBase的Block Cache实现机制分析
- HBase的Block Cache实现机制分析
- [HBase] HBase Block Cache实现机制分析
- Hbase 的cache block
- HBase写请求分析
- HBase Block Cache实现机制分析
- HBase Block Cache实现机制分析
- 两年前写的:HBase性能深度分析
- Block的详细分析
- HBase-1.2.4 Allow block cache to be external分析
- HBase-put写操作源码分析
- HBase Coprocessor的分析
- hbase coprocessor的分析
- HBASE coprocessor 的分析
- HBase的compact分析
- HBase的split分析
- HBase多次加载-ROOT-和META的bug
- stardict for ubuntu
- What is move semantics?
- <MySQL Performance: over 1M QPS with InnoDB Memcached Plugin in MySQL 5.7>MySQL的高性能:MySQL 5.7
- 记录本-暂存一些东西
- HBase写被block的分析
- HEVC函数分析之TComPattern::fillReferenceSamples()
- 从PC中向Android模拟器中复制文件
- Effective Java笔记(第二章)
- 操作系统实验资料搜集:信号量,生产者消费者,读者写者等
- hdu 1598 列举+最小生成树★★
- windows环境中mysql忘记root密码的解决办法
- fragstats不能加载grid数据的问题
- Android4.3手机系统安装