Mean time to recovery／HBase

MTTR是指因为某个节点宕机或服务不可用导致HBase不可用／或部分不可用，直到HBase服务恢复所用的时间。

该过程主要分为三步：

1.识别出节点宕机或者节点上的服务不可用

2.恢复正在写的数据：其他节点通过获取WAL日志，恢复尚未flush持久化到hdfs的数据

3.重新分配故障节点上的regions到其他regionservers

在以上过程中，相关的region对于客户端来说是不可用的。

节点／服务，故障或者不可用分为两种情况：

1.管理员提交命令关闭regionserver，这种情况下regionserver会以正确的方式关闭并即时给hmaster同步关闭状态，（wal日志会被持久化到磁盘，待验证），然后hmaster就会立刻开始做region迁移

2.对于另外一种暴力故障，比如网线松了、网卡坏掉、断电等。依赖于zk发现节点故障，zk与每一个regionserver建立连接，zk长时间收不到不到regionserver的心跳，hbase会宣布该regionserver死亡。

恢复正在写的数据

对于相关服务进程不可用的情况，wal会被并行地随机发送到健康的regionservers上，日志文件会根据edits-per-region在hdfs上被分裂成不同的文件，然后相关的regions被迁移到对应的regionserver上，每个regionserver各自读取相关的wal文件，恢复region。

对于节点故障或者hdfs问题，处理起来就比较复杂了，这种情况不仅仅是regionserver服务不可用，该节点上的hdfs block文件也不可用了，而split（待确认是split，还是reallocate）需要读取hdfs block文件，如果有三副本，则有33%的几率读取失败，而且split作业还要向datanode写文件，且所有文件会被写为三副本（默认），如果其中任何文件被assign到故障的datanode，这次写会超时，转而写到别的datanode上。这会大大减缓故障恢复速度。

region的reassignment

越快越好，依赖于zk，通过zk同步hmaster和regionserver的状态。

对mttr的优化措施

1.监听node故障方面

调低zk超时时间，默认配置值是3分钟，这是为了给GC停止留下足够的时间窗。但对于特别关注mttr的生产环境来说，可把这个值调到30秒-1分钟，理论上最小可以调到20秒左右。同时，需要调整GC参数，比如新生代、老年带的配置等（这里不做过多赘述），以保证zk时间不超过zk超时时间。

2.优化in-progress writes恢复

通常hbase有足够多健康的regionserver来并行接收日志，因此恢复数据的关键在于迅速定位故障的hdfs节点和副本数据块所在datanode，因此需要把hdfs数据节点的心跳汇报周期调短于hbase，比如hbase的失败检测周期（感知心跳超时时间）是60秒，hdfs则可配置为20秒。hdfs是通过namenode来监听数据节点心跳的，但一个datanode故障后，该节点的数据block会被复制到其他健康的datanode上，这个进程开销很大。如果多个datanode同时故障，会引起数据集中迁移风暴，进而引起系统过载，这可能导致某些健康节点无法及时返回心跳，从而被认为节点故障，然后这个节点的数据也需要被迁移，如此恶性循环下去。。。出于这个原因，hdfs可能在启动相关恢复进程之前要经历超过10分钟的等待。这对于hbase数据恢复形成了障碍，因为hbase访问故障的datanode意味着会话超时，这降低了hbase数据恢复的速度。

针对以上问题，最新的hdfs版本1.04和1.2，分支2和3做了修复，对于没有及时返回心跳的datanode，可以标记其状态为stale，被标记stale状态的datanode上的数据最后才会被读取。对于1.2／2.0/3.0版本的hdfs，stale对读写都生效。

对assign region的优化

0.94版本之后的hbase对此做了优化，通过减少hbase内部同步，降低多个region assignment的耗时，尤其是对hmaster。

总结

默认情况下，hbase数据恢复时间为10分钟左右，这个时间主要花费在hdfs宣布一个节点故障、hdfs使用故障节点的数据。通过以上stale等配置，hbase数据恢复对hdfs依赖降低，从而将hbase不可用region恢复到健康regionserver的时间降低到2分钟左右。