Details
-
Bug
-
Status: Confirmed (View Workflow)
-
Critical
-
Resolution: Unresolved
-
10.5, 10.6, 10.11, 11.1(EOL), 11.2(EOL), 11.3(EOL)
Description
# Requires standard m/s replication. Use RBR or MBR. |
SET binlog_row_image='NOBLOB'; |
CREATE TABLE t (c INT PRIMARY KEY, d INT, i BLOB GENERATED ALWAYS AS (c), KEY k(i)) ENGINE=InnoDB; |
CREATE TEMPORARY TABLE t2 (c INT) ENGINE=InnoDB; |
INSERT INTO t (c) VALUES (1); |
SELECT * FROM performance_schema.global_status; |
UPDATE t SET d=0; |
Leads to:
10.6.18 33af5575a976c86163752cce77dddb640ffeef00 (Optimized, Slave) |
2024-04-23 10:31:44 6 [ERROR] InnoDB: Record in index `k` of table `test`.`t` was not found on update: TUPLE (info_bits=0, 2 fields): {NULL,[4] (0x80000001)} at: COMPACT RECORD(info_bits=0, 1 fields): {[8]infimum (0x696E66696D756D00)}
|
2024-04-23 10:31:44 6 [ERROR] InnoDB: We detected index corruption in an InnoDB type table. You have to dump + drop + reimport the table or, in a case of widespread corruption, dump all InnoDB tables and recreate the whole tablespace. If the mariadbd server crashes after the startup or when you dump the tables. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
|
2024-04-23 10:31:44 6 [Warning] InnoDB: Record in index `k` of table `test`.`t` was not found on rollback, trying to insert: TUPLE (info_bits=0, 2 fields): {NULL,[4] (0x80000001)} at: COMPACT RECORD(info_bits=0, 1 fields): {[8]infimum (0x696E66696D756D00)}
|
2024-04-23 10:31:44 6 [ERROR] mariadbd: Index for table 't' is corrupt; try to repair it
|
2024-04-23 10:31:44 6 [ERROR] Slave SQL: Could not execute Update_rows_v1 event on table test.t; Index for table 't' is corrupt; try to repair it, Error_code: 1034; handler error HA_ERR_CRASHED; the event's master log binlog.000001, end_log_pos 1595, Gtid 0-1-7, Internal MariaDB error code: 1034
|
2024-04-23 10:31:44 6 [Warning] Slave: Index for table 't' is corrupt; try to repair it Error_code: 1034
|
2024-04-23 10:31:44 6 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'binlog.000001' position 1416; GTID position '0-1-6'
|
May seem lightly sporadic, but is more likely timing-based (i.e. SLEEP's etc. may help to reduce any light sporadicity).
Both dbg+opt affected. PS required. The specific PS table queried does not seem to matter.
The issue has been reproduced in the versions listed above, but not in 11.4, 11.5.
Attachments
Issue Links
- relates to
-
MDEV-34344 Replica index corruption and InnoDB: Failing assertion: !cursor->index->is_committed() in row_ins_sec_index_entry_by_modify when using generated columns
-
- Confirmed
-
-
MDEV-34572 [ERROR] InnoDB: Record in index of table was not found on update
-
- Open
-
I would like to see a self-contained, minimal test case for this. I would suggest to test an AddressSanitizer instrumented build, in case the error occurs due to a memory overrun. I tested the following, without the SELECT statement that would attempt to access performance_schema, because I usually build cmake -DPLUGIN_PERFSCHEMA=NO:
--source include/have_innodb.inc
--source include/have_partition.inc
--error ER_WARNING_NON_DEFAULT_VALUE_FOR_GENERATED_COLUMN
--error ER_TRUNCATED_WRONG_VALUE_FOR_FIELD
There was no crash on 10.6 bb2e125d076d9475cbe04fc8c24fbaee39d76bda.