[
https://issues.apache.org/jira/browse/PHOENIX-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116674#comment-15116674
]
Alicia Ying Shu commented on PHOENIX-2221:
------------------------------------------
[~jamestaylor]
>the commit should fail after you disable the index table, but it looks to be
>succeeding. That's not correct.
It is the correct behavior. The commit would succeed because the data had been
written to the data table. After that the index update failed. But the index
update failure would not throw SQLException because it would trigger index
repair at handleFailure(Multimap<HTableInterfaceReference, Mutation> attempted,
Exception cause) in PhoenixIndexFailurePolicy.java. That would set
indexDisableTimestamp etc., all the changes we made. Thus the data commit would
succeed.
>only a single row should be returned from the query after that as the
>timestamp should be set such that you wouldn't see the committed data.
There would be 2 rows returned. One is the last inserted value after index
repair finished. One is the repaired index value (the one that had been written
to the data table, but failed when updating index). Thus the tests are correct.
>you should be able to just disable the index table rather than delete it
Delete index table can simulate index update failure and it worked.
> Option to make data regions not writable when index regions are not available
> -----------------------------------------------------------------------------
>
> Key: PHOENIX-2221
> URL: https://issues.apache.org/jira/browse/PHOENIX-2221
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Devaraj Das
> Assignee: Alicia Ying Shu
> Fix For: 4.8.0
>
> Attachments: DelegateIndexFailurePolicy.java, PHOENIX-2221-v1.patch,
> PHOENIX-2221-v2.patch, PHOENIX-2221-v3.patch, PHOENIX-2221-v4.patch,
> PHOENIX-2221-v5.patch, PHOENIX-2221-v6.patch, PHOENIX-2221.patch,
> PHOENIX-2221.wip, PHOENIX-2221_v7.patch
>
>
> In one usecase, it was deemed better to not accept writes when the index
> regions are unavailable for any reason (as opposed to disabling the index and
> the queries doing bigger data-table scans).
> The idea is that the index regions are kept consistent with the data regions,
> and when a query runs against the index regions, one can be reasonably sure
> that the query ran with the most recent data in the data regions. When the
> index regions are unavailable, the writes to the data table are rejected.
> Read queries off of the index regions would have deterministic performance
> (and on the other hand if the index is disabled, then the read queries would
> have to go to the data regions until the indexes are rebuilt, and the queries
> would suffer).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
