Server crashes in one of the secondary indexes created on virtual column
General
Escalation
General
Escalation
Description
Environment
None
AFFECTED CS IDs
CS0016057, CS0017525, CS0018218, CS0019123, CS0036624
Smart Checklist
Activity
Show:
Aaditya Dubey August 6, 2024 at 8:29 AM
Hi
We were unable to repeat the issue; if you get the reproducible steps, please feel free to create a new report for this case. closing this report.
edwin.wang June 21, 2024 at 4:49 PMEdited
No, We couldn’t reproduce the same issue. But it seems the chances of data corruption(and in turn mysql crash) increased when working with virtual column
Przemyslaw Malkowski June 7, 2023 at 9:16 AM
Similar issue happened on 8.0.28-20:
The table has GENERATED ALWAYS AS ... column, but the corrupted index is on a single timestamp column.
Satya Bodapati January 19, 2022 at 1:30 PM
but once is index is corrupted, there is no way to fix it. only dump and restore is the way.
Satya Bodapati January 19, 2022 at 1:30 PMEdited
look around secondary index (virtual column) bugs fixed in 8.0 (release notes) after 8.0.23
Cannot Reproduce
Details
Details
Assignee
Unassigned
UnassignedReporter
Fernando Laudares CarmagosTime tracking
1d 6h 30m logged
Affects versions
Priority
MediumSmart Checklist
Open Smart Checklist
Smart Checklist
Open Smart Checklist
Created June 28, 2021 at 9:38 PM
Updated August 6, 2024 at 8:29 AM
Resolved August 6, 2024 at 8:29 AM
Servers are crashing on compressed tables where the purge thread is trying to clean up some records. The other thing to note is that these are all indexes on virtual columns:
The next operation in that stack should btr_page_get_father_node_ptr_func, as the servers are crashing with:
with <indexA> being one composed by thee fields (fieldA, fieldB, fieldC) where:
`fieldA` varbinary(1536) NOT NULL,
`fieldB` tinyint(1) NOT NULL DEFAULT '0',
`fieldC` bigint(20) GENERATED ALWAYS AS ((case when isnull(json_unquote(json_extract(`metadata`,'$._ttl'))) then NULL else to_seconds((`ts` + interval json_unquote(json_extract(`metadata`,'$._ttl')) second)) end)) STORED,
with `ts` being a 4th, timestap (6) field. The target table is created with compression:
Another similar index (<indexB>) composed of only (fieldB, fieldC) is not affected by the problem and, from the few samples I've got, report a smaller number of entries when corruption is perceived on the "main" index: