I'm seeing a crash on one of my InnoDB tables that indicates there's a bad table index (or something like that). I haven't been able to find much about my error online, but the little I see indicates I could simply delete the rows that are corrupted (I am fine losing that data) and I might be ok after that. The table in question is about 14GB of data right now (255 million rows, give or take). I'm running an optimze table right now, but I suspect that's going to take another 10 or 12 hours to complete. In the mean time, is there a way to figure out which row(s) are associated with a specific "table page"? Note line 643 of the error log below, "InnoDB: file read of page 2275584" seems to be what's fundamentally failed.
623 100628 11:19:16 mysqld restarted 624 100628 11:19:16 [Warning] The syntax for replication startup options is deprecated and will be removed in MySQL 5.2. Please use 'CHANGE MASTER' instead. 625 InnoDB: Log scan progressed past the checkpoint lsn 23 793930116 626 100628 11:19:16 InnoDB: Database was not shut down normally! 627 InnoDB: Starting crash recovery. 628 InnoDB: Reading tablespace information from the .ibd files... 629 InnoDB: Restoring possible half-written data pages from the doublewrite 630 InnoDB: buffer... 631 InnoDB: Doing recovery: scanned up to log sequence number 23 793949349 632 100628 11:19:16 InnoDB: Starting an apply batch of log records to the database... 633 InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 634 InnoDB: Apply batch completed 635 InnoDB: Last MySQL binlog file position 0 36488, file name /var/log/mysql/mysql-bin.000120 636 100628 11:19:17 InnoDB: Started; log sequence number 23 793949349 637 100628 11:19:17 [Note] Recovering after a crash using /var/log/mysql/mysql-bin 638 100628 11:19:17 [Note] Starting crash recovery... 639 100628 11:19:17 [Note] Crash recovery finished. 640 100628 11:19:17 [Note] /usr/libexec/mysqld: ready for connections. 641 Version: '5.0.88-log' socket: '/var/lib/mysql/mysql.sock' port: 3306 Source distribution 642 InnoDB: Database page corruption on disk or a failed 643 InnoDB: file read of page 2276684. 644 InnoDB: You may have to recover from a backup. 645 100628 11:19:35 InnoDB: Page dump in ascii and hex (16384 bytes): 646 len 16384; hex c2ff848c0022bd4c0022bd4b0022bd4d000000166f2594c245bf00000000000000000000000200433b40810a00000000000000020107010800000000000000000000000000000000001000000000000 647 100628 11:19:35 InnoDB: Page checksum 3570692139, prior-to-4.0.14-form checksum 3368067420 648 InnoDB: stored checksum 3271525516, prior-to-4.0.14-form stored checksum 3368067420 649 InnoDB: Page lsn 22 1864733890, low 4 bytes of lsn at page end 1864733890 650 InnoDB: Page number (if stored to page already) 2276684, 651 InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 2 652 InnoDB: Page may be an index page where index id is 0 16 653 InnoDB: (index PRIMARY of table database/measurements) 654 InnoDB: Database page corruption on disk or a failed 655 InnoDB: file read of page 2276684.656 InnoDB: You may have to recover from a backup. 657 InnoDB: It is also possible that your operating 658 InnoDB: system has corrupted its own file cache 659 InnoDB: and rebooting your computer removes the 660 InnoDB: error. 661 InnoDB: If the corrupt page is an index page 662 InnoDB: you can also try to fix the corruption 663 InnoDB: by dumping, dropping, and reimporting 664 InnoDB: the corrupt table. You can use CHECK 665 InnoDB: TABLE to scan your table for corruption. 666 InnoDB: See also InnoDB: http://dev.mysql.com/doc/refman/5.0/en/forcing-recovery.html 667 InnoDB: about forcing recovery. 668 InnoDB: Ending processing because of a corrupt database page. 669 670 Number of processes running now: 0