[ https://issues.apache.org/jira/browse/IGNITE-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16503349#comment-16503349 ]
Vladimir Ozerov commented on IGNITE-8723: ----------------------------------------- [~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)