Phoenix 索引失效及重建

Phoenix 索引失效及重建

失效原因

phoenix端数据写入时，hbase宕机或重启，导致写入中断，写入更新索引表失败，导致索引失效，很多情况下是重启hbase没有停phoenix服务导致索引数据不一致

现象

如下所示，可以看到有两个索引的状态为 PENDING_DISABLE ,其余是__active__的

 !tables 

TABLE_CAT	TABLE_SCHEM	TABLE_NAME	TABLE_TYPE	REMARKS	TYPE_NAME	SELF_REFERENCING_COL_NAME	REF_GENERATION	INDEX_STATE	IMMUTABLE_R
	DZ	ODS_DB-A_TB-A_INDEX_1	INDEX					PENDING_DISABLE	false
	DZ	ODS_DB-A_TB-A_INDEX_1_2	INDEX					ACTIVE	false
	DZ	ODS_DB-B_TB-B_INDEX_1	INDEX					ACTIVE	false
	DZ	ODS_DB-B_TB-B_INDEX_2	INDEX					ACTIVE	false
	DZ	ODS_DB-B_TB-B_INDEX_3	INDEX					ACTIVE	false
	DZ	ODB_DB-X_TB-X_INDEX_5	INDEX					ACTIVE	false
	DZ	ODB_DB-X_TB-X_INDEX_6	INDEX					PENDING_DISABLE	false
	DZ	ODB_DB-X_TB-X_INDEX_6_2	INDEX					ACTIVE	false
	DZ	ODB_DB-X_TB-X_INDEX_7	INDEX					ACTIVE	false

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kyIsqAfF-1640838170623)(C:/Users/ship1/AppData/Roaming/Typora/typora-user-images/image-20211230110212614.png)]

其中INDEX_STATE为pending_disable的为不可用索引，需要修复

也可在catlog表中查看索引状态，如下：

select 
TABLE_NAME -- 表名（索引表也是个表） 
,DATA_TABLE_NAME -- 数据表（我们保存数据的表，不包括索引表，虽然他也存数据）
,INDEX_TYPE -- 索引类型
,INDEX_STATE -- 索引状态
,INDEX_DISABLE_TIMESTAMP -- disable的时间 
from system.catalog 
where INDEX_TYPE is not null;

INDEX_STATE会有a,w,x,b等枚举

如果为a,e则为正常服务，x或d则为索引挂起，不可使用需要重建或者修复，i为不可用，但在自动修复，b为重建中

简写	类型	描述
a	ACTIVE	ACTIVE 表示索引表能被正常用于查询中。
b	BUILDING	BUILDING 表示将从索引不可用的时间戳处重建索引直到重建完成。
d	UNUSABLE	UNUSABLE 表示索引将不能用于查询中，但索引仍然在不可用的维护状态
e	USABLE	USABLE 表示索引表能被正常用于查询中。
i	INACTIVE	INACTIVE 表示索引将不能用于查询中，但索引仍然在不可用的维护状态
x	DISABLE	DISABLE 表示索引将处于不可用的维护状态，同时将不能用于查询中。
r	REBUILD	REBUILD 表示索引将完成重建，同时一旦重建完成此索引将能被在此用于查询中。

修复

1. 自动修复

   一般索引失效其会自动修复，但是基本上修复不好。

2. 新建一张和失效索引一样的索引表

   数据量比较小的可以新建一张和原来一样的索引表，已解燃眉之急。但是如果数据量比较大那就BBQ了，可能会建很久（大几个小时。。

3. 手动修复

   3.1 先找到失效的索引

   select TABLE_NAME,DATA_TABLE_NAME,INDEX_TYPE,INDEX_STATE,INDEX_DISABLE_TIMESTAMP from system.catalog where INDEX_TYPE is not null and INDEX_STATE in ('w', 'x', 'i', 'd');
   

   TABLE_NAME	DATA_TABLE_NAME	INDEX_TYPE	INDEX_STATE	INDEX_DISABLE_TIMESTAMP
   DZ_TR_NB_CMER_INDEX_2	DZ_TR_NB_CUOMER	1	x	1636963156228
   DZ_TR_NB_HEOTIFY_INDEX_1	DZ_TR_NB_HENOTIFY	1	w	1632738818454
   DZ_TR_NB_POLY_INDEX_6	DZ_TR_NB_POY	1	w	1634723285293

   3.2 设置索引为disable

   alter index DZ_TR_NB_HEFY_INDEX_1  on DZ.DZ_TR_NB_HEFY DISABLE;
   

   TABLE_NAME	DATA_TABLE_NAME	INDEX_TYPE	INDEX_STATE	INDEX_DISABLE_TIMESTAMP
   DZ_TR_NB_CMER_INDEX_2	DZ_TR_NB_CUOMER	1	x	1636963156228
   DZ_TR_NB_HEFY_INDEX_1	DZ_TR_NB_HEFY	1	x	1632738818454
   DZ_TR_NB_POLY_INDEX_6	DZ_TR_NB_POY	1	w	1634723285293

   3.3 重建

   alter index DZ_TR_NB_HEALTHNOTIFY_INDEX_1  on DZ.DZ_TR_NB_HEALTHNOTIFY REBUILD;
   

   TABLE_NAME	DATA_TABLE_NAME	INDEX_TYPE	INDEX_STATE	INDEX_DISABLE_TIMESTAMP
   DZ_TR_NB_HEOTIFY_INDEX_1	DZ_TR_NB_HENOTIFY	1	b	1632738818454
   DZ_TR_NB_POLY_INDEX_6	DZ_TR_NB_POY	1	w	1634723285293

3.4

!tables
INDEX_STATE刚开始为BUILDING，建好就ACTIVE了

比较

数据量小推荐方法2，生产推荐2和3其中3需要看运气我试过几次有可能会重建失败。