So this isn't production - well just rebuild it from a backup? It's a pain in the rear to get the lsn aligned again through data creation/removal but if it's a system critical instance without possible downtime you've got some work to do...
On Mon, Jan 28, 2013 at 2:21 PM, walter harms <wha...@bfs.de> wrote: > > > Am 28.01.2013 15:01, schrieb Manuel Arostegui: > > 2013/1/28 walter harms <wha...@bfs.de> > > > >> 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 ? > >> > >> > >> > > Hello, > > > > I reckon you really need to think of what caused your MySQL to crash. If > > there's not a clear reason (HW problem) you might want to dig into that > to > > prevent this happening again. I am saying this because it is not the > first > > time I see someone fixing a corruption (re-building the database or > fixing > > corrupted tables) and then getting it corrupted again within some hours. > > > very simple: power outage > Our Production server are on UPS but i was making tests on this one and to > be > fair power outages are very seldom > > > The problem itself has a solution: increasing the log sequence counter. I > > wouldn't do it if it's not totally necessary (ie: you don't have another > > machine to copy the data from). If you can get the data copied again from > > some other server, that is probably the safest solution here to make sure > > your data isn't corrupted. If not, I would suggest to run > pt-table-checksum > > to make sure the data is okay. Once your DB is recovered from this crash. > > > > pt-table-checksum means this tool ? [ > http://www.percona.com/doc/percona-toolkit/2.1/pt-table-checksum.html] > I would need to run it once, from the description i had the impression it > is > intended for monitoring. Could you please explain ? > > re, > wh > > > Cheers > > Manuel. > > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql > >
