Re: Innodb crash on failed read disk

2005-07-10 Thread Per Andreas Buer
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

2005-07-05 Thread Ady Wicaksono

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

2005-07-04 Thread Ady Wicaksono

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