[
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 entry with new key class, there are some possible scenarios:
# Some data become unavailable with SQL.
# Unexpected SQL requests failures.
# Node failures.
# B+Tree corruption. 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. To B+Corruption
it is not necessary to annotate field {{@AffinityKeyMapped}}, it is reproduced
with annotation {{@QuerySqlField(index = true)}} .
# Insert some entries.
# Create new key class with the same field: same name, same annotations.
# If 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 try to insert some entries with new key from *backup*, then all other
nodes, mapped to the key, will fail.
# If you deactivate and restart cluster, and try to put few entries, then no
exception occur at all. Then 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.
# 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.
was:
It seems, than we have insufficient validation when inserting entries with
changed class of key to cache with indexing.
When we try to put entry with new key class, there are some possible scenarios:
# Some data become unavailable with SQL.
# Unexpected SQL requests failures.
# Node failures.
# B+Tree corruption. 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. To B+Corruption
it is not necessary to annotate field {{@AffinityKeyMapped}}, it is reproduced
with annotation {{@QuerySqlField(index = true)}} .
# Insert some entries.
# Create new key class with the same field: same name, same annotations.
# If 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 try to insert some entries with new key from *backup*, then all other
nodes, mapped to the key, will fail.
# If you deactivate and restart cluster, and try to put few entries, then no
exception occur at all. Then 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.
# 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.
> 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
> Reporter: Ilya Shishkov
> Priority: Critical
> Labels: ise
>
> 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 entry with new key class, there are some possible
> scenarios:
> # Some data become unavailable with SQL.
> # Unexpected SQL requests failures.
> # Node failures.
> # B+Tree corruption. 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. To
> B+Corruption it is not necessary to annotate field {{@AffinityKeyMapped}}, it
> is reproduced with annotation {{@QuerySqlField(index = true)}} .
> # Insert some entries.
> # Create new key class with the same field: same name, same annotations.
> # If 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 try to insert some entries with new key from *backup*, then all other
> nodes, mapped to the key, will fail.
> # If you deactivate and restart cluster, and try to put few entries, then no
> exception occur at all. Then 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.
> # 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
