Errors mysql After Upgrade to 8.7

[matrixsup]

1.Seeing Some Errors in /opt.zimbra/log/mysql_error.log as follows.

InnoDB: Error: Fetch of persistent statistics requested for table "mboxgroup62"."mail_item" but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

The Objects within Mboxgroup being tag/mail_items etc,

2. InnoDB: Error: Column last_update in table "mysql"."innodb_table_stats" is INT UNSIGNED NOT NULL but should be BINARY(4) NOT NULL (type mismatch).

Can any onehelp me understand if any issue & how to fix .All Email Operations Working Fine.

[racerock]

Same issue here on all my 8.6_1200 to 8.7 upgrades the pre-database check prior to upgrade reports its clean,however, Once the upgrade is completed everything appears to function correctly, but I find similar errors, being endlessly reported in the /opt/zimbra/log/mysql_error.log..
EG:
7fb6b59f1b00 InnoDB: Error: Column last_update in table "mysql"."innodb_table_stats" is INT UNSIGNED NOT NULL but should be BINARY(4) NOT NULL (type mismatch).

7fb6b59f1b00 InnoDB: Error: Fetch of persistent statistics requested for table "mboxgroup18"."tag" but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

7fb6b59f1b00 InnoDB: Error: Fetch of persistent statistics requested for table "mboxgroup11"."tombstone" but the required system tables mysql.innodb_table_stats and mysql.innodb_index_stats are not present or have unexpected structure. Using transient stats instead.

etc.. etc ..

[hmmblah]

Same thing here. My stat graphs also show "No Data Available" in the admin console.

[cerri]

I can confirm the problem, on 3 installations upgraded from 8.6 (last patchlevel).

[mefistoteles]

Hi

This behavior is caused by bug in Zimbra installation script which doesn't perform mysql_upgrade during Zimbra upgrade process.

Resolution:

1. Obtain mysql root password:
$ zmlocalconfig -s | grep mysql | grep password

2. Create missing directory and symbolic link:
$ mkdir /opt/zimbra/data/tmp/mysqldata
$ ln -s /opt/zimbra/data/tmp/mysql/mysql.sock /opt/zimbra/data/tmp/mysqldata/mysql.sock

3. Perform mysql_upgrade
$ /opt/zimbra/common/bin/mysql_upgrade -u root -p

That's it

Cheers,

mefistoteles

[racerock]

I confirm after taking the steps described above by mefistoteles the mysql_error.log no longer reports any errors and everything appears to function normally


Many Thanks

[zmbr16]

Thank you mefistoteles,

I confirm too, after executing the given commands sequence, I no longer see those errors in my /opt/zimbra/log/mysql_error.log.

[msquadrat]

Many thanks as well for the workaround. I opened a pull request to have this [bug]107976[/bug] fixed, hopefully in the next release: https://github.com/Zimbra/zm-build/pull/23

[Himanshu_N]

Seems I have landed Up in same issue. But When Trying to run /opt/zimbra/common/bin/mysql_upgrade -u root -p

I am getting Following issue.

Phase 3/6: Running 'mysql_fix_privilege_tables'
ERROR 1050 (42S01) at line 586: Table './mysql/#sql2-13e1-27d1' already exists

Release 8.7.1_GA_1670.RHEL7_64_20161025045328 RHEL7_64 FOSS edition.

Looking for Help.

[Himanshu_N]

Ok. I this thing Done after bit of struggle.
It had Two issues.

1.Had to Increase innodb_force_recovery (in my.cnf) upto 5 in a step by step manner.
2.mysql -u root --password=$mysql_root_password
3.USE mboxgroup9; ( Database which reported Tabel as Corrupt)
4.OPTIMIZE TABLE open_conversation;
5.Repeated for all such tables which were reported as corrupt in
/opt/zimbra/libexec/zmdbintegrityreport -r
And Finally Applied Upgrade
6./opt/zimbra/common/bin/mysql_upgrade -u root -p
7.And Upgrade to 8.7.xx was Successful.

Above Issue of open_Conversation was resulting in Mobile Client Unable to Sync using Imap & Slowed Performance .