No Server Statistics

[soxfan]

I just realized that since upgrading to version 4.5.6 my Server Statistics page on the Admin console is not getting updated. In searching around the system I found the following in the /tmp/logprocess.out file:

Table './zimbra_logger/mta' is marked as crashed and should be repaired
Table './zimbra_logger/mta' is marked as crashed and should be repaired at /opt/zimbra/libexec/zmlogprocess line 1047.

I'm assuming this is why I'm not getting the stats, but even if it isn't it's probably something that I need to address. How would I go about fixing this table? I'm not too familiar with MySQL database repair so any pointers would be greatly appreciated. I'd also like to know if it's recommended to shutdown Zimbra while doing the repair. Everything else on the system seems to be working fine, so I don't want to take any chances just to get the stats back.

TIA,
John

[jholder]

Try

su - zimbra
logmysql -D zimbra_logger
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Welcome to the MySQL monitor. Commands end with a ; or \g.
Your MySQL connection id is 5
Server version: 5.0.33-log Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> repair table mta;

It should give you some output as to whether it went okay.

Good luck,
john

[soxfan]

Any risk of doing this with Zimbra running or should I shut it down first?

[uxbod]

I have repaired tables dynamically, but do so at your own *** RISK ***. Best way would be to shutdown Zimbra, take a backup, repair table, and then restart Zimbra.

[jholder]

Originally Posted by soxfan

Any risk of doing this with Zimbra running or should I shut it down first?

You have to have logmysql.server running in order to repair the tables.

My suggestion would be to stop zimbra, and run a
logmysql.server start

then repair the tables with only logmysql.server running.

[soxfan]

Well, I finally got a chance to try the repair (weekend - less users on the system, lower email volume, etc.). Unfortunately I didn't have any luck. As suggested, I first shutdown zimbra, and then ran logmysql.server start. Next I executed 'logmysql -D zimbra_logger', which successfully brought up the mysql command prompt, then I ran 'mysql repair mta'. However, it immediately came back and said 'Table is already up to date'. As the command came back so quickly and didn't seem to do anything I was wary and sure enough when I ran 'check table mta' it still shows that the table is 'marked as crashed and should be repaired'. I tried the repair a couple of more times, but always with the same result.

Any other suggestions? I've been Googling around for some general info on repairing MySQL tables, but I'm afraid to try anything that could make things worse. Since this is apparently just a log/stats table I'm willing to wipe it out and start from scratch, but I don't want to do anything that could mess up an otherwise fully functioning Zimbra server.

[soxfan]

Sorry, but I can't let this one drop. Even though everything seems to be running fine besides the stats, I don't like the idea of having a corrupted/crashed database table on the system. I think at this point I could probably drop the table, recreate it, and start from scratch. However, as I said before I don't want to do anything that might mess up something else. Can anyone provide any further help or suggestions?

Thanks again,
John

[ArcaneMagus]

The following page has a few tricks to repair corrupt tables. You might try one of the alternate methods listed here.

[MrZillNet]

I found on 4.5.6 that the reason stats were not being generated was that the rrdtool binaries used to generate the images were not in the right place. I suggest looking thru the cron logs and the stuff in /tmp to see if the cron job is executing.

You can also "su - zimbra" then do "crontab -l" to see all the cron jobs that are executing.

Also, have you tried a full restart of everything, like /etc/init.d zimbra stop followed by start?