Rusma, below it crashes because several data pages are corrupt. You can try starting it on level 6 and dump your tables. Then recreate your InnoDB data files and ib_logfiles and import the table dumps. Since the corruption is extensive, you are probably not able to dump all your data, though.
Best regards, Heikki Tuuri Innobase Oy http://www.innodb.com Foreign keys, transactions, and row level locking for MySQL InnoDB Hot Backup - a hot backup tool for InnoDB which also backs up MyISAM tables Order MySQL technical support from https://order.mysql.com/ ----- Original Message ----- From: ""Rusma Mulyadi"" <[EMAIL PROTECTED]> Newsgroups: mailing.database.myodbc Sent: Tuesday, February 03, 2004 1:09 AM Subject: FW: starting a crashed mysqld > ------=_NextPart_000_0006_01C3E9A6.E7140E00 > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > The RAID that we used to hold our mysql data was crashed a few days ago. > > Although it is fine now (after switching to the secondary host = > connector), > we can't seem to start the mysqld. > > We tried to start the server using the various innodb_force_recovery = > options > (1-6) with no luck. > > Below is the error log with the innodb_force_recovery =3D 1. =20 > > =20 > > Any inputs are much appreciated. > > =20 > > Thanks! > > =20 > > 040202 13:27:32 mysqld started > > 040202 13:27:32 InnoDB: Database was not shut down normally. > > InnoDB: Starting recovery from log files... > > InnoDB: Starting log scan based on checkpoint at > > InnoDB: log sequence number 28 1814914366 > > 040202 13:27:33 InnoDB: Starting an apply batch of log records to the > database... > > InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 InnoDB: Database page > corruption on disk or=20 > > a failed > > InnoDB: file read of page 393110. > > InnoDB: You may have to recover from a backup. > > 040202 13:27:33 InnoDB: Page dump in ascii and hex (16384 bytes): > > len 16384; hex 00000000... > > =20 > > =20 > > 8 040202 13:27:33 InnoDB: Page checksum 394994200 stored checksum > 1142435917 > > InnoDB: Page lsn 28 1820582657, low 4 bytes of lsn at page end = > 1820222636 > > InnoDB: Page may be an index page where index id is 0 1660 > > InnoDB: Database page corruption on disk or a failed > > InnoDB: file read of page 393110. > > 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: Look also at section 6.1 of > > InnoDB: http://www.innodb.com/ibman.html about > > InnoDB: forcing recovery. > > 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 InnoDB: = > Database > page corruptio > > n on disk or a failed > > InnoDB: file read of page 698866. > > InnoDB: You may have to recover from a backup. > > 040202 13:27:36 InnoDB: Page dump in ascii and hex (16384 bytes): > > len 16384; hex 0000000000..=20 > > =20 > > 040202 13:28:18 InnoDB: Page checksum 1308210445 stored checksum = > 3312266381 > > InnoDB: Page lsn 28 1674093630, low 4 bytes of lsn at page end = > 1820530832 > > InnoDB: Page may be an index page where index id is 0 1657 > > InnoDB: Database page corruption on disk or a failed > > InnoDB: file read of page 497825. > > 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: Look also at section 6.1 of > > InnoDB: http://www.innodb.com/ibman.html about > > InnoDB: forcing recovery. > > InnoDB: Probable data corruption on page 497825 > > InnoDB: Original record RECORD: info bits 32 0: len 4; hex 42a68d35; asc > B..5;; 1: len 8;=20 > > hex 800000000094ca94; asc ........;; > > InnoDB: on that page. Steps 1. > > InnoDB: Cannot find the dir slot for record RECORD: info bits 32 0: len = > 4; > hex 42a68d35; a > > sc B..5;; 1: len 8; hex 800000000094d149; asc .......I;; > > InnoDB: on that page! > > 040202 13:28:18 InnoDB: Page dump in ascii and hex (16384 bytes): > > len 16384; hex 000000000... > > =20 > > 040202 13:28:18 InnoDB: Page checksum 1308210445 stored checksum = > 3312266381 > > InnoDB: Page lsn 28 1674093630, low 4 bytes of lsn at page end = > 1820530832 > > InnoDB: Page may be an index page where index id is 0 1657 > > 040202 13:28:18 InnoDB: Assertion failure in thread 6 in file = > page0page.c > line 116 > > InnoDB: We intentionally generate a memory trap. > > InnoDB: Send a detailed bug report to [EMAIL PROTECTED] > > mysqld got signal 11; > > This could be because you hit a bug. It is also possible that this = > binary > > or one of the libraries it was linked against is corrupt, improperly = > built, > > or misconfigured. This error can also be caused by malfunctioning = > hardware. > > We will try our best to scrape up some info that will hopefully help > diagnose > > the problem, but since we have already crashed, something is definitely > wrong > > and this may fail. > > =20 > > key_buffer_size=3D8388600 > > read_buffer_size=3D131072 > > 040202 13:28:18 mysqld ended > > > ------=_NextPart_000_0006_01C3E9A6.E7140E00-- > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
