[MDEV-22986] [ERROR] InnoDB: Record in index was not found on update in mysqld.log on slave Created: 2020-06-23  Updated: 2023-03-06  Resolved: 2023-03-06

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.2.31, 10.3.28, 10.4.19, 10.3
Fix Version/s: N/A

Type: Bug Priority: Critical
Reporter: Vova Moroz Assignee: Marko Mäkelä
Resolution: Incomplete Votes: 3
Labels: corruption
Environment:

CentOS7

Issue Links:
Relates
relates to MDEV-9663 InnoDB assertion failure: *cursor->in... Closed
relates to MDEV-21790 secondary index corruption after 10.3... Closed
relates to MDEV-26977 mariadb 10.5.12 reboot loop in AWS | ... Closed
relates to MDEV-27734 Set innodb_change_buffering=none by d... Closed
relates to MDEV-30009 InnoDB shutdown hangs when the change... Closed

 Description   

[ERROR] InnoDB: Record in index `item_id` of table `item3`.`deleted_items` was not found on update: TUPLE (info_bits=0, 2 fields):

{[4] x (0x819678F8),[4] ;J (0x003B4AD8)}

at: COMPACT RECORD(info_bits=32, 2 fields):

{[4] x (0x819678F8),[4] ;( (0x003B28F9)}

 Comments   
Comment by Marko Mäkelä [ 2020-07-01 ]

Moroz, do you have any more information on this corruption?

Comment by Vova Moroz [ 2020-07-03 ]

Hi, Marko! Could you tell wich information is needed and where can I find it?

Comment by Marko Mäkelä [ 2021-03-22 ]

Moroz, SHOW CREATE TABLE could help. Was the index item_id created on a virtual column? If yes, we have plenty of bugs related to indexed virtual columns.

If the index is on a regular stored column, then it is possible that the database was corrupted due to MDEV-24449 at some point of the past. Rebuilding the table should fix it:

ALTER TABLE item3.deleted_items FORCE;

Comment by Valerii Kravchuk [ 2021-07-03 ]

This still happens in 10.4.19 too, (Galera cluster node) after restart with innodb_fast_shutdown=0 and with innodb_change_buffering = none, for several tables and none of them has virtual columns:

2021-07-02 17:50:38 32 [ERROR] InnoDB: Record in index `last_login` of table `db1`.`t1` was not found on update: TUPLE (info_bits=0, 2 fields): {[4]` 0:(0x60DE303A),[8] c (0x0000000000006388)} at: COMPACT RECORD(info_bits=0, 2 fields): {[4]` (0x60DDB3C6),[8] s_(0x000000000000735F)}
 
2021-07-03 0:00:04 32 [ERROR] InnoDB: Record in index `type` of table `db2`.`t2` was not found on update: TUPLE (info_bits=0, 3 fields): {[1] (0x03),[4] Y>(0xC1D1593E),[8] 9(0x0000000000019039)} at: COMPACT RECORD(info_bits=0, 3 fields): {[1] (0x03),[4] Y>(0xC39E593E),[8] q(0x0000000000018871)}
 
2021-07-03 0:04:51 52 [ERROR] InnoDB: Record in index `type` of table `db3`.`t2` was not found on update: TUPLE (info_bits=0, 3 fields): {[1] (0x03),[4] 7=(0x91AB373D),[8] (0x000000000017DCF4)} at: COMPACT RECORD(info_bits=0, 3 fields): {[1] (0x03),[4]K 7=(0x4BAA373D),[8] r(0x0000000000129172)}

Comment by Marko Mäkelä [ 2021-07-03 ]

valerii, there exist various bugs with indexed virtual columns that can cause such corruption. Please check if one of the bugs applies to your case, and re-close this bug if appropriate.

We should keep in mind that InnoDB corruption usually does not heal by itself; you will have to drop and re-create the corrupted index, or rebuild the table.

You might want to check what I wrote in MDEV-22373 (which I expect to close in a few months, once the reporter has confirmed the fix):

For any MySQL or MariaDB version before 10.5.0, the race condition that was fixed in MDEV-24449 could corrupt anything in the InnoDB system tablespace as well as any secondary index pages during crash recovery. For MariaDB Server 10.2, 10.3, 10.4 but not 10.5, the change MDEV-21069 introduced MDEV-25869: wrongful deletion of change buffer records after server restart for files whose first page had not yet been read.

That applies to non-virtual columns. I am afraid that with indexed virtual columns, it is still easy to trigger corruption via other bugs.

Comment by Marko Mäkelä [ 2021-09-17 ]

valerii, starting with the 10.4 series, virtual columns may ‘secretly’ be used due to MDEV-371, and there is an open bug MDEV-22759.

Moroz, is this reproducible with a more recent server? Several possible fixes related to this are linked from MDEV-22373.

Comment by Vova Moroz [ 2021-09-18 ]

Hi,

Still getting after update on 10.3.29. There are no virtual columns.

[ERROR] InnoDB: Record in index `subscribeId` of table `auto3_search_history`.`searchSubscribe` was not found on update: TUPLE (info_bits=0, 2
fields):

{[8] + h(0x80000000002BBC68),[8] u(0x0000000000AABB75)}

at: COMPACT RECORD(info_bits=0, 2 fields):

{[8] + h(0x80000000002BBC68),[8] / (0x000 00000009C2FD2)}

as well as other ones:

2021-09-02 18:34:18 2 [ERROR] InnoDB: Unable to find a record to delete-mark
InnoDB: tuple DATA TUPLE: 2 fields;
0: len 17; hex 4b4c31554637353631384b383039363238; asc KL1UF75618K809628;;
1: len 8; hex 000000000188ff94; asc ;;

InnoDB: record PHYSICAL RECORD: n_fields 2; compact format; info bits 0
0: len 17; hex 4b4c31554637353631354b313630313237; asc KL1UF75615K160127;;
1: len 8; hex 0000000001a2951c; asc ;;
2021-09-02 18:34:18 2 [ERROR] InnoDB: page [page id: space=2159, page number=73312] (335 records, index id 143734).
2021-09-02 18:34:18 2 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/

Comment by martina342 [ 2021-09-21 ]

Hello Marko,

I have the same error on 10.6.5

2021-09-21  1:16:52 3540276 [ERROR] InnoDB: Clustered record for sec rec not found index `****` of table `***`.`***`
 
InnoDB: sec index record PHYSICAL RECORD: n_fields 2; compact format; info bits 0
 
 0: len 30; hex ***; asc ****; (total 40 bytes);
 
 1: len 4; hex 0303b5e7; asc     ;;
 
 
 
InnoDB: clust index record PHYSICAL RECORD: n_fields 285; compact format; info bits 0
 
 0: len 4; hex 0303b5e6; asc     ;;
 
 1: len 6; hex 000000000000; asc       ;;
 
 2: len 7; hex 80000000000000; asc        ;;
 
 3: len 30; hex 202020202020202020202020202020202020202020202020202020202020; asc                               ; (total 40 bytes);
 
 4: len 4; hex 0012d271; asc    q;;
 
 5: len 6; hex 526f6d616e65; asc Romane;;
 



2021-09-21 11:47:18 4168529 [ERROR] InnoDB: Record in index `id****` of table `b****`.`pe*****` was not found on update: TUPLE (info_bits=0, 2 fields): {[40]**** (****),[4]    (0x00000001)} at: COMPACT RECORD(info_bits=0, 2 fields): {[40]**** (*****),[4] 1  (0x0031DF1D)}
 
2021-09-21 13:29:56 4163657 [ERROR] InnoDB: Records in wrong order
 
 
 
InnoDB: previous record PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 
 0: len 30; hex ****; asc ****-9r; (total 40 bytes);
 
 1: len 4; hex 00019622; asc    ";;
 
 2: len 4; hex 00bb00b8; asc     ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 
 0: len 30; hex ****; asc ****; (total 40 bytes);
 
 1: len 4; hex 0027d1f9; asc  '  ;;
 
 2: len 4; hex 00bab575; asc    u;;

I think that what caused it was killing a request to update the type of a column, which is varchar/char, and is indexed

dropping then recreating the index fixed it.

The table is not virtual

edit: actually even a non related index is corrupted :
Warning : InnoDB: Index '***' contains 68069449 entries, should be 68069450.
error : Corrupt

edit: this last index corrupted may be due to things I had to do to be able to restart the server to remove the index as it was crashing on start

Comment by Marko Mäkelä [ 2021-09-29 ]

martina342, in some other ticket you mentioned that you had run with innodb_undo_log_truncate=ON. Unfortunately, there has been some corruption related to that, to be fixed in the upcoming releases, in MDEV-26450 (10.2+) and MDEV-26672 (10.3+). Could this corruption be related to that?

martina342 and Moroz, does the corruption go away if you rebuild the table (OPTIMIZE TABLE or ALTER TABLE…FORCE)? If not, I would like to see the SHOW CREATE TABLE output, showing at least the PRIMARY KEY columns and the columns that are part of the problematic secondary index. There is a known bug MDEV-25440 that affects NO PAD collations.

Comment by martina342 [ 2021-09-29 ]

no it is not related to undo log truncate, the whole data have been reimported with undo truncation disabled

i don't know if optimize table/alter table fix it, as i already fixed the index since my message

here are the fields. Both xxx and yyy were corrupted

CREATE TABLE `personnes` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`YYY` char(40) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,

`XXX` varchar(180) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NOT NULL,

PRIMARY KEY (`id`),
KEY `yyy` (`yyy`),
KEY `XXX` (`XXX`),
) ENGINE=InnoDB AUTO_INCREMENT=77368337 DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC |

