Phoenix索引生命周期

作者: ad4d39659223 | 来源:发表于2018-07-22 18:39 被阅读69次

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

    索引状态
    索引总共有以下几个状态,其状态信息存储在SYSTEM.CATALOG表中。可以通过以下SQL来查看所有索引表信息:
    select TABLE_NAME,DATA_TABLE_NAME,INDEX_TYPE,INDEX_STATE,INDEX_DISABLE_TIMESTAMPfrom system.catalog where INDEX_TYPE is not null;

    image
    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 表示索引表能被正常用于查询中。

    image

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

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

    自动重建索引过程

    1. MetaDataRegionObserver类负责运行重建索引线程,SYSTEM.CATALOG表是disable索引表更新的关键,因为它记录着索引表的所有状态。
    2. INACTIVE和DISABLE索引将会被选择重建(所有Online索引表region)。
    3. 所有表的所有索引表重建过程将串行执行(运行在cp上)。
    4. 索引表的建立是从disabled timestamp开始的。(此处会生成disable 时间到现在时间, 并带有需要更新索引信息的scan, RS在执行scan时触发cp重建索引)
    5. 对应的执行sql "UPSERT /+ NO_INDEX / INTO index_table_name(indexedCols) select dataCols from data_table” 完成索引同步。

    索引重建生命周期

    image
    控制自动重建索引的属性
    "phoenix.index.failure.handling.rebuild"(default true)
    
    "phoenix.index.failure.handling.rebuild.interval" (default 10 seconds)
    

    更新索引表失败处理实践

    1. 写索引表失败会试图禁用索引,向SYSTEM.CATALOG表写入索引状态。
    2. 在集群状态异常情况下,比如存在rit。此时CATALOG表的写操作可能失败,也就是状态不能得到更新,索引数据也同步失败,导致不断的执行起重建索引任务。
    3. 为了确保索引已经能得到更新,杀死RS,来触发WAL的replay,这样就能使得索引表的更新在WAL replay过程中得到重试。 同时需要手工介入,通过alter命令设置索引状态使之可用。

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

    1. 雪崩效应,整个集群的RS全部自杀:因为自杀的RS上也host了很多region,这些region可能是其他RS的索引表。某一RS自杀后,会导致其他RS的索引表更新失败,从而触发其他RS自杀,而其他RS自杀又会因为同样的原因导致更多的RS自杀,恶性循环。在很短的时间内,集群中所有RS都自杀了。
    2. 禁用的index表需要人工介入才能启用,在集群多了以后,会成为管理负担
    3. 禁用index表之后,本来通过命中索引表来完成的查询,就需要对主表做全表扫描来完成了。小scan会立即变成大scan,这可能会快速耗尽RS的资源,并导致client端大量超时。

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

    1. 在sync WAL之前出现的问题,由client负责重试: 因为没有WAL没有写下去,就不会导致主表和索引表的数据不一致。
    2. 在sync WAL之后出现的问题,由RS负责重试:因为WAL已经写下去了,此时,部分索引表的更新也可能已经完成,客户端如果不重试且RS不重启,主表和索引表会保持长时间的不一致。

    参考

    1. https://community.hortonworks.com/articles/58818/phoenix-index-lifecycle.html
    2. https://phoenix.apache.org/secondary_indexing.html



    更多技术交流,可关注微信交流群,微信公众号等:

    或参考文章: HBase中文社区官网、交流群
    1. 微信群

    扫描添加小编微信好友(或搜索微信号: Mr_wanyue 添加),回复: HBase 加群

    2. 钉钉群:

    扫一扫添加
    3. 微信公众号:
    扫描关注

    相关文章

      网友评论

        本文标题:Phoenix索引生命周期

        本文链接:https://www.haomeiwen.com/subject/wdhrmftx.html