如何修复hbase phoenix表

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,,13614333900762636b5a2b3d3d08f23d2af9582f29bd8','info:server'
当时就觉得有有问题，没有涉及META表，如何更新META信息？
尝试两次删除后是始终报错，确定应该是有问题，为了以防万一，google一下更新META信息的 *** 作，将命令改为
delete 'META','TrojanInfo,,13614333900762636b5a2b3d3d08f23d2af9582f29bd8','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,,13614333900762636b5a2b3d3d08f23d2af9582f29bd8）
[plain] view plaincopy

delete 'TrojanInfo','TrojanInfo,,13614333900762636b5a2b3d3d08f23d2af9582f29bd8','info:server'
delete 'TrojanInfo','TrojanInfo,,13614333900762636b5a2b3d3d08f23d2af9582f29bd8','info:serverstartcode'
delete 'TrojanInfo','TrojanInfo,,13614333900762636b5a2b3d3d08f23d2af9582f29bd8','info:reg
转meta表修复三
Java代码
一、故障原因
IP为101911353的服务器在2013年8月1日出现服务器重新启动的情况，导致此台服务器上的所有服务均停止。从而造成NTP服务停止。当NTP服务停止后，导致HBase集群中大部分机器时钟和主机时间不一致，造成regionserver服务中止。并在重新启动后，出现region的hole。需要对数据进行重新修复，以正常提供插入数据的服务。

二、恢复方式
1、集群50个regionserver，宕掉服务41个，namenode所在机器101911353不明重启（原因查找中）导致本机上的namenode、zookeeper、时间同步服务器服务挂掉。
2、重启hbase服务时，没能成功stop剩余的9个regionserver服务，进行了人为kill进程，
3、在hdfs上移走了hlog（避免启动时split log花费过多时间影响服务），然后重启hbase。发现1019113530机器上的时间与时间同步服务器101911353不同步。手工同步后重启成功。hbase可以正常提供查询服务。
4、运行mapreduce put数据。抛出异常，数据无法正常插入；
5、执行/opt/hbase/bin/hbase hbck -fixAssignments，尝试重新分配region。结果显示hbase有空洞，即region之间数据不连续了；
6、通过上述 *** 作可以定位是在regionserver服务宕掉的后重启的过程中丢了数据。需要进行空洞修复。然而hbase hbck命令总是只显示三条空洞。
7、通过编写的regionTestjar工具进行进一步检测出空洞所在的regionname然后停掉hbase，进而进行region合并修复空洞;
8、合并的merge *** 作需要先去META表里读取该region的信息，由于META表也在regionserver宕机过程中受到损坏，所以部分region的META信息没有，merge *** 作时就抛出空指针异常。因此只能将hdfs这些region进行移除，然后通过regionTestjar 检测新的空洞所在的regionname，进行合并 *** 作修复空洞；
9、关于region重叠，即regionname存在META表内，但是在hdfs上被错误的移出，并进行了region合并。这种情况下需要通过regionTestjar检测重叠的regionname然后手动去META表删除，META表修改之后需要flush；
10、最后再次执行 hbase hbck 命令，hbase 所有表status ok。

---