the 2 indexes were modified during big transactions were running on the table

Comment by Vova Moroz [ 2021-09-29 ]

Hi,

After ALTER TABLE .. FORCE corruption goes away.

Comment by Marko Mäkelä [ 2021-09-29 ]

martina342, thank you. Because you are using 10.6.5 and not using indexed virtual columns, there should still be some unknown corruption out there. As I noted in MDEV-22373 today, it is very hard to reproduce this kind of bugs in our internal stress testing, which typically uses much smaller data sets (on RAM disk) and data directory lifespans (measured in minutes, not years).

I will keep waiting for further feedback from you and Moroz and any other affected users. It would be interesting to know if setting innodb_change_buffering=none (after rebuilding the affected table) would prevent this corruption.

Comment by martina342 [ 2021-10-02 ]

hello, a quick update.
It corrupted again before I modify innodb_change_buffering : 

2021-09-30 13:44:53 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 026a95c3; asc  j  ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 13:44:53 12260134 [ERROR] InnoDB: page [page id: space=98, page number=7093245] (235 records, index id 1749).
 
2021-09-30 13:44:53 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 13:45:10 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 017376de; asc  sv ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 13:45:10 12260134 [ERROR] InnoDB: page [page id: space=98, page number=5026541] (236 records, index id 1749).
 
