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).