Phoenix索引生命周期

本文主要介绍Phoenix索引状态的生命周期，帮助大家解惑“为什么我的phoenix索引不能正常使用了？”

索引状态

索引总共有以下几个状态，其状态信息存储在SYSTEM.CATALOG表中。可以通过以下SQL来查看所有索引表信息：

SQL中字段：

TABLE_NAME表示索引表名

DATA_TABLE_NAME表示原数据表名

INDEX_TYPE表示索引类型

GLOBAL(1)

LOCAL(2)

INDEX_STATE表示索引状态

BUILDING("b")

USABLE("e")

UNUSABLE("d")

ACTIVE("a")

INACTIVE("i")

DISABLE("x"))

REBUILD("r")

DISABLE表示索引将处于不可用的维护状态，同时将不能用于查询中。

REBUILD表示索引将完成重建，同时一旦重建完成此索引将能被在此用于查询中。

BUILDING表示将从索引不可用的时间戳处重建索引直到重建完成。

INACTIVE/UNUSABLE表示索引将不能用于查询中，但索引仍然在不可用的维护状态。

ACTIVE/USABLE表示索引表能被正常用于查询中。

注：disable状态的索引必须重建，不能设置为USABLE状态。

INDEX_DISABLE_TIMESTAMP

表示索引disable时的时间戳。当索引是active或者手动置为disable时值为0，当索引写失败引起disable时值为非0。

自动重建索引过程

MetaDataRegionObserver类负责运行重建索引线程，SYSTEM.CATALOG表是disable索引表更新的关键，因为它记录着索引表的所有状态。

INACTIVE和DISABLE索引将会被选择重建（所有Online索引表region）。

所有表的所有索引表重建过程将串行执行（运行在cp上）。

索引表的建立是从disabled timestamp开始的。（此处会生成disable 时间到现在时间， 并带有需要更新索引信息的scan, RS在执行scan时触发cp重建索引）

对应的执行sql "UPSERT /+ NO_INDEX/ INTO index_table_name(indexedCols) select dataCols from data_table” 完成索引同步。

索引重建生命周期

控制自动重建索引的属性

更新索引表失败处理实践

写索引表失败会试图禁用索引，向SYSTEM.CATALOG表写入索引状态。

在集群状态异常情况下，比如存在rit。此时CATALOG表的写操作可能失败，也就是状态不能得到更新，索引数据也同步失败，导致不断的执行起重建索引任务。

为了确保索引已经能得到更新，杀死RS，来触发WAL的replay，这样就能使得索引表的更新在WAL replay过程中得到重试。 同时需要手工介入，通过alter命令设置索引状态使之可用。

以上是社区版本通过RS failover来解决问题，但这种方法也存在一些问题：

雪崩效应，整个集群的RS全部自杀：因为自杀的RS上也host了很多region，这些region可能是其他RS的索引表。某一RS自杀后，会导致其他RS的索引表更新失败，从而触发其他RS自杀，而其他RS自杀又会因为同样的原因导致更多的RS自杀，恶性循环。在很短的时间内，集群中所有RS都自杀了。

禁用的index表需要人工介入才能启用，在集群多了以后，会成为管理负担

禁用index表之后，本来通过命中索引表来完成的查询，就需要对主表做全表扫描来完成了。小scan会立即变成大scan，这可能会快速耗尽RS的资源，并导致client端大量超时。

云HBASE针对以上问题，提出了以下解决方法，并已经实现。

在sync WAL之前出现的问题，由client负责重试： 因为没有WAL没有写下去，就不会导致主表和索引表的数据不一致。

在sync WAL之后出现的问题，由RS负责重试：因为WAL已经写下去了，此时，部分索引表的更新也可能已经完成，客户端如果不重试且RS不重启，主表和索引表会保持长时间的不一致。

参考

https://community.hortonworks.com/articles/58818/phoenix-index-lifecycle.html

https://phoenix.apache.org/secondary_indexing.html

大家工作学习遇到HBase技术问题，把问题发布到HBase技术社区论坛http://hbase.group，欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup)，非常欢迎大家积极投稿。