On Sun, Feb 3, 2013 at 7:23 AM, walter harms <wha...@bfs.de> wrote: > > > Am 02.02.2013 01:34, schrieb Larry Martell: >> On Mon, Jan 28, 2013 at 5:01 AM, walter harms <wha...@bfs.de> wrote: >>> hi list, >>> >>> i am using mysql 5.1.53. >>> after a crash i have the follwing error in my log: >>> >>> 130128 10:45:25 InnoDB: Error: page 61 log sequence number 0 2871649158 >>> InnoDB: is in the future! Current system log sequence number 0 2494349480. >>> InnoDB: Your database may be corrupt or you may have copied the InnoDB >>> InnoDB: tablespace but not the InnoDB log files. See >>> InnoDB: http://dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html >>> InnoDB: for more information. >>> >>> according to the doc's at >>> http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html >>> I need to restore the database from scratch (short version). What i do not >>> understand is what >>> exactly is broken ? Whole DBM ? One Instance ? (mysqlcheck says all tables >>> are ok). >>> >>> Not all tables are INNODB. Is is possible to restore only immodb tables ? >>> (Having fun with forgein keys) >>> >>> Or is there a better way to handle this ? >> >> >> We had the same thing happen to us today. We had a power hit and when >> the server came back we got the log sequences numbers in the future >> message. We were able to dump the >> affected tables, but when we tried to restore them we were not able to >> drop the old tables. When we tried the server crashed with: >> >> InnoDB: Failing assertion not_full_n_used >= descr_n_used >> >> We did try booting with innodb_force_recovery at all levels from 1 to >> 6 with the same results. >> >> We still have not figured out what to do. Pretty big disaster. >> > > Yep, a serious problem. > I tried several thinks that came to my mind but this was all useless > i had to drop the database and manualy rm ib_datalog0/1 (?). > > Did you already got the funny errormsg about rawpartions ? > > I must admit that we made several test before using innodb but we > never had such problem, actualy we are happy with that but that > kind of problems cost me three days of backup replay.
We also ended up dropping the database and restoring from dumps. However all recent dumps ended up having a similar corruption and we were still getting the same errors. We had to go back to an October dump before it would come up cleanly. And our db is fairly large, and it takes around 4 hours to load a dump. We were working on this Friday from 8:30 AM until 4AM Saturday before we got it going. And now we're trying to recall all the alters we did since then, and reload all the data since then, most of which is in files we can import. The only thing we don't have is the manual updates done. All in all a total disaster and something that will make us rethink our procedures. Perhaps we'll look at replication, although I don't know if that would have helped in this case. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
