[ https://issues.apache.org/jira/browse/PHOENIX-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14804536#comment-14804536 ]
James Taylor commented on PHOENIX-2221: --------------------------------------- +1 to [~rajeshbabu]'s idea to reuse INDEX_DISABLE_TIMESTAMP. Instead of adding a new config parameter (INDEX_FAILURE_BLOCK_WRITE_ATTRIB), how about we use INDEX_RECOVERY_FAILURE_POLICY_KEY to a new class that implements the IndexFailurePolicy interface? Just to confirm, this is a system-wide setting, not a per table option, correct? Also, transactions are nearing completion which will guarantee indexes to be transactionally consistent with the data table. IMHO, this is a much cleaner, crisper answer to this issue. Are we sure we want to introduce another semi-hack to deal with consistency issues? > 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 > Attachments: PHOENIX-2221.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)