标签：exception procedure 异常 请求 分享 roo asc 方案 删除
Procedure V2, 是hbase1.1版本引入的一套fault-tolerant的执行multi-steps-job的框架, 目前主要用在Master中, 比如创建表,删除表等操作
新旧比较
下面比较0.94版本和1.25版本下的建表流程
0.94
0.94版本中,创建表是通过HBaseAdmin类,向Master发起一个异步的建表请求,然后不断的扫描meta表,直到从meta表中扫描到的表的region数目和预期的数据相同,即认为建表成功, 时序图如下:
流程:
1. 从HBaseAdmin发起 createTable请求到master[异步请求]
2. Master做完基本检查后,如果有MasterCoprocessor,就调用coprocessor的preCreateTable做前置检查
3. 检查通过后,Master生成CreateTableHandler, 提交给ExecuterService服务去执行
3.1. hdfs的 hbaseroot/.tmp目录上创建TableDescriptor
3.2. hdfs的hbaseroot/.tmp目录上创建region及相关文件
3.3. 把tmp目录中创建好的表文件拷贝到hbaseroot目录下
3.4. 新增region信息到META表
3.5. 触发所有region的assignment,随机分配到集群alive的regionserver上
3. 6. zk上修改表的状态为TableState.ENABLED
4. HBaseAdmin在第1步完成后, 会通过MetaScan不断的去meta表查看所创建表的region数目是不是和预期的相等,如果是,建表成功,如果经过了一定的重试次数后(默认10*10=100次),依然失败,则抛出TableNotEnabledException异常
存在的问题:
1. 如果一切顺利还好,但是如果任意一步出现问题,则很难定位和修复,比如:
1. 3.3成功后,master宕机, 3.4还没有执行, 那么定位后,可以通过hbase hbck -fixMeta 工具做修复
2. 如果3.4部分成功, 就没有很好的工具做修复, 这时候就需要人工介入,去做回滚操作,然后再重新建表
1.2.5
procedure v2是在hbase1.1版本引入的特性,主要是为了解决之前的方案中存在的问题, 比如,任务意外中断后,中间状态需要人工接入, 难以追溯任务状态等问题:
...未完待续
标签：exception procedure 异常 请求 分享 roo asc 方案 删除
原文地址：http://www.cnblogs.com/igloo1986/p/6977858.html
