[
https://issues.apache.org/jira/browse/PHOENIX-950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey Zhong updated PHOENIX-950:
----------------------------------
Attachment: TransactionSupportPhoenixSecondaryIndexUpdate.pdf
In order to improve global secondary index failure handling better I'm planning
to do the following two things:
Firstly a short-term workaround approach:
1) Having a "prepare" phase before data region's WAL appendNoSync to check
index region is online(as most failure situation should index RS isn't
available)
2) When index updates fails, we set index to "inactive" state(disallow reads
while writes still can come)
3) Rebuild index partially in background from where it failed
Secondly, using transaction to better handle secondary index update. See my
attached proposal. We could use a general transaction implementation to do the
same while so far a general transaction implementation seems won't available
soon, may require an extra component and some performance ramifications.
-Jeffrey
> Improve Secondary Index Update Failure Handling
> -----------------------------------------------
>
> Key: PHOENIX-950
> URL: https://issues.apache.org/jira/browse/PHOENIX-950
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Jeffrey Zhong
> Assignee: Jeffrey Zhong
> Attachments: Improve Phoenix Secondary Index Update Failure
> Handling.pdf, TransactionSupportPhoenixSecondaryIndexUpdate.pdf
>
>
> Current secondary index update could trigger chained region server failures.
> This isn't friendly to end-users. Even we disable index after index update
> failures before aborting, it will involve lot of human involvement because
> index update failure isn't a rare situation.
> In this JIRA, I propose a 2PC like protocol. The "like" means it's a not a
> real 2PC because no infinitely blocking but it requires read time(query) to
> reconcile inconsistence between index and data. Since I'm not familiar with
> the query time logic, please let me know if the proposal could fly.
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
