[
https://issues.apache.org/jira/browse/PHOENIX-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ankit Singhal updated PHOENIX-3045:
-----------------------------------
Attachment: PHOENIX-3045.patch
[~jamestaylor],
bq. Does this issue happen when we attempt to replay the index WAL entries when
the data WAL entries are being replayed
Yes, this is during the WAL replay time.
bq. Can we detect that the index table no longer exists and not do the index
WAL replay?
I tried in attached patch but not sure it's the right way.
bq. It's only if the RS crashes during flush, right?
I think the actual scenarios is, RS crashes and index is dropped during WAL
replay.
bq. If that's not feasible, then perhaps this is enough of a corner case to
allow us to defer it to a 4.8.1 point release?
Yes, IMO it can be defer to 4.8.1 if workaround provided above actually works
otherwise user will not be able to recover it's data region without losing
data(by manually side lining the WAL files).
> Data regions in transition forever if RS holding them down during drop index
> and before flush on data table
> ------------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-3045
> URL: https://issues.apache.org/jira/browse/PHOENIX-3045
> Project: Phoenix
> Issue Type: Bug
> Reporter: Sergio Peleato
> Assignee: Ankit Singhal
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3045.patch
>
>
> Currently we are flushing data table after dropping the index so that region
> opening won't be failed to recover dropped index edits. But there is a chance
> that region server holding the data regions might abruptly killed before
> flushing the data table this leads same failure case that data regions won't
> be opened which leads to the regions in transition forever. We need to handle
> this case by checking dropped indexes on recovery write failures and skip the
> corresponding mutations to write to them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
