Zmdbintegrityreport: Difference between revisions

No edit summary
No edit summary
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Article Infobox|{{admin}}|{{ZCS 7.0}}|{{ZCS 6.0}}|{{ZCS 5.0}}}}=Hardware and Operating System=
{{BC|Certified}}
 
__FORCETOC__
 
<div class="col-md-12 ibox-content">
= zmdbintegrityreport =
=Zmdbintegrityreport=
 
{{KB|{{ZC}}|{{ZCS 7.0}}|{{ZCS 6.0}}|}}
{{WIP}}
== Description ==
== Description ==


Line 94: Line 95:


This would indicate that running it more often would likely reduce the run time of each execution.
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:
<pre>
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.
</pre>
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 :
* http://bugzilla.zimbra.com/show_bug.cgi?id=50272
MySQL bug reference :
* http://bugs.mysql.com/bug.php?id=43829
* http://bugs.mysql.com/bug.php?id=30487
== Error About "Table upgrade required. Please do "REPAIR TABLE " ==
Please consult the Release Notes for the ZCS version that you most likely upgraded to. It will probably have a reference in the "After the upgrade is complete" section about needing to run a script to upgrade the db. Something like :
  /opt/zimbra/libexec/scripts/migrate20100913-Mysql51.pl
'''NOTE''' : Don't just run the above script, it's an example. Consult the specific Release Notes for the version you upgraded to.

Latest revision as of 02:33, 11 July 2015

Zmdbintegrityreport

   KB 15369        Last updated on 2015-07-11  




0.00
(0 votes)

Description

As noted in the ZCS Administration Guide [1], 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.

Usage

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

Crontab entry

The default crontab entry is the following, running at 11pm on Sunday evenings:

0 23 * * 7 /opt/zimbra/libexec/zmdbintegrityreport -m

mysqlcheck

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.

Database Load

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.

Configuration

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.

Timing

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 :

Error About "Table upgrade required. Please do "REPAIR TABLE "

Please consult the Release Notes for the ZCS version that you most likely upgraded to. It will probably have a reference in the "After the upgrade is complete" section about needing to run a script to upgrade the db. Something like :

 /opt/zimbra/libexec/scripts/migrate20100913-Mysql51.pl

NOTE : Don't just run the above script, it's an example. Consult the specific Release Notes for the version you upgraded to.

Jump to: navigation, search