Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 39

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

  1. #11
    Join Date
    Feb 2008
    Location
    Urbana-Champaign, IL
    Posts
    68
    Rep Power
    7

    Default

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

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

  2. #12
    Join Date
    Jul 2010
    Posts
    38
    Rep Power
    5

    Question

    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.

  3. #13
    phoenix is offline Zimbra Consultant & Moderator
    Join Date
    Sep 2005
    Location
    Vannes, France
    Posts
    23,587
    Rep Power
    58

    Default

    Quote Originally Posted by ducommun View Post
    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.
    Regards


    Bill


    Acompli: A new adventure for Co-Founder KevinH.

  4. #14
    Join Date
    Feb 2012
    Location
    Italy
    Posts
    4
    Rep Power
    3

    Default should zimbra make pressure over mysql developers?

    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...

  5. #15
    phoenix is offline Zimbra Consultant & Moderator
    Join Date
    Sep 2005
    Location
    Vannes, France
    Posts
    23,587
    Rep Power
    58

    Default

    Quote Originally Posted by mattia1190 View Post
    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.
    Regards


    Bill


    Acompli: A new adventure for Co-Founder KevinH.

  6. #16
    Join Date
    Jul 2009
    Posts
    69
    Rep Power
    6

    Default

    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 ?

  7. #17
    Join Date
    Oct 2008
    Posts
    38
    Rep Power
    7

    Cool Not really a MySQL bug

    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:
    Code:
    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:
    Code:
    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.
    Last edited by fab; 05-14-2012 at 01:17 AM.

  8. #18
    Join Date
    Feb 2009
    Location
    Singapore
    Posts
    503
    Rep Power
    7

    Default

    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?

  9. #19
    phoenix is offline Zimbra Consultant & Moderator
    Join Date
    Sep 2005
    Location
    Vannes, France
    Posts
    23,587
    Rep Power
    58

    Default

    Quote Originally Posted by bhwong View Post
    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.
    Regards


    Bill


    Acompli: A new adventure for Co-Founder KevinH.

  10. #20
    Join Date
    Feb 2009
    Location
    Singapore
    Posts
    503
    Rep Power
    7

    Default

    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.

Similar Threads

  1. The installer was interrupted...
    By spiderbo in forum Zimbra Connector for Outlook
    Replies: 9
    Last Post: 05-23-2013, 07:33 AM
  2. Error Installing Outlook Connector
    By DanO in forum Zimbra Connector for Outlook
    Replies: 17
    Last Post: 08-28-2007, 10:35 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •