[
https://issues.apache.org/jira/browse/PHOENIX-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16155722#comment-16155722
]
Vincent Poon edited comment on PHOENIX-3953 at 9/6/17 5:17 PM:
---------------------------------------------------------------
[~jamestaylor] Is there a way for us to signal that this happened, perhaps by
setting the indexDisableTimestamp to a special negative value? At a minimum, I
think we should add a log line to indicate this. Otherwise from an operator
perspective, we would see a disabled index and have to triage why the rebuilder
didn't fix it.
Perhaps a new index state would make it even clearer
was (Author: vincentpoon):
[~jamestaylor] Is there a way for us to signal that this happened, perhaps by
setting the indexDisableTimestamp to a special negative value? At a minimum, I
think we should add a log line to indicate this. Otherwise from an operator
perspective, we would see a disabled index and have to triage why the rebuilder
didn't fix it.
> 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_addendum1.patch, 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)
