Repair Logger Data Corruption
|This article applies to the following ZCS versions.|
Frequent write activity on the zimbra_logger.raw_logs table cause it to be subject to index corruption under certain conditions. Those conditions include but may not be limited to 100% disk utilization, abrupt end to the MySQL logger process, or other system failure. If the logger database is experiencing corruption, the raw_logs table is the likely culprit, however other tables can be affected as well. Trouble with the logger database is reported in /opt/zimbra/logger/db/data/hostname.err.
This error is especially common in Zimbra releases prior to 4.5.7, in which an error in a maintenance script could cause the zmlogswatch script to show itself as down when in fact it was still running. An administrator would see the logger as failed and would restart it, which would result in two or more instances of the zmlogswatch script running. Both of these instances would write to the same table in the logger database, causing this error. If this error is happening frequently, an upgrade to the current release is recommended.
Any data or index corruption on the logger DB will result in inaccurate or missing statistics.
Diagnose problematic table in hostname.err
070927 14:30:01 [ERROR] /opt/zimbra/logger/mysql/libexec/mysqld: Table './zimbra_logger/raw_logs' is marked as crashed and last (automatic?) repair failed
Attempt table repair
$ logmysql zimbra_logger mysql> REPAIR TABLE raw_logs;
If this repair step succeeds, you do not need to perform the next step.
Repair table by writing a new index file
This repair method creates a new .MYI index file using the .frm file for the table. Use this option only as a last resort.
mysql> REPAIR TABLE raw_logs USE_FRM;
MySQL 5.0 Reference Manual http://dev.mysql.com/doc/refman/5.0/en/repair-table.html
Keywords: logger, database, mysql, error, raw_logs, corrupt, index