Am 28.01.2013 16:18, schrieb Andrew Moore: > 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... >
to be fair, my main concern is to understand what is going on. Last time we had this in production, we loaded the back but it takes some serious time. This time i hoped to find a faster solution. What exactly belongs to the innodb-side of a database (beside the tables) only they ibdata1-file or is there more ? re, wh > > 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 >> >> > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
