[
https://issues.apache.org/jira/browse/PHOENIX-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15143683#comment-15143683
]
James Taylor commented on PHOENIX-2635:
---------------------------------------
This JIRA is about rebuilding an index after a write to it has failed. In this
case, the write to the data table succeeded, but the write to the index failed.
We know the timestamp of the mutations that failed to go through, so we can
only replay mutations at or older than this timestamp. We're not replaying the
WAL here - we're issuing a query against the data table and re-issuing the
mutations so that our coprocessor will generate the corresponding index
mutations. We need to replay all mutations. For example, let's say that that a
row was deleted from the data table. That write succeeds, but the corresponding
delete of the index row fails. We need to do a raw scan on the data table to
pick up that delete. If we don't, we'll simply find no mutations and assume
that the index is now valid.
> Partial index rebuild doesn't delete prior index row
> ----------------------------------------------------
>
> Key: PHOENIX-2635
> URL: https://issues.apache.org/jira/browse/PHOENIX-2635
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
>
> The partial rebuild index feature for mutable secondary indexes does not do
> the correct index maintenance. We currently only insert the new index rows
> based on the current data row values which would not correctly remove the
> previous index row (thus leading to an invalid index). Instead, we should
> replay the data row mutations so that the coprocessors generate the correct
> deletes and updates.
> Also, instead of *every* region running the partial index rebuild, we should
> have each region only replay their own data mutations so that we're not
> duplicating work.
> A third (and perhaps most serious) issue is that the partial index rebuild
> could trigger the upgrade code before a cluster is ready to be upgraded.
> We'll definitely want to prevent that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
