[SOLVED] Error : You can't use locks with log tables (after upgrade to ZCS OSE 7)

[lindsey]

Whether or not it's the right thing to do, this patch fixes things for me.

cd ~zimbra ; patch -p0 < zmdbintegrityreport-hidelockerrors.txt

[ducommun]

mysql.general_log
Error : You can't use locks with log tables.
mysql.slow_log
Error : You can't use locks with log tables.

Same for me!
Is there an official patch?
I'have this message from a long, and just want to repair this properly.
Many thanks and best regards.

[phoenix]

Originally Posted by ducommun

Is there an official patch?

If you read this threa you'll know that ther isn't any 'official' fix for this from Zimbra (if that's what you're asking), it's a bug in MySQL.

[mattia1190]

i understand that this is a bug of MySQL and not of ZCS, but it will be a nice thing that Zimbra will make pressure over MySQL developers to resolve this bug because this type of errors in production environments are so unpleasant...

[phoenix]

Originally Posted by mattia1190

i understand that this is a bug of MySQL and not of ZCS, but it will be a nice thing that Zimbra will make pressure over MySQL developers to resolve this bug because this type of errors in production environments are so unpleasant...

If you read the threads on this topic you'll see that It's already been reported to MySQL and Zimbra has added their comments to that bug report. The MySQL developers, I guess like most open source developers, don't respond to 'pressure' and will fix the bug when they get round to it - perhaps you'd like to send them one.

[dkbk]

Originally Posted by Houston

Upgrade to Zimbra 7 - Table upgrade required

DARIO DALL'OMO: Zimbra - Error MySql Table upgrade required. Please do "REPAIR TABLE xxx" or dump/reload to fix it!

bye

Thanks. However, I'd like to make sure there's be no adverse effects to deleting the offending .frm log files as suggested in those links.

Common sense dictates deleting log files should have no effect (except for the one of loosing the past logs) but my SQL knowledge is null so I'd like to be sure there's no other ill effect involved before going ahead.

Could somebody who has gone ahead please confirm ?

[fab]

I don't see this as a real MySQL bug, it's just a warning message from the MySQL db engine telling that you can't lock a table whose type (engine) is CSV. I guess Zimbra should either filter the output of zmdbintegrityreport or avoid checking those tables; another viable solution is to remove at all those tables because ZCS doesn't need them (see below to understand why).

Both general_log and slow_log are CSV-type tables created by default in every MySQL installation into the 'mysql' database but they are used only if you configure MySQL to log into its own database: in this case the error log should end up in general_log and the slow queries in slow_log.

BTW, when MySQL is left at its default settings it logs in the usual, standard text log files and even the MySQL instance used by ZCS logs in such files, indeed in /opt/zimbra/conf/my.cnf we have:

slow_query_log_file = /opt/zimbra/log/myslow.log
err-log = /opt/zimbra/log/mysqld.log

Moreover, notice that .frm files are used to store the table's structure for whatever table type you use (MyISAM, InnoDB, CSV), thus removing the .frm file it's like removing the whole table because you no longer see its data even if you leave the other files in place (the .CSV and .CSM files in this case).

My conclusion is that you may safely remove both tables by using this simple command after you have stopped all ZCS services:

cd /opt/zimbra/db/data/mysql ; rm -f general_log.* slow_log.*

I have deleted them on our ZCS 7.1.4 servers and we didn't experience any problem.

[bhwong]

It will be good if Zimbra could provide an official workaround over it's problematic components, even if it's provided by 3rd party, since customers is paying for the whole package.

I think this is a serious issue for Zimbra growth in the future if 3rd party component ever breakdown Zimbra. Zimbra and 3rd party might just end up pushing responsibility with one another, leaving customers in deep shit?

[phoenix]

Originally Posted by bhwong

Zimbra and 3rd party might just end up pushing responsibility with one another, leaving customers in deep shit?

That is a silly comment, the bug has been acknowledged by MySQL and is in their bug tracking system - add your comments to that bug report (mentioned in post #2) and get MySQL to fix the problem.

[bhwong]

It's not silly at all. What if MySQL has a critical bug that broke Zimbra. Will Zimbra insists that it's not Zimbra bug and leave it to MySQL developers to fix it while leaving Zimbra customers in deep shit?

Just like previously when ClamAV broke Zimbra, Zimbra was responsible enough to release a patch quickly within the next working day to fix it without pointing finger and wait for ClamAV developers to fix it.

Since Zimbra decided to use MySQL as it's main component, then Zimbra has the responsibility to ensure that it works with Zimbra right? For open source, you may still have a ground to argue this, but not for paid version.