[
https://issues.apache.org/jira/browse/PHOENIX-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15095708#comment-15095708
]
James Taylor commented on PHOENIX-2221:
---------------------------------------
[~ayingshu] - I found and fixed several other problems in your patch already.
For example, you weren't updating the protobuf, so the value would never had
made it to the client.
Please make the changes I suggested of entering that if statement based on the
index state *or* the index disable timestamp changing (rather than the logic
you mentioned above).
The test mechanism will be fine to verify that writes are blocked to the data
table. Instead of deleting the underlying HBase index table, you can just
disable it so that you can enhance the test to confirm that indexes are written
to again (i.e. by enabling the underlying HBase index table again).
You just need to confirm the basic flow:
- index cannot be written to
- index disable timestamp set
- data table invalidated
- next client access pulls over modified data table
- attempts to write are blocked
- reads to table reflect only previous mutations (i.e. the current batch that
failed shouldn't be read because the upper bound on the scan prevents it)
- re-enable the underlying index table
- partial index rebuild kicks in and writes the missing batch
- index disable timestamp is cleared
- data table invalidated
- next client access pulls over modified data table
- attempts to write are no longer blocked
- index is consistent with data table
Is this working? You can step through this in a debugger. Where is it breaking
down.
> 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.patch, PHOENIX-2221.wip
>
>
> 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)
