[
https://issues.apache.org/jira/browse/PHOENIX-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16154049#comment-16154049
]
James Taylor commented on PHOENIX-3953:
---------------------------------------
bq. Does this mean we're writing to another table (to a region most likely
located on a different server) from inside the compaction hooks? That sounds
scary. Does it fail gracefully, i.e. letting the compaction finish?
Yes, we need to do this as otherwise the index cannot potentially no longer be
rebuilt correctly. Having an index out of sync with the data table without
knowing it is pretty scary too. We do let the compaction finish under failure,
but it might be better to abort the compaction and let it run next time to
prevent the index/data table potentially getting of sync.
> Clear INDEX_DISABLED_TIMESTAMP and disable index on compaction
> --------------------------------------------------------------
>
> Key: PHOENIX-3953
> URL: https://issues.apache.org/jira/browse/PHOENIX-3953
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: James Taylor
> Labels: globalMutableSecondaryIndex
> Fix For: 4.12.0
>
> Attachments: PHOENIX-3953.patch, PHOENIX-3953_v2.patch
>
>
> To guard against a compaction occurring (which would potentially clear delete
> markers and puts that the partial index rebuild process counts on to properly
> catch up an index with the data table), we should clear the
> INDEX_DISABLED_TIMESTAMP and mark the index as disabled. This could be done
> in the post compaction coprocessor hook. At this point, a manual rebuild of
> the index would be required.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
