phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey Zhong (JIRA)" <>
Subject [jira] [Updated] (PHOENIX-950) Improve Secondary Index Update Failure Handling
Date Mon, 16 Jun 2014 22:50:02 GMT


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


> Improve Secondary Index Update Failure Handling
> -----------------------------------------------
>                 Key: PHOENIX-950
>                 URL:
>             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

View raw message