引用《https://blog.csdn.net/nigeaoaojiao/article/details/54909921》
hlog介绍:
hlog构建:
从图中可以看出,对于一个hlog日志,整一个region server中的region数据都写入到同一个日志中,日志中最小单元的格式为<HLogKey,WALEdit>
hlogKey格式:
- sequenceid,自增id
- write time,写入时间,修改操作何时写入日志的时间戳
- cluster ids,集群id,满足用户多集群之间复制的需求
- region 信息
- table name,表名
hlog滚动:
region server每个一段时间就会生成一个log文件(默认1小时,可以设置),设置日志滚动机制,类似于binlog的处理机制。虽然会产生会多文件,但是考虑到删除文件时,直接将文件删除是最方便的方式。
hlog失效:
当一个日志文件的数据全部从MemStore中flush到了HFile中,该日志文件即可以被删除掉了。可以通过自增id——sequenceid判断,当一个文件中的sequenceid小于Memstore中flush记录的最大的sequenceid即可判断。当一个log被判定为失效后,会被移到oldWALs目录下
hlog删除:
hmaster后台启动一个线程每个一段时间(默认一分钟)检查文件夹OldWALs,判断下面的log是否真正的失效,确认失效即删除。
hbase日志恢复流程:
regionServer是否存活:
hbase中,master检查regionServer是否存活是通过zookeeper实现的,regionServer通过向zookeeper注册节点(/hbase/rs目录下),并且定时向zookeeper上报心跳来证明自己处于存活状态。master通过查看该目录的节点查看regionServer是否存活。
region server出问题的情况:
- regionServer出现长时间的full gc
- regionServer宕机
- zookeeper出问题
- 网络问题
- 等等
在master看来,就是在zookeeper中查看不到具体的region Server注册的节点,这时候就会进行数据恢复。
hbase的日志恢复有三种方式:
- logSplitting
- Distributed log splitting
- Distributed log replay
logSplitting:
hbase的日志分割方式,整个过程都由HMaster执行。
- 首先将日志复制一份,重命名后缀加-splitting。
- 启动一个线程依次读取log,根据hlogkey中不同的region,写入到不同的buffer中。知道全部的log读完
- 对应每个buffer启动一个线程,将每个buffer的数据写入到hdfs中
- 之后,等hmaster分配完region后,将hdfs中数据写入到对应的region中
因为是单线程恢复,在出现大量的机器宕机后,需要恢复的数据过大,耗时会变得非常长。
Distributed log splitting:
DLS是LS的分布式实现,借助了master和多个regionserver的计算能力,将hlog的splitting任务分散到不同的regionserver上。
- hmaster分别将每个log(该日志在hdfs上的路径)作为一个任务发布到zookeeper上(/hbase/splitWAL节点下),设置起始状态为TASK_UNASSIGNED。
- 所有存活的regionserver都注册这个节点上等待任务,一旦hmaster发布任务,全部regionserver开始竞争任务,即全部regionserver尝试修改任务状态为TASK_OWNED,修改成功即竞争成功。
- regionserver抢占任务成功后,分配任务给相应的线程处理。处理成功修改状态为TASK_DONE,失败修改状态为TASK_ERR。
- hmaster一直监听者该节点,一旦有状态修改就会收到通知,如果任务成功,则删除对应任务节点,如果任务失败,则从新发布任务。
- 具体regionserver处理一个任务的流程和LS处理流程一样
DLS有一个问题,生成的小文件过多,对于M个region,N个hlog日志最终会生成M*N个文件。
Distributed log replay:
DLR方式相对于DLS方式来说,流程上做了一些改动:
- DLR先分配region,在切分回放HLog,region重新分配后状态被设置为recovering,该状态只能写不能读取。而在HLog splitting分配到buffer后,不写文件,而是直接执行回放操作。