meta表修复一
Java代码
查看hbasemeta情况
hbase hbck
1.重新修复hbase meta表（根据hdfs上的regioninfo文件，生成meta表）
hbase hbck -fixmeta
2.重新将hbase meta表分给regionserver（根据meta表，将meta表上的region分给regionservere）
hbase hbck -fixAssignments
转meta，表手动删除表
Java代码
因为集群硬盘紧俏，绝对对原来的表加上COMPRESSION=>LZO属性。但是创建表，长时间没有反馈。决定drop掉这张表，但是始终drop失败。重启集群，hbase 60010界面显示有region transaction。为创建失败的表region，在PENDING_OPEN和CLOSED之间跳。describe 表失败， enable表失败，disable表失败，从60010界面查看表失败。很蛋疼。
后决定强制删除当前表。google了一下，找到这篇文章，文章大部分都是对的，但是最后一步存在问题.原文中命令为：
delete 'TrojanInfo','TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.','info:server'
当时就觉得有有问题，没有涉及.meta.表，如何更新meta信息？
尝试两次删除后是始终报错，确定应该是有问题，为了以防万一，google一下更新meta信息的操作，将命令改为
delete '.meta.','TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.','info:server'
命令成功执行。
重启集群后，transction仍然存在，分析应该是meta表没有更新的问题，对meta表做一次major_compact，重启集群，成功。不再有报错。
下面是对原文的拷贝：
强制删除表：
1、强制删除该表在hdfs上的所有文件(路径根据实际情况而定）：
[sql] view plaincopy
./hadoop fs -rmr /hbase/TrojanInfo
2、删除该表在Hbase系统表.meta.中的记录：
A、首先从.meta.中查询出表 TrojanInfo在.meta.中的rowkey，这可以通过scan '.meta.'，然后手动筛选；
B、然后删除该rowkey下的3个字段（假设查询出的rowkey为TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.）
[plain] view plaincopy
delete 'TrojanInfo','TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.','info:server'
delete 'TrojanInfo','TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.','info:serverstartcode'
delete 'TrojanInfo','TrojanInfo,,1361433390076.2636b5a2b3d3d08f23d2af9582f29bd8.','info:reg
转meta表修复三
Java代码
一、故障原因
IP为10.191.135.3的服务器在2013年8月1日出现服务器重新启动的情况，导致此台服务器上的所有服务均停止。从而造成NTP服务停止。当NTP服务停止后，导致Hbase集群中大部分机器时钟和主机时间不一致，造成regionserver服务中止。并在重新启动后，出现region的hole。需要对数据进行重新修复，以正常提供插入数据的服务。
二、恢复方式
1、集群50个regionserver，宕掉服务41个，namenode所在机器10.191.135.3不明重启（原因查找中）导致本机上的namenode、zookeeper、时间同步服务器服务挂掉。
2、重启hbase服务时，没能成功stop剩余的9个regionserver服务，进行了人为kill进程，
3、在hdfs上移走了hlog（避免启动时split log花费过多时间影响服务），然后重启hbase。发现10.191.135.30机器上的时间与时间同步服务器10.191.135.3不同步。手工同步后重启成功。hbase可以正常提供查询服务。
4、运行mapreduce put数据。抛出异常，数据无法正常插入；
5、执行/opt/hbase/bin/hbase hbck -fixAssignments，尝试重新分配region。结果显示hbase有空洞，即region之间数据不连续了；
6、通过上述操作可以定位是在regionserver服务宕掉的后重启的过程中丢了数据。需要进行空洞修复。然而hbase hbck命令总是只显示三条空洞。
7、通过编写的regionTest.jar工具进行进一步检测出空洞所在的regionname然后停掉hbase，进而进行region合并修复空洞;
8、合并的merge 操作需要先去.meta.表里读取该region的信息，由于.meta.表也在regionserver宕机过程中受到损坏，所以部分region的.meta.信息没有，merge操作时就抛出空指针异常。因此只能将hdfs这些region进行移除，然后通过regionTest.jar 检测新的空洞所在的regionname，进行合并操作修复空洞；
9、关于region重叠，即regionname存在.meta.表内，但是在hdfs上被错误的移出，并进行了region合并。这种情况下需要通过regionTest.jar检测重叠的regionname然后手动去.meta.表删除，.meta.表修改之后需要flush；
10、最后再次执行 hbase hbck 命令，hbase 所有表status ok。
