1

CiviCRM 4.7.31 (upgrading today) Drupal 7.x

Our log_civicrm_group table crashed and needed repair. We had to run the repair twice from the command line for it to actually work. It's about 850MB large now. When we click the "log" tab on some contact records we're seeing some timeouts or some extremely long load times. It should also be noted we're using a MailChimp extension and there is extensive use of groups.

Does anyone have a suggestion for keeping these log tables at sane sizes (archiving?) or optimizing mysql to present them quicker despite their size?

Thank you for any suggestions. We just enabled the feature and didn't think about what to do after collecting a year of logs.

| improve this question | |
4

If you don't need the logs, you could delete them.

Which engine are your log tables using? There is a useful article by Eileen about ARCHIVE vs INNODB: https://civicrm.org/blog/eileen/who-did-what-when

| improve this answer | |
  • We are using ARCHIVE, but I did not consciously choose that. CiviCRM must set that by default? Thanks for the suggestion. – Zachary Jun 12 '18 at 18:32
  • 3
    ARCHIVE was the old standard. New sites use INNODB but old sites are not automatically changed from ARCHIVE tables. The article shows how you can manually switch over. – Aidan♦ Jun 12 '18 at 19:19
  • any tips on step 3? 3) existing sites can migrate to the new log_conn_id by running an api function (probably by drush or similar) civicrm_api3('System', 'updatelogtables', array()); – Zachary Jun 12 '18 at 21:49
  • 1
    Install this github.com/eileenmcnaughton/nz.co.fuzion.innodbtriggers before running the api function - you can run it through api explorer if you want - or via drush or similar docs.civicrm.org/dev/en/latest/api – user4278 Jun 14 '18 at 5:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.