2021-09-30 13:45:10 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 13:45:44 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 016ac181; asc  j  ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 13:45:44 12260134 [ERROR] InnoDB: page [page id: space=98, page number=3404264] (230 records, index id 1749).
 
2021-09-30 13:45:44 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 14:08:42 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 012916a7; asc  )  ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 14:08:42 12260134 [ERROR] InnoDB: page [page id: space=98, page number=4012853] (255 records, index id 1749).
 
2021-09-30 14:08:42 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 14:40:58 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 027cecc2; asc  |  ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 14:40:58 12260134 [ERROR] InnoDB: page [page id: space=98, page number=4416346] (233 records, index id 1749).
 
2021-09-30 14:40:58 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 004f7eb8; asc  O~ ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: page [page id: space=98, page number=1340493] (240 records, index id 1749).
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 004f6fa7; asc  Oo ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: page [page id: space=98, page number=1340493] (240 records, index id 1749).
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 0050986f; asc  P o;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: page [page id: space=98, page number=1340493] (240 records, index id 1749).
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 004f2298; asc  O" ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: page [page id: space=98, page number=1340493] (240 records, index id 1749).
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 004f83ad; asc  O  ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: page [page id: space=98, page number=1340493] (240 records, index id 1749).
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 004f82aa; asc  O  ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: page [page id: space=98, page number=1340493] (240 records, index id 1749).
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 0050adfd; asc  P  ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: page [page id: space=98, page number=1340493] (240 records, index id 1749).
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 0050b2cd; asc  P  ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: page [page id: space=98, page number=1340493] (240 records, index id 1749).
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 004f4e74; asc  ONt;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: page [page id: space=98, page number=1340493] (240 records, index id 1749).
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Unable to find a record to delete-mark
 
InnoDB: tuple DATA TUPLE: 2 fields;
 
 0: len 0; hex ; asc ;;
 
 1: len 4; hex 0050a218; asc  P  ;;
 
 
 
InnoDB: record PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 
 0: len 8; hex 696e66696d756d00; asc infimum ;;
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: page [page id: space=98, page number=1340493] (240 records, index id 1749).
 
2021-09-30 16:04:09 12260134 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/

i wasn't modifying any index, so it wasn't related to any index creation/modification.

i deleted and recreated the mentioned index using index id, and set innodb_change_buffering=none

i'm not waiting to see if it corrupt again

edit: it was one of the same index that corrupted itself before

Comment by martina342 [ 2021-10-16 ]

it's been 2 weeks with innodb_change_buffering=none without any index corruption,
so I guess this settings prevent the error

Comment by martina342 [ 2021-11-13 ]

hello,
it ias been more than a month without corruption. Marko, are you still working on a fix for this ?

Comment by ssauravy [ 2021-12-27 ]

The same thing happened.

