Re: Innodb crash on failed read disk
Ady Wicaksono [EMAIL PROTECTED] writes: Dear All I use RedHat 9 with 2,5 Gbyte RAM, Intel(R) Xeon(TM) CPU 2.80GHz (Hyperthread), filesystem ext3 standar linux journaling filesystem. Today my DB is crash :(, here is the log. Could it be that our stacks and your heaps might have mixed? If your threads allocate to much memory and you have a lot of them this might corrupt your database. -- Per Andreas Buer -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
(More Data) Re: Innodb crash on failed read disk
Seems that i have a bad block :( # badblocks -sv /dev/sda3 Checking for bad blocks in read-only mode From block 0 to 10241437 Checking for bad blocks (read-only test): 102414360/ 10241437 done Pass completed, 1 bad blocks found. Ady Wicaksono wrote: Dear All I use RedHat 9 with 2,5 Gbyte RAM, Intel(R) Xeon(TM) CPU 2.80GHz (Hyperthread), filesystem ext3 standar linux journaling filesystem. Today my DB is crash :(, here is the log. I try to : 1. shutdown MySQL, unmount harddisk partition used by MySQL innodb data file and doing fsck.ext3 on it and found that partition is clean |# fsck.ext3 -v -f /dev/sda3 e2fsck 1.32 (09-Nov-2002) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity /lost+found not found. Createy? yes Pass 4: Checking reference counts Pass 5: Checking group summary information /data1: * FILE SYSTEM WAS MODIFIED * 20 inodes used (0%) 1 non-contiguous inodes (5.0%) # of inodes with ind/dind/tind blocks: 8/8/0 2103570 blocks used (82%) 0 bad blocks 0 large files 8 regular files 2 directories 0 character device files 0 block device files 0 fifos 0 links 0 symbolic links (0 fast symbolic links) 0 sockets 10 files | Any explanation ? |050705 11:19:18 InnoDB: Started; log sequence number 0 4129451638 /usr/sbin/mysqld-max: ready for connections. Version: '4.1.9-Max' socket: '/var/lib/mysql/mysql.sock' port: 3306 Official MySQL RPM InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 18467. InnoDB: You may have to recover from a backup. hexdump ... 050705 11:19:20 InnoDB: Page checksum 1075917609, prior-to-4.0.14-form checksum 3652064195 InnoDB: stored checksum 2099841729, prior-to-4.0.14-form stored checksum 3652064195 InnoDB: Page lsn 0 3887279414, low 4 bytes of lsn at page end 3887279414 InnoDB: Page number (if stored to page already) 18467, 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 310 InnoDB: (index PRIMARY of table sms_9388_telkomsel/t_outgoing_sms) InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 18467. 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 http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html InnoDB: about forcing recovery. InnoDB: Ending processing because of a corrupt database page. Number of processes running now: 0 050705 11:19:20 mysqld restarted | ( -- Regards, Ady Wicaksono HP: +628562208680 -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Innodb crash on failed read disk
Dear All I use RedHat 9 with 2,5 Gbyte RAM, Intel(R) Xeon(TM) CPU 2.80GHz (Hyperthread), filesystem ext3 standar linux journaling filesystem. Today my DB is crash :(, here is the log. I try to : 1. shutdown MySQL, unmount harddisk partition used by MySQL innodb data file and doing fsck.ext3 on it and found that partition is clean |# fsck.ext3 -v -f /dev/sda3 e2fsck 1.32 (09-Nov-2002) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity /lost+found not found. Createy? yes Pass 4: Checking reference counts Pass 5: Checking group summary information /data1: * FILE SYSTEM WAS MODIFIED * 20 inodes used (0%) 1 non-contiguous inodes (5.0%) # of inodes with ind/dind/tind blocks: 8/8/0 2103570 blocks used (82%) 0 bad blocks 0 large files 8 regular files 2 directories 0 character device files 0 block device files 0 fifos 0 links 0 symbolic links (0 fast symbolic links) 0 sockets 10 files | Any explanation ? |050705 11:19:18 InnoDB: Started; log sequence number 0 4129451638 /usr/sbin/mysqld-max: ready for connections. Version: '4.1.9-Max' socket: '/var/lib/mysql/mysql.sock' port: 3306 Official MySQL RPM InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 18467. InnoDB: You may have to recover from a backup. hexdump ... 050705 11:19:20 InnoDB: Page checksum 1075917609, prior-to-4.0.14-form checksum 3652064195 InnoDB: stored checksum 2099841729, prior-to-4.0.14-form stored checksum 3652064195 InnoDB: Page lsn 0 3887279414, low 4 bytes of lsn at page end 3887279414 InnoDB: Page number (if stored to page already) 18467, 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 310 InnoDB: (index PRIMARY of table sms_9388_telkomsel/t_outgoing_sms) InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 18467. 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 http://dev.mysql.com/doc/mysql/en/Forcing_recovery.html InnoDB: about forcing recovery. InnoDB: Ending processing because of a corrupt database page. Number of processes running now: 0 050705 11:19:20 mysqld restarted | -- Regards, Ady Wicaksono HP: +628562208680