[MDEV-21726] Index corruption after 10.4 upgrade Created: 2020-02-13  Updated: 2020-03-12  Resolved: 2020-03-12

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.4.12
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: O Assignee: Unassigned
Resolution: Incomplete Votes: 0
Labels: corruption, need_feedback, regression
Environment:

Debian buster

Issue Links:
Relates
relates to MDEV-9663 InnoDB assertion failure: *cursor->in... Closed

 Description   

Hi,

done an upgrade of MariaDB Server from 10.3.21 to 10.4.12, and encountered the following errors after replication process restarted:

2020-02-10 16:00:27 4 [ERROR] InnoDB: Unable to find a record to delete-mark
InnoDB: tuple DATA TUPLE: 3 fields;
0: len 32; hex 6464343936316561363264373763666362663630663635396563323231343463; asc dd4961ea62d77cfcbf60f659ec22144c;;
1: len 4; hex 00b2d13e; asc >;;
2: len 4; hex 00662119; asc f! ;;

InnoDB: record PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 30; hex 646434393565626136316631333938666539313237383038626463633031; asc dd495eba61f1398fe9127808bdcc01; (total 32 bytes);
1: len 4; hex 00e4975d; asc ];;
2: len 4; hex 00564157; asc VAW;;
2020-02-10 16:00:27 4 [ERROR] InnoDB: page [page id: space=2383, page number=2684675] (304 records, index id 4183).
2020-02-10 16:00:27 4 [ERROR] InnoDB: Submit a detailed bug report to https://jira.mariadb.org/

Actually, a workaround is to optimize all tables on all schemas between (10.3 restore and 10.4 upgrade process) and (replication restart, or any other first transaction after restart of the instance)

First time having this strange behaviour after doing lots of server migrations, case reproduced on others servers with the same OS and DB setup

Thanks
Emmanuel

 Comments   
Comment by Marko Mäkelä [ 2020-02-13 ]

This type of corruption was originally reported in MDEV-9663. Some causes of it have been fixed, but I suspect that there could be a problem related to the InnoDB adaptive hash index (MDEV-20487, MDEV-20203) or possibly change buffering. If either of these guesses are correct, you could prevent further corruption by the following:

SET GLOBAL innodb_change_buffering=inserts;
 
SET GLOBAL innodb_adaptive_hash_index=OFF;

Note: This does not look like the MDEV-19916 corruption that was originally introduced in 10.3.

We have been unable to reproduce this type of errors, despite significant efforts in the past. A copy of a corrupted data directory would likely not help analyze it; we’d need a complete stream of SQL statements that would create and populate all tables and reproduce the error with some reasonable probability.

Comment by O [ 2020-02-13 ]

Thanks Marko for your quick answer, i'm taking a look to this new setup and trying to reproduce (or not) this bug

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