[MDEV-12463] Unable to find a record to delete-mark just after upgrading from 10.2.4 to 10.2.5 Created: 2017-04-06  Updated: 2021-09-30  Resolved: 2017-05-05

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

Type: Bug Priority: Critical
Reporter: jocelyn fournier Assignee: Marko Mäkelä
Resolution: Duplicate Votes: 0
Labels: None
Environment:

Debian Jessie


Issue Links:
Duplicate
duplicates MDEV-9663 InnoDB assertion failure: *cursor->in... Closed
Relates
relates to MDEV-11756 Delete-marked records unexpectedly ex... Closed
relates to MDEV-11802 innodb.innodb_bug14676111 fails in bu... Closed

 Description   

Hi!

Just after apt-upgrading from 10.2.4 to 10.2.5, I've got a warning in the log file :

2017-04-06 22:57:16 125067273648000 [Note] Reading of all Master_info entries succeded
2017-04-06 22:57:16 125067273648000 [Note] Added new Master_info '' to hash table
2017-04-06 22:57:16 125067273648000 [Note] /usr/sbin/mysqld: ready for connections.
Version: '10.2.5-MariaDB-10.2.5+maria~jessie'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  mariadb.org binary distribution
2017-04-06 22:57:17 125062776846080 [ERROR] InnoDB: Unable to find a record to delete-mark
InnoDB: tuple DATA TUPLE: 2 fields;
 0: len 8; hex 0000000000053b79; asc       ;y;;
 1: len 29; hex 77707a5f736f6674697a792f77707a5f65777777696f5f696d61676573; asc wpz_softizy/wpz_ewwwio_images;;
 
InnoDB: record PHYSICAL RECORD: n_fields 2; 1-byte offsets; info bits 0
 0: len 8; hex 0000000000053b76; asc       ;v;;
 1: len 23; hex 77707a5f736f6674697a792f77707a5f6f7074696f6e73; asc wpz_softizy/wpz_options;;
2017-04-06 22:57:17 125062776846080 [ERROR] InnoDB: page [page id: space=0, page number=684] (122 records, index id 5).
2017-04-06 22:57:17 125062776846080 [ERROR] InnoDB: Submit a detailed bug report to http://bugs.mysql.com

The definitions of the tables:

CREATE TABLE `wpz_ewwwio_images` (
  `id` int(14) unsigned NOT NULL AUTO_INCREMENT,
  `path` text DEFAULT NULL,
  `image_md5` varchar(55) DEFAULT NULL,
  `results` varchar(75) NOT NULL,
  `gallery` varchar(10) DEFAULT NULL,
  `image_size` int(10) unsigned DEFAULT NULL,
  `orig_size` int(10) unsigned DEFAULT NULL,
  `updates` int(5) unsigned DEFAULT NULL,
  `updated` timestamp NOT NULL DEFAULT '1971-01-01 00:00:00' ON UPDATE current_timestamp(),
  `trace` blob DEFAULT NULL,
  `attachment_id` bigint(20) unsigned DEFAULT NULL,
  `resize` varchar(75) DEFAULT NULL,
  `converted` text NOT NULL,
  `backup` varchar(100) DEFAULT NULL,
  `level` int(5) unsigned DEFAULT NULL,
  `pending` tinyint(1) NOT NULL DEFAULT 0,
  UNIQUE KEY `id` (`id`),
  KEY `path_image_size` (`path`(191),`image_size`),
  KEY `attachment_info` (`gallery`(3),`attachment_id`)
) ENGINE=InnoDB AUTO_INCREMENT=518 DEFAULT CHARSET=utf8mb4
 
CREATE TABLE `wpz_options` (
  `option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `option_name` varchar(191) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `option_value` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
  `autoload` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'yes',
  PRIMARY KEY (`option_id`),
  UNIQUE KEY `option_name` (`option_name`)
) ENGINE=InnoDB AUTO_INCREMENT=174329 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

Let me know if you need more informations.

BR,
Jocelyn Fournier



 Comments   
Comment by jocelyn fournier [ 2017-04-06 ]

BTW, perhaps the "2017-04-06 22:57:17 125062776846080 [ERROR] InnoDB: Submit a detailed bug report to http://bugs.mysql.com" should be changed to jira.mariadb.org

Comment by Elena Stepanova [ 2017-04-23 ]

I've set it to 10.2-ga because it needs to be at least looked at till then. If it turns out to be not a recent regression, the label can be removed.

The part about bugs.mysql.com has been extracted into MDEV-12569.

Comment by Marko Mäkelä [ 2017-04-24 ]

This is a known problem also in Oracle MySQL, since at least MySQL 5.5.
It happened very infrequently, and we did not find out a way to trigger it.
Like I wrote in MDEV-9663 some time ago, I suspect that there could be a bug in the InnoDB change buffering that could cause this. I would suggest one of:

SET GLOBAL innodb_change_buffering=inserts;
SET GLOBAL innodb_change_buffering=none;

and checking if this gets rid of the corruption in the future.
Note that this will not fix already introduced corruption; that you can only fix by DROP INDEX. And unless you found a way to trigger the corruption reasonably often in the first place, it would quite some time to conclude if this really helped.

One more related issue could be MDEV-11802. Why did this not occur before the upgrade? Maybe the purge was somehow stuck, and SHOW ENGINE INNODB STATUS never indicated "History list length 0" before the upgrade. Then, after upgrade, the purge was ‘unstuck’. Maybe just a restart of the same server version would have done it.

Generated at Thu Feb 08 07:57:55 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.