[
https://issues.apache.org/jira/browse/IGNITE-26261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-26261:
-----------------------------------
Description:
It seems, than we have insufficient validation when inserting entries with
changed class of key into a cache with enabled indexing.
When we try to put entries with new key class, but the same indexed field,
there are some possible scenarios:
# Some data can become unavailable with SQL.
# Unexpected SQL requests failures can occur.
# Node failures on put.
# B+Tree corruption after multiple puts. As I see, there are no possibility to
rebuild indexes, maintenance mode also fails to rebuild index. It is impossible
to restore data with standard utilities.
*Root cause for all cases:*
{code}
org.apache.ignite.binary.BinaryObjectException: Failed to get field because
type ID of passed object differs from type ID this BinaryField belongs to
[expected=[typeId=449234053,
typeName=org.apache.ignite.KeyClassChangeTest$OtherIntKey],
actual=[typeId=1318599563,
typeName=org.apache.ignite.KeyClassChangeTest$IntKey], fieldId=106079,
fieldName=key, fieldType=int]
{code}
Problem is reproduced on Calcite and H2 engines.
*How to reproduce:*
# Create cache with query entity, where key class contains field, annotated
both {{@AffinityKeyMapped}} and {{@QuerySqlField}} annotations. In order to
trigger B+Tree corruption, it is not necessary to annotate field with
{{@AffinityKeyMapped}}. Problem is reproduced with annotation
{{@QuerySqlField(index = true)}}.
# Insert some entries.
# Create new key class with the same field: same name, same annotations.
# If you try to insert some entries with new key from *primary*, then you will
get {{CacheException}}. But entry will be inserted! Entry can not be obtained
from SQL.
# If you try to insert some entries with new key from *backup*, then all other
nodes, mapped to the key, will fail.
# Then, *deactivate* and restart cluster, and try to put few entries, then no
exception occur at all. But now you can not call such queries, as {{select *
from table}} (it seems, that problem will occur, when both keys conforms query
conditions). It does not matter, entries were put from primary or from backup.
# Now, if you try to put relatively large amount of entries, then you will get
B+Tree corruption, which will not be fixed during maintenance mode.
*Reproducer:* [^KeyClassChangeTests.patch]
*Also, it should be investigated:*
# Atomic caches.
# Changing of key field class instead of entire key class. Nested field class
should contain {{@AffinityKeyMapped}} and {{@QuerySqlField}} annotations on one
field.
# Possible B+Tree corruptions during SQL requests.
was:
It seems, than we have insufficient validation when inserting entries with
changed class of key into a cache with enabled indexing.
When we try to put entries with new key class, but the same indexed field,
there are some possible scenarios:
# Some data can become unavailable with SQL.
# Unexpected SQL requests failures can occur.
# Node failures on put.
# B+Tree corruption after multiple puts. As I see, there are no possibility to
rebuild indexes, maintenance mode also fails to rebuild index. It is impossible
to restore data with standard utilities.
*Root cause for all cases:*
{code}
org.apache.ignite.binary.BinaryObjectException: Failed to get field because
type ID of passed object differs from type ID this BinaryField belongs to
[expected=[typeId=449234053,
typeName=org.apache.ignite.KeyClassChangeTest$OtherIntKey],
actual=[typeId=1318599563,
typeName=org.apache.ignite.KeyClassChangeTest$IntKey], fieldId=106079,
fieldName=key, fieldType=int]
{code}
Problem is reproduced on Calcite and H2 engines.
*How to reproduce:*
# Create cache with query entity, where key class contains field, annotated
both {{@AffinityKeyMapped}} and {{@QuerySqlField}} annotations. It is not
necessary to annotate field with {{@AffinityKeyMapped}}, in order to trigger
B+Tree corruption, bug is reproduced with annotation {{@QuerySqlField(index =
true)}}.
# Insert some entries.
# Create new key class with the same field: same name, same annotations.
# If you try to insert some entries with new key from *primary*, then you will
get {{CacheException}}. But entry will be inserted! Entry can not be obtained
from SQL.
# If you try to insert some entries with new key from *backup*, then all other
nodes, mapped to the key, will fail.
# Then, *deactivate* and restart cluster, and try to put few entries, then no
exception occur at all. But now you can not call such queries, as {{select *
from table}} (it seems, that problem will occur, when both keys conforms query
conditions). It does not matter, entries were put from primary or from backup.
# Now, if you try to put relatively large amount of entries, then you will get
B+Tree corruption, which will not be fixed during maintenance mode.
*Reproducer:* [^KeyClassChangeTests.patch]
*Also, it should be investigated:*
# Atomic caches.
# Changing of key field class instead of entire key class. Nested field class
should contain {{@AffinityKeyMapped}} and {{@QuerySqlField}} annotations on one
field.
# Possible B+Tree corruptions during SQL requests.
> Key class change leads to critical failures and B+Tree corruption
> -----------------------------------------------------------------
>
> Key: IGNITE-26261
> URL: https://issues.apache.org/jira/browse/IGNITE-26261
> Project: Ignite
> Issue Type: Bug
> Affects Versions: 2.16, 2.17
> Reporter: Ilya Shishkov
> Priority: Critical
> Labels: ise
> Attachments: KeyClassChangeTests.patch
>
>
> It seems, than we have insufficient validation when inserting entries with
> changed class of key into a cache with enabled indexing.
> When we try to put entries with new key class, but the same indexed field,
> there are some possible scenarios:
> # Some data can become unavailable with SQL.
> # Unexpected SQL requests failures can occur.
> # Node failures on put.
> # B+Tree corruption after multiple puts. As I see, there are no possibility
> to rebuild indexes, maintenance mode also fails to rebuild index. It is
> impossible to restore data with standard utilities.
> *Root cause for all cases:*
> {code}
> org.apache.ignite.binary.BinaryObjectException: Failed to get field because
> type ID of passed object differs from type ID this BinaryField belongs to
> [expected=[typeId=449234053,
> typeName=org.apache.ignite.KeyClassChangeTest$OtherIntKey],
> actual=[typeId=1318599563,
> typeName=org.apache.ignite.KeyClassChangeTest$IntKey], fieldId=106079,
> fieldName=key, fieldType=int]
> {code}
> Problem is reproduced on Calcite and H2 engines.
> *How to reproduce:*
> # Create cache with query entity, where key class contains field, annotated
> both {{@AffinityKeyMapped}} and {{@QuerySqlField}} annotations. In order to
> trigger B+Tree corruption, it is not necessary to annotate field with
> {{@AffinityKeyMapped}}. Problem is reproduced with annotation
> {{@QuerySqlField(index = true)}}.
> # Insert some entries.
> # Create new key class with the same field: same name, same annotations.
> # If you try to insert some entries with new key from *primary*, then you
> will get {{CacheException}}. But entry will be inserted! Entry can not be
> obtained from SQL.
> # If you try to insert some entries with new key from *backup*, then all
> other nodes, mapped to the key, will fail.
> # Then, *deactivate* and restart cluster, and try to put few entries, then no
> exception occur at all. But now you can not call such queries, as {{select *
> from table}} (it seems, that problem will occur, when both keys conforms
> query conditions). It does not matter, entries were put from primary or from
> backup.
> # Now, if you try to put relatively large amount of entries, then you will
> get B+Tree corruption, which will not be fixed during maintenance mode.
> *Reproducer:* [^KeyClassChangeTests.patch]
> *Also, it should be investigated:*
> # Atomic caches.
> # Changing of key field class instead of entire key class. Nested field class
> should contain {{@AffinityKeyMapped}} and {{@QuerySqlField}} annotations on
> one field.
> # Possible B+Tree corruptions during SQL requests.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
