Hi there
I do a dump of mysql installation on the hour as an interim backup solution. However the mysqldump manages to crash mysqld every now and again. It happens intermittently but quite regularly.
The cause are always the index pages of one of two innodb tables - both with the same design. The tables each contains a million rows that are used to create random one time passwords. It is two columns: an unsigned auto increment id as primary key and a zerofill int code. (see full table description below)
The mysql error file reports a database page corruption on the primary index of the table (full error below).
A CHECK TABLE always returns with OK.
The mysql version is 5.0.51a-log and OS is SUSE10.2.
Any ideas as to why this happens or how to rectify?
Thanks in advance.
The table structure:
CREATE TABLE `digit7_available_code` (
`id` int(10) unsigned NOT NULL auto_increment,
`code` int(7) unsigned zerofill default NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `code` (`code`)
) ENGINE=InnoDB AUTO_INCREMENT=1000044 DEFAULT CHARSET=latin1
An example of data in the table:
mysql> select * from digit7_available_code limit 10;
+--------+---------+
| id | code |
+--------+---------+
| 358009 | 0000001 |
| 772092 | 0000002 |
| 129169 | 0000016 |
| 141522 | 0000032 |
| 985315 | 0000035 |
| 366162 | 0000042 |
| 157246 | 0000058 |
| 369531 | 0000059 |
| 11888 | 0000068 |
| 276710 | 0000071 |
+--------+---------+
The mysql error logs:
Version: '5.0.51a-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 9864.
InnoDB: You may have to recover from a backup.
100530 19:31:02 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex af370a660000268800000dcc000003f5000000002867f9ab45bf00000000000000000000000000503eb28250172b0f8117100005000001bb000000000000000000000000000000000c2700000000000001dd363200000000000001dd3572010002001b696e66696d756d0005000b000073757072656d756d00000010001b000e0f1b0000009d0bad8000000e9039fe000846bf0000001814ac000e0f1c0000009d0bae80000020............etc....etc......
......... % W < ; c G o0{ p #g 3T ' O < w: k i 3 + [9 + 5 & <0 Q ?2+' g "# ! #
R K s 1 7 .z / ; 8 W ! 7q 9!)j4 ;6 ; c (g ;InnoDB: End of page dump
100530 19:31:02 InnoDB: Page checksum 2449731046, prior-to-4.0.14-form checksum 2961241874
InnoDB: stored checksum 2939619942, prior-to-4.0.14-form stored checksum 2961241874
InnoDB: Page lsn 0 677902763, low 4 bytes of lsn at page end 677902763
InnoDB: Page number (if stored to page already) 9864,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 0 3111
InnoDB: (index PRIMARY of table witcm1/digit7_available_code)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 9864.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
Number of processes running now: 0
100530 19:31:02 mysqld restarted
InnoDB: Log scan progressed past the checkpoint lsn 0 685673085
100530 19:31:02 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
....and then crash recovery brings mysqld up.
I do a dump of mysql installation on the hour as an interim backup solution. However the mysqldump manages to crash mysqld every now and again. It happens intermittently but quite regularly.
The cause are always the index pages of one of two innodb tables - both with the same design. The tables each contains a million rows that are used to create random one time passwords. It is two columns: an unsigned auto increment id as primary key and a zerofill int code. (see full table description below)
The mysql error file reports a database page corruption on the primary index of the table (full error below).
A CHECK TABLE always returns with OK.
The mysql version is 5.0.51a-log and OS is SUSE10.2.
Any ideas as to why this happens or how to rectify?
Thanks in advance.
The table structure:
CREATE TABLE `digit7_available_code` (
`id` int(10) unsigned NOT NULL auto_increment,
`code` int(7) unsigned zerofill default NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `code` (`code`)
) ENGINE=InnoDB AUTO_INCREMENT=1000044 DEFAULT CHARSET=latin1
An example of data in the table:
mysql> select * from digit7_available_code limit 10;
+--------+---------+
| id | code |
+--------+---------+
| 358009 | 0000001 |
| 772092 | 0000002 |
| 129169 | 0000016 |
| 141522 | 0000032 |
| 985315 | 0000035 |
| 366162 | 0000042 |
| 157246 | 0000058 |
| 369531 | 0000059 |
| 11888 | 0000068 |
| 276710 | 0000071 |
+--------+---------+
The mysql error logs:
Version: '5.0.51a-log' socket: '/tmp/mysql.sock' port: 3306 MySQL Community Server (GPL)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 9864.
InnoDB: You may have to recover from a backup.
100530 19:31:02 InnoDB: Page dump in ascii and hex (16384 bytes):
len 16384; hex af370a660000268800000dcc000003f5000000002867f9ab45bf00000000000000000000000000503eb28250172b0f8117100005000001bb000000000000000000000000000000000c2700000000000001dd363200000000000001dd3572010002001b696e66696d756d0005000b000073757072656d756d00000010001b000e0f1b0000009d0bad8000000e9039fe000846bf0000001814ac000e0f1c0000009d0bae80000020............etc....etc......
......... % W < ; c G o0{ p #g 3T ' O < w: k i 3 + [9 + 5 & <0 Q ?2+' g "# ! #
R K s 1 7 .z / ; 8 W ! 7q 9!)j4 ;6 ; c (g ;InnoDB: End of page dump
100530 19:31:02 InnoDB: Page checksum 2449731046, prior-to-4.0.14-form checksum 2961241874
InnoDB: stored checksum 2939619942, prior-to-4.0.14-form stored checksum 2961241874
InnoDB: Page lsn 0 677902763, low 4 bytes of lsn at page end 677902763
InnoDB: Page number (if stored to page already) 9864,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 0
InnoDB: Page may be an index page where index id is 0 3111
InnoDB: (index PRIMARY of table witcm1/digit7_available_code)
InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 9864.
InnoDB: You may have to recover from a backup.
InnoDB: It is also possible that your operating
InnoDB: system has corrupted its own file cache
InnoDB: and rebooting your computer removes the
InnoDB: error.
InnoDB: If the corrupt page is an index page
InnoDB: you can also try to fix the corruption
InnoDB: by dumping, dropping, and reimporting
InnoDB: the corrupt table. You can use CHECK
InnoDB: TABLE to scan your table for corruption.
InnoDB: See also InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html
InnoDB: about forcing recovery.
InnoDB: Ending processing because of a corrupt database page.
Number of processes running now: 0
100530 19:31:02 mysqld restarted
InnoDB: Log scan progressed past the checkpoint lsn 0 685673085
100530 19:31:02 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
....and then crash recovery brings mysqld up.