Phoenix -修復表索引

• 索引的修復可以通過2種方式，（關於pehoenix的索引的生命周期可以參考  https://community.hortonworks.com/articles/58818/phoenix-index-lifecycle.html
  • 一 手工執行修復命令 
  • 依賴phoenix的自動修復命令
• 自動修復
  • Phoenix 對於索引狀態異常的情況，按照設計會自動進行修復的，也就是autorebuild，不過發現在HDP2.2 下，不能正常修復，后台（regionserver）提示找不到schema
    
    針對這個bug，社區已經反饋為HDP2.2的bug，在2.3版本已經修復.可以參考 https://community.hortonworks.com/questions/66446/phoenix-index-becom-unavaiable.html#comment-67349
• 手工修復
  • 當數據量比較小的時候，正常的修復命令可以正常執行，但是由於數據量較大，出現了修復超時、修復錯誤等問題
  • 當數據量較大的時候，采用修復命令的時候，比較曲折，由於各方面原因最終沒有修復成功，
• 下面的一個場景為修復我們的一個數據庫表原始數據800G,索引數據70個G左右，regionserver 是3台，8core 14g
• 修復流程如下
• 查看當前索引的狀態
  
                                select TABLE_NAME,DATA_TABLE_NAME,INDEX_TYPE,INDEX_STATE,INDEX_DISABLE_TIMESTAMP from system.catalog where INDEX_TYPE is not null

;

　　　　　　驗證sql 是否走索引 發現沒有走

　　　　　　
　　                          .修復索引

• • • • ALTER INDEX IF EXISTS SysActionLog_idx ON "SysActionLog" REBUIL3
  • 執行出現超時
    　　    Error: org.apache.phoenix.exception.PhoenixIOException: Failed after attempts=36, exceptions:
    
  • • Wed Nov 16 11:06:26 GMT 2016, null, java.net.SocketTimeoutException: callTimeout=60000, callDuration=73626: row '' on table 'SYSACTIONLOG_IDX' at region=SYSACTIONLOG_IDX,,1463835204579.ce4eb5993504052a305c8807d6234d93., hostname=workernode2.reddog.microsoft.com,16020,1479228656092, seqNum=1438608 (state=08000,code=101)
  • 再次查詢。
  • 
    此時索引的狀態已經 變為正在進行修復

•                    修改phoenix 的執行超時（index.phoenix.querytimeout） ，后執行 再次 仍然出現錯誤

  • • • •  

      6/11/16 11:40:40 WARN client.ScannerCallable: Ignore, probably already closed（region server 的日志對應的為超時）
      
      org.apache.hadoop.hbase.UnknownScannerException: org.apache.hadoop.hbase.UnknownScannerException: Name: 5, already closed?
      •   at org.apache.hadoop.hbase.regionserver.HRegionServer.scan(HRegionServer.java:3186)
         at org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:29994)
         at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2080)
         at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:108)
        at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:114
      at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:94)
       at java.lang.Thread.run(Thread.java:74
    
    5修改超時時間
                      針對上面的錯誤，分析regionserve的日志，發現是由於一些超時時間導致，在每個regionserver 的節點上增加如下參數

• • • • <property>
        <name>hbase.client.scanner.timeout.period</name>
        <value>9200000</value>
        </property>
        <property>
        <name>hbase.rpc.timeout</name>
        <value>9200000</value>
        </property>
        <property>
        <name>hbase.regionserver.lease.period</name>
        <value>9200000</value>
        </property>
        <property>
        <name>phoenix.query.timeoutMs</name>
        <value>9200000</value>
        </property>

• 

  • 目前 懷疑 應該在HDInsight 節點下的phoenix 目錄下的hbase-site.xml 增加上面的幾個參數，但是原生的HDP下phoenix的目錄下沒有這個hbase-site.xml。 有時間進一步驗證....  

  • 在Hdp 原生的集群執行時，也出現了超時，由於時微軟的azure windows 平台上 不知HDP在window上是否有問題，同樣的操作和參數配置 在測試的HDP liux集群出現了如下錯誤，需要進一步解決,(調整zk的時間)
• 
• 未完 待續