innodb_fast_shutdown=0
innodb_change_buffering=none
After reflecting, again in 4 days
An error has occurred.
as a temporary measure
The table has been reorganized.
alter table tbl1 engine=innodb;

MariaDB [(none)]> select @@version;
---------------------

@@version

---------------------

10.3.32-MariaDB-log

---------------------

Comment by Marko Mäkelä [ 2022-02-08 ]

Is this corruption repeatable for anyone after:

  1. Setting innodb_change_buffering=none
  2. Rebuilding all secondary indexes for which corruption has been reported

Note: Disabling the change buffering will not fix already corrupted indexes. It will only prevent further corruption by the change buffer.

Comment by martina342 [ 2022-02-08 ]

for me,
innodb_change_buffering=none
then recreate all tables and it's been multiple months without crashes

Comment by Juan [ 2022-02-08 ]

marko - None of the support cases potentially affected by this which I have been watching have reported any corruption recurrence after changing to innodb_change_buffering=none.

Comment by Marko Mäkelä [ 2022-03-22 ]

This is still waiting for a reproducible test case. MDEV-26977 is essentially a duplicate of this report, and this report is essentially a duplicate of MDEV-9663, which was closed prematurely. We are unable to reproduce such corruption in-house.

A work-around was implemented in 10.5.15, 10.6.7, 10.7.3, 10.8.2 by MDEV-27734 (Set innodb_change_buffering=none by default) after testing that there should not be significant performance impact. Some graphs were posted to MDEV-11634.

Comment by Ruben Estrada Orozco [ 2022-07-27 ]

I think I have a similar error and I already have innodb_change_buffering=none:

2022-07-27  9:34:38 215 [ERROR] InnoDB: Record in index `vtiger_crmentity_labelidx` of table `vt_produccion`.`vtiger_crmentity` was not found on update: TUPLE (info_bits=0, 2 fields): {[30]Sandra Sandy Mu  oz Fe
 
rn  ndez(0x53616E6472612053616E6479204D75C3B16F7A204665726EC3A16E64657A),[4] =  (0x803DD517)} at: COMPACT RECORD(info_bits=0, 2 fields): {[23]Sandra Saavedra Ch  vez(0x53616E647261205361617665647261204368C3A1766
 
57A),[4] BU (0x804255E8)}
 
2022-07-27 10:09:48 382 [ERROR] InnoDB: Corruption of an index tree: table `vt_produccion`.`vtiger_crmentity` index `vtiger_crmentity_labelidx`, father ptr page no 70022, child page no 273970
 
PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 
 0: len 30; hex 59612064656369646520706f72206f74726120756e697665727369646164; asc Ya decide por otra universidad; (total 90 bytes);
 
 1: len 4; hex 8005fd4d; asc    M;;
 
 2: len 4; hex 00044186; asc   A ;;
 
2022-07-27 10:09:48 382 [Note] InnoDB: n_owned: 0; heap_no: 2; next rec: 233
 
PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 
 0: len 19; hex 554e49564552534944414420c38d5441434120; asc UNIVERSIDAD   TACA ;;
 
 1: len 4; hex 803fdbf4; asc  ?  ;;
 
 2: len 4; hex 00011186; asc     ;;
 
2022-07-27 10:09:48 382 [Note] InnoDB: n_owned: 5; heap_no: 54; next rec: 13420
 
2022-07-27 10:09:48 382 [ERROR] [FATAL] InnoDB: You should dump + drop + reimport the table to fix the corruption. If the crash happens at database startup. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery. Then dump + drop + reimport.
 
220727 10:09:48 [ERROR] mysqld got signal 6 ;
 
This could be because you hit a bug. It is also possible that this binary
 
or one of the libraries it was linked against is corrupt, improperly built,
 
or misconfigured. This error can also be caused by malfunctioning hardware.
 
 
 
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
 
 
 
We will try our best to scrape up some info that will hopefully help
 
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.
 
 
 
Server version: 10.6.8-MariaDB
 
key_buffer_size=134217728
 
read_buffer_size=131072
 
max_used_connections=61
 
max_threads=153
 
thread_count=48
 
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467959 K  bytes of memory
 
Hope that's ok; if not, decrease some variables in the equation.
 
 
 
Thread pointer: 0x7f42e80008d8
 
Attempting backtrace. You can use the following information to find out
 
where mysqld died. If you see no messages after this, something went
 
terribly wrong...
 
stack_bottom = 0x7f43dc058cc0 thread_stack 0x49000
 
Can't start addr2line
 
/usr/sbin/mariadbd(my_print_stacktrace+0x2e)[0x556c739b2a7e]
 
/usr/sbin/mariadbd(handle_fatal_signal+0x307)[0x556c733fa6f7]
 
/lib64/libpthread.so.0(+0xf630)[0x7f46837bd630]
 
/lib64/libc.so.6(gsignal+0x37)[0x7f4682c08387]
 
/lib64/libc.so.6(abort+0x148)[0x7f4682c09a78]
 
/usr/sbin/mariadbd(+0xe02e10)[0x556c7382ee10]
 
/usr/sbin/mariadbd(+0xe08261)[0x556c73834261]
 
/usr/sbin/mariadbd(+0xe0e415)[0x556c7383a415]
 
/usr/sbin/mariadbd(+0xe21725)[0x556c7384d725]
 
/usr/sbin/mariadbd(+0xe2cac6)[0x556c73858ac6]
 
/usr/sbin/mariadbd(+0xe0ea40)[0x556c7383aa40]
 
/usr/sbin/mariadbd(+0xe21725)[0x556c7384d725]
 
/usr/sbin/mariadbd(+0xe2cac6)[0x556c73858ac6]
 
/usr/sbin/mariadbd(+0xf01969)[0x556c7392d969]
 
/usr/sbin/mariadbd(+0xf050ac)[0x556c739310ac]
 
/usr/sbin/mariadbd(+0xdad6bb)[0x556c737d96bb]
 
/usr/sbin/mariadbd(+0xd5a494)[0x556c73786494]
 
/usr/sbin/mariadbd(+0xddebe2)[0x556c7380abe2]
 
/usr/sbin/mariadbd(+0xcb0c9c)[0x556c736dcc9c]
 
/usr/sbin/mariadbd(_Z17ha_rollback_transP3THDb+0x14f)[0x556c733fe4ef]
 
/usr/sbin/mariadbd(_Z14trans_rollbackP3THD+0x36)[0x556c732e2de6]
 
/usr/sbin/mariadbd(_Z21mysql_execute_commandP3THDb+0x25a3)[0x556c731d7363]
 
/usr/sbin/mariadbd(_Z11mysql_parseP3THDPcjP12Parser_state+0x20b)[0x556c731da5bb]
 
/usr/sbin/mariadbd(_Z16dispatch_command19enum_server_commandP3THDPcjb+0x1217)[0x556c731dc777]
 
/usr/sbin/mariadbd(_Z10do_commandP3THDb+0x123)[0x556c731dde13]
 
/usr/sbin/mariadbd(_Z24do_handle_one_connectionP7CONNECTb+0x187)[0x556c732d39f7]
 
/usr/sbin/mariadbd(handle_one_connection+0x34)[0x556c732d3c94]
 
/usr/sbin/mariadbd(+0xc1270c)[0x556c7363e70c]
 
/lib64/libpthread.so.0(+0x7ea5)[0x7f46837b5ea5]
 
/lib64/libc.so.6(clone+0x6d)[0x7f4682cd0b0d]
 
 
 
Trying to get some variables.
 
Some pointers may be invalid and cause the dump to abort.
 
Query (0x7f42e80106e0): ROLLBACK
 
 
 
Connection ID (thread ID): 382
 
Status: NOT_KILLED
 
 
 
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off
 
 
 
The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mysqld/ contains
 
information that should help you find out what is causing the crash.
 
Writing a core file...
 
Working directory at /var/lib/mysql
 
Resource Limits:
 
Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes     
Max resident set          unlimited            unlimited            bytes     
Max processes             63343                63343                processes 
Max open files            32768                32768                files     
Max locked memory         65536                65536                bytes     
Max address space         unlimited            unlimited            bytes     
Max file locks            unlimited            unlimited            locks     
Max pending signals       63343                63343                signals   
Max msgqueue size         819200               819200               bytes     
Max nice priority         0                    0                    
Max realtime priority     0                    0                    
Max realtime timeout      unlimited            unlimited            us 
Core pattern: core

could you help me out with this?

Comment by Marko Mäkelä [ 2022-08-01 ]

rulotec, we can only help with this bug if someone produces a way of reproducing the error on a database that has been initialized, loading the data with SQL statements only (no copying of data files).

If the affected table contains indexed virtual columns (MDEV-5800) or unique keys on long columns (MDEV-371), there may already exist a separate open bug that explains the corruption.

Comment by Marko Mäkelä [ 2023-02-05 ]

MDEV-30009 is another bug fix in this area.

Comment by Sergei Golubchik [ 2023-03-06 ]

InnoDB change buffer (a possible culprit) was removed in MDEV-29694. Let's close this issue.

If anyone would still experience this bug, please add a comment here and we'll reopen the issue if needed.

Generated at Thu Feb 08 09:18:59 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.