|This article applies to the following ZCS versions.|
Hardware and Operating System
As noted in the ZCS Administration Guide , zmdbintegrityreport is a crontab task that runs once a week, to check the MySQL database for corruption. zmdbintegrityreport essentially is a wrapper for mysqlcheck, a standard MySQL tool that is distributed with the MySQL package.
zmdbintegrityreport is run weekly to check the MySQL database for corruption and will notify the administrator if any corruption is found. When this is run, it may consume a significant amount of I/O. If you find that it is an issue, you may want to change the frequency with which zmdbintegrityreport is run by editing the ZCS crontab entry.
zmdbintegrityreport should be run by the user "zimbra". zmdbintegrityreport can be run with the following options:
Usage: /opt/zimbra/libexec/zmdbintegrityreport [-m] [-v] [-h] [-r] -m emails report to admin account, otherwise report is presented on stdout -v verbose output -r attempt auto repair of tables -h help
The default crontab entry is the following, running at 11pm on Sunday evenings:
0 23 * * 7 /opt/zimbra/libexec/zmdbintegrityreport -m
zmdbintegrityreport is just a wrapper for mysqlcheck, a standard MySQL database tool. The mysqlcheck in zmdbintegrityreport runs this command by default:
/opt/zimbra/mysql/bin/mysqlcheck --defaults-file=/opt/zimbra/conf/my.cnf -S /opt/zimbra/db/mysql.sock -A -C -s -u root --password=xxxxxxxxxxxxxxxxxxxxxxxxxx
zmdbintegrityreport just runs a standard mysqlcheck. There are options to mysqlcheck that allow more extensive checks, such as "-m" and "-e". The standard check puts a lower load on the MySQL database, and requires less time. However, a more extensive check can be used to perform a row-by-row table analysis:
-m, --medium-check Faster than extended-check, but only finds 99.99 percent of all errors. Should be good enough for most cases. -e, --extended If you are using this option with CHECK TABLE, it will ensure that the table is 100 percent consistent, but will take a long time. If you are using this option with REPAIR TABLE, it will force using old slow repair with keycache method, instead of much faster repair by sorting.
zmdbintegrityreport (mysqlcheck) does put load on the MySQL database, which in turn can cause higher latency and slower performance from mailboxd. It runs by default late on Sunday nights in order to limit impact to users. It is important to confirm it is completing by the time of peak load - if it is not, the crontab entry can be adjusted to use a different time (note: check cron entries again after every upgrade).
If choosing to disable zmdbintegrityreport altogether, Zimbra would recommend running zmdbintegrityreport manually regularly in order to check the database integrity.
Sites may opt to disable this by setting the following:
zmlocalconfig -e zmdbintegrityreport_disabled=TRUE
If you choose to disable this, it is recommended that the integrity report be run by hand during the normal maintenance windows and prior to running any ZCS upgrades.
Your mileage may vary, but an example time is provided here. For reference, the database size of this server is:
# du -sh /opt/zimbra/db/data 46G /opt/zimbra/db/data
For this database, it takes approximately 45 minutes to run.
$ time /opt/zimbra/libexec/zmdbintegrityreport -v real 45m36.724s user 0m0.082s sys 0m0.035s
Note too that the default zmdbintegrityreport uses -C:
• --check-only-changed, -C Check only tables that have changed since the last check or that have not been closed properly.
This would indicate that running it more often would likely reduce the run time of each execution.
Error About "You can't use locks with log tables"
This is a bug from MySQL and it has already been filed and confirm by Zimbra. It is a harmless error and can be ignored if your report ONLY lists references to the lock issue, for example:
Running /opt/zimbra/libexec/zmdbintegrityreport display the following Database errors found. /opt/zimbra/mysql/bin/mysqlcheck --defaults-file=/opt/zimbra/conf/my.cnf -S /opt/zimbra/db/mysql.sock -A -C -s -u root --password=XXXXXXXX mysql.general_log Error : You can't use locks with log tables. mysql.slow_log Error : You can't use locks with log tables.
If there was anything else wrong with your db, it would have other references besides the "You can't use locks with log tables."
Zimbra bug reference :
MySQL bug reference :