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
