On 16/11/12 21:44, Marlen Caemmerer wrote:
Now I tried several thing to check which table might
be corrupted.
Innodbchecksum reported everything fine.
Mysqlcheck crashed the mysql daemon when accessing centralauth.localnames.
Oh? Why? Checking the table again crashes mysql. Hm.
Tried a repair table - "storage engine does not support this"...hm.
The log says
InnoDB: Page lsn 268 3672100478, low 4 bytes of lsn at page end 3672100478
InnoDB: Page number (if stored to page already) 192520,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 428
InnoDB: Page may be an index page where index id is 0 1174
InnoDB: (index "PRIMARY" of table
"centralauth"."localnames")
InnoDB: Error in page 192520 of index "PRIMARY" of table
"centralauth"."localnames"
121116 13:02:46 - mysqld got signal 11 ;
I tried to remove the index to rebuild it but this does not work due
to innodb_force_recovery = 3.
You may need to set innodb_force_recovery back to 0 before being able
to drop the index (we got lucky there if it's just the index).
http://dev.mysql.com/doc/refman/5.1/en/forcing-innodb-recovery.html:
The database must not otherwise be used with any
nonzero value of
innodb_force_recovery. As a safety measure, InnoDB prevents users from
performing INSERT, UPDATE, or DELETE operations when
innodb_force_recovery
is greater than 0.
(I would have expected DROP INDEX to work, as DROP or CREATE tables are
allowed in innodb_force_recovery, but seems it's not)
Mysqldump fails - crashes the mysql daemon too.
I expect it only crashes when dumping that table :)
You may be able to get the values out of the table by forcing usage of
the other index (ln_name, ln_wiki). Although it could be safer to get a
new dump for that able from wmf, or a mixture of them (such as getting a
dump at both sides, then rsyncing).