Just wanted to upgrade a Zimbra server from 8.7.3 to 8.7.5. The upgrade always asks you whether to check database integrity. Even it was only a minor upgrade, I chose yes to be on the safe side. And it turned out the MySQL DB was indeed corrupt.

I had seen corrupt zimbra dbs a lot and the “MySQL crash recovery” guide in the zimbra wiki always helped out. But not this time.

I tried the crash recovery as explained in the wiki. When doing dumps, four mboxgroup-databases always failed because the index open_conversation of the table open_conversation was corrupt. As the guide explains, I increased innodb_force_recovery step by step from 1 to the maximum 6, but the error did not go away.

So here is what helped:

1. Try to create the dumps as explained in the crash recovery guide. You will get errors like this:

   Dumped mboxgroup8
   mysqldump: Error 1712: Index open_conversation is corrupted when dumping table `open_conversation` at row: 0
   Dumped mboxgroup9

   This means that mboxgroup9 (not 8!) is corrupt. Write down all the mboxgroup numbers where an error appeared.

2. Remove  innodb_force_recovery from the my.cnf if you inserted it
3. Login as zimbra

   su zimbra

4. Restart the mysql server

   mysql.server restart

5. Load the MySQL account data into shell variables

   source ~/bin/zmshutil ; zmsetvars

6. Log into MySQL using the root account

   mysql -u root --password=$mysql_root_password

7. Open the first database that is corrupt:

   USE mboxgroup9;

8. Repair the corrupt open_converstation table:

   OPTIMIZE TABLE open_conversation;

   Note: If this fails, check if you really removed innodb_force_recovery from the my.cnf!

9. Go back to step 7 and open the next database that is corrupt until all have been repaired.
   Now exit the MySQL prompt:

   exit;

10. You can now continue with the crash recovery, it should now create all dumps correctly. But if the open_conversation tables where the only corruption problem, you could also just stop here as this should have fixed the corruption. In my case, I jus started the upgrade again and let it verify message store database integrity again, and this time it completed with “No errors found”. 🙂
11. Clean up the MySQL dumps

     rm -R /tmp/mysql.db.list /tmp/mysql.sql/

Please let me know if this helped you or if you have some additions.