[
https://issues.apache.org/jira/browse/IGNITE-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503349#comment-16503349
]
Vladimir Ozerov edited comment on IGNITE-8723 at 6/6/18 2:10 PM:
-----------------------------------------------------------------
[~agoncharuk], I doubt it would work for MVCC. Consider an {{UPDATE}} or
{{SELECT FOR UPDATE}} query which needs to take a lock on a key. All such
queries must lock a key on a primary node.
I think more generic approach here is to disable an index cluster-wide. This is
common practice in other databases - indexes could be switched off ("offline")
either manually, or automatically in case of corrupt. We already has necessary
infrastructure for this - exchange-like consensus protocol to initiate DDL
change, and hidden indexes, which are not used in queries, but are still
updated (we can disable it if needed).
I think this would be better solution than adding more complexity to request
routing logic which is already non trivial (partitioned vs replicated,
multicast vsunicast, update w/ and w/o reducer, MVCC cases, etc).
was (Author: vozerov):
[~agoncharuk], I doubt it would work for MVCC. Consider an {{UPDATE}} or
{{SELECT FOR UPDATE}} query which needs to take a lock on a key. All such
queries must lock a kay on a primary node.
I think more generic approach here is to disable an index cluster-wide. This is
common practice in other databases - indexes could be switched off ("offline")
either manually, or automatically in case of corrupt. We already has necessary
infrastructure for this - exchange-like consensus protocol to initiate DDL
change, and hidden indexes, which are not used in queries, but are still
updated (we can disable it if needed).
I think this would be better solution than adding more complexity to request
routing logic which is already non trivial (partitioned vs replicated,
multicast vsunicast, update w/ and w/o reducer, MVCC cases, etc).
> Detect index corruption at runtime
> ----------------------------------
>
> Key: IGNITE-8723
> URL: https://issues.apache.org/jira/browse/IGNITE-8723
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexey Goncharuk
> Priority: Major
> Fix For: 2.6
>
>
> Several times Ignite users faced a situation when SQL indexes were corrupted
> (linked to invalid or removed data).
> I think it makes sense to slightly rework such errors during index
> dereference, and
> 1) Fail all ongoing and further SQL queries assigned to this node. SQL mapper
> should cache this and try to re-route SQL requests to other OWNING nodes
> 2) After index corruption is detected, all or only corrupted indexes should
> be deallocated (the decision depends on what is faster) and rebuilt
> 3) After indexes are rebuilt, we should notify other nodes that the node is
> available for queries again
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
