Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Duplicate
-
10.2.5
-
None
-
Debian Jessie
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
Attachments
Issue Links
- duplicates
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
Activity
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.
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.
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