[
https://issues.apache.org/jira/browse/PHOENIX-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13980018#comment-13980018
]
Jesse Yates commented on PHOENIX-950:
-------------------------------------
Not having read the doc yet, I'd really care more about the recovering from the
case where the index is disabled.
Currently, there is no good mechanism to catchup the index. I'd imagine we
could add an Endpoint that is called when an index falls behind and then async
goes and attempts to catch up the index (from failed update -> current time).
There would need to be some slight machinations (locking, 2PC, careful
replacement, or something like that). on that last bit -"current time" -to
ensure that index doesn't fall behind from the last client write and the
completion of the recovery.
But I'll take a look at the doc :)
bq. We can also optionally not write the index updates to the WAL if that's
problematic (a kind of "do you feel lucky" mode).
This is essentially running without WAL for the primary table - any failures
and you are pretty much hosed.
> 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
> Attachments: Improve Phoenix Secondary Index Update Failure
> Handling.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)
