hbase的稳定性是近期社区的重要关注点，毕竟稳定的系统才能被推广开来，这里有几次稳定性故障和大家分享。 
    第一次生产故障的现象及原因 
    现象：  

    1 hbase发现无法写入  

    2 通过hbck检测发现.META.表中出现空洞，具体log            是：;Chain of regions in table ...  is broken; edges does not contain ...  

    3 此时读写失败  

    修复方法：直接使用check_meta.rb重新生成.META.表并修补空洞，但是会引起数据丢失。因为引起该空洞的原因是某个region的parent和daughter都被删掉了 
    查找故障过程非常复杂，具体就不提了，都是内伤啊... 
    故障原因需要从split的原理说起： 
    split是一个分布式的事务过程，由于分布式的复杂性，在每一步都有可能发生异常中止，因此每进行一步就要记录一下当前的状态。如果出错了，就根据己经进行的状态来进行对应的回滚操作。这个记录状态的变量在代码里体现为JournalEntry 
    于是split的过程是这样的：(见图) 

• 1 创建splitDir(region目录下的splits目录)

• 2 状态机添加CREATE_SPLIT_DIR

• 3 执行internalFlushcache把内存刷到磁盘

• 4 close parent并且返回所有storefile

• 5 状态机添加CLOSED_PARENT_REGION

• 6 把region从rs的online列表中删除

• 7 状态机添加OFFLINED_PARENT

• 8 多线程进行split storefiles，创建子目录并把文件写进去，(原文件不删除，该过程默认超过30s会强行中止并抛出IOE)

• 9 状态机添加STARTED_REGION_A_CREATION

• 10 创建第一个daughter region

• 11 状态机添加STARTED_REGION_B_CREATION

• 12 创建第二个daughter region

• 13 在meta表中下线parent

• 14 原子性往meta表中写以下信息：parent置为offline以及split状态，parent添加两列：splitA和splitB

• 15 并发open DaughterA和DaughterB(如果线程中断，则通知rs退出进程)

• 16 在open期间，如果server中止，则先把A和B的信息写入到meta表中再跳过以下过程

• 17 创建两个新的HRegion，通知rs把子region添加到online列表中

• 18 把Daughter信息写入meta表

    当以上过程中任何一步抛出异常时，regionserver会进入回滚逻辑(rollback)： 
    对状态机中存储己经进行的状态进行检查，并从后往前开始遍历己进行的状态： 

• CREATE_SPLIT_DIR:删除子目录

• CLOSED_PARENT_REGION:重新初始化parent

• STARTED_REGION_A_CREATION:删除A对应的目录

• STARTED_REGION_B_CREATION:删除B对应的目录

• OFFLINED_PARENT:把parent添加到online队列中

    了解了以上过程，我们来假设以下两种场景： 
    场景1 如果split期间如果在第4步(close parent并且返回所有storefile)结束后，或者执行过程中发生异常，那么此时会发生什么呢？ 
    状态机里的值是CREATE_SPLIT_DIR，因此会删除子目录，但由于parent己经被close或者处于closing状态了，那么就是父子region都没有在线，此时无法读写该region对应的数据 
    场景1还比较好解决，比如直接下线该台rs再重启就能解决了。当然对于在线业务来讲，这个还是不能接受的，因为系统不可用时间太长了。于是需要用到HBASE-4563这个patch来解决它 
    它的原理很简单：把CLOSED_PARENT_REGION状态放到close parent前面即可 

    场景2 如果split期间在第14步期间或以后发生异常。那此时meta表己经将parent下线了，回滚时却没有将parent在meta中的状态改回来，而是删除了子region的目录以及open parent 
(注意在open parent的时候并不会修改meta中的offline及split值)。于是该region就不再上线了，形成了空洞。不过这个时候客户端如果cache了该region的地址，那暂时还不会报错， 
因为regionserver己经把它重新上线了，数据暂时还能读到。 
    但是严重的问题是：master有个垃圾清理线程(CatalogJanitor)会定期对meta表做扫描，默认5min一次。它会扫描meta表中split和offline状态为true的那些region，检查是否有子region指向它，如果没有的话，它会认为这个region是己经split成功的，于是会将它从meta表以及hdfs上删掉。检查子region是否指向它是检查是否有子目录存在并且不为空。在场景2中显然子目录己经不再存在了，因此被认为是split成功的region，于是数据被master删掉... 
    这里的根本原因是没有对写meta这个状态进行记录以及回滚，并且master检查子region是否存在的条件太过简单，需要做调整。具体可参见HBASE-3872以及HBASE-4562(3872试图解决这个问题，但是没有解决掉。4562进行了进一步的处理) 
    修复的原理就是增加一个状态来记录，而当回滚发现这个问题时，让这台regionserver自己挂掉。这样在master恢复它的时候，会执行fixDaughter的逻辑，这个逻辑会完整地恢复这个region，让split成功，子region上线。而CatalogJanitor的逻辑也进行了调整，对数据进行更加严格的检查和保护，避免随意删除数据。 
    场景2是个非常严重的bug，推荐大家都升级一下。因为在复杂的网络环境中这个异常还是比较容易出现的。 

    第二次生产故障的现象及原因 
    现象： 

    1 用户发现tps有下降，且部分写入不正常。  

    2 通过hbck检查到集群有"Chain of regions in table …contains less elements than are listed in META; visited=”问题存在，意即META表中某些region出错，此时若用户有新的写入，则新的写入有可能会数据丢失。  

    3 通过1个多小时的修复，仍然没有将该集群状态无损还原。原因是出现了两个region服务同一段数据  

    修复方法：找到start_key和end_key相同的几个region，把它们的从hdfs上删除掉。然后用add_table重建meta表（会导致丢失数据） 
    这个过程也是一个hbase的bug产生的，这个bug来自于重启过程。复现问题也很容易，进行以下几步即可复现： 
    1 找到一台正在split的region所在的rs 
    2 kill掉该台rs 
    3 重启整个集群或master进行切换 
    原因分析： 
    当hbase的master在主从切换或者重启的时候，有一个步骤是切换之后的master需要对原来所有的挂掉的regionserver上的region进行processDeadRegion，即重新上线。 
    该过程在0.90.4之前存在一个bug，即会把meta表中所有处在split期间的region也进行处理，虽然region在meta表中处于split状态并不能证明它己经split结束还是正在split（要对split状态进行标记还是很复杂的，因此目前的代码还没有对split状态进行记录，只能通过一些辅助手段，比如检查子region的状态来说明region是否处于split状态），但是万一它己经split结束的话是绝对不应该上线的。因此有可能一个region己经split结束，但它在这个处理过程中又被新起的master上线了，这就导致父子region同时服务了。而父region上线后又有可能继续split，导致状况更加糟糕，同一段数据被两个region服务，等等。 
    正确的处理办法是在重启时检查这些region的子region状态，具体检查方案在hbase-0.90.4中己经给出，可参见HBASE-3946。注意：打上3946的patch以后，还必须要打上3995的patch，否则单元测试无法通过。