Phoenix 索引生命週期

本文主要介紹phoenix索引狀態的生命週期，幫助大家解惑「為什麼我的phoenix索引不能正常使用了？」

索引總共有以下幾個狀態，其狀態資訊儲存在system.catalog表中。可以通過以下sql來檢視所有索引表資訊：

sql中欄位：

local(2)

usable("e")

unusable("d")

active("a")

inactive("i")

disable("x"))

rebuild("r")

disable表示索引將處於不可用的維護狀態，同時將不能用於查詢中。

rebuild表示索引將完成重建，同時一旦重建完成此索引將能被在此用於查詢中。

building表示將從索引不可用的時間戳處重建索引直到重建完成。

inactive/unusable表示索引將不能用於查詢中，但索引仍然在不可用的維護狀態。

active/usable表示索引錶能被正常用於查詢中。

注：disable狀態的索引必須重建，不能設定為usable狀態。

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不重啟，主表和索引表會保持長時間的不一致。