CRM-21835 Gracefully switch Log Table Engines if Archive is not avali…

[seamuslee001]

…able

Overview

Since MariaDB 10.1 The archive engine is not automatically enabled. This can cause problems when enabling detailed logging as it will try to create the tables using the Archive Engine. Some users maybe able to enable the Archive Engine but for others especially on shared hosting this may not be available as an option. So lets gracefully fall over to INNODB.

Before

If you enable logging when the ARCHIVE engine is unavailable, it generates a fatal error.

After

If you enable logging when the ARCHIVE engine is unavailable, it falls back to InnoDB.

Comments

ping @eileenmcnaughton @totten @agileware . This was raised to me by Agileware and i think it makes sense to just gracefully handle it rather than try and get people to install the archive extension. This set up also keeps the status quo of if Archive is available use it.

[jusfreeman]

Thanks @seamuslee001

[totten]

I want to give a general 👍 on policy terms -- i.e. it seems reasonable to me to fallback to InnoDB. However, I haven't done a proper test/review.

Note: In the description, I updated the Before/After blocks to make them clearer.

[totten]

Question: let's say you do some sysadmin (e.g. apt-get dist-upgradeor vi /etc/mysql/my.cnf) with the net-effect of flipping support for ARCHIVE on. Then you go about your merry business (entering contacts, adding custom-groups, enabling new extensions, upgrading to a newer version of Civi, etc). You may eventually get a mix of log tables, where some use InnoDB and others use ARCHIVE. Can you foresee any problems from mixing them?

[seamuslee001]

@totten its a good question it looks like you can use

civicrm-core/api/v3/System.php

Line 399 in ff8784d

function civicrm_api3_system_updatelogtables() {

to then re-set the engine of all log_tables. We could add a status check in if log_tables are INNODB and Archive is avaliable but we may need to have a check if Eileen's extension to convert tables to INNODB is there or maybe there has been a deliberate choice to make them INNODB ?

[eileenmcnaughton]

So

1. no, I don't see any problem with mixing them. I've certainly converted some tables but not others on live sites
2. I think there is a case to say 'if there are some innodb maybe future ones should be innodb' but
3. like I say, I have deliberately run a mix before (to save space on tables I don't care about indexing or more likely because I only got around to converting some... so
4. I think this is fine. I don't think it's worth any additional work to solve an obscure scenario that doesn't seem like a real problem

[eileenmcnaughton]

Ok - I'm going to merge this - I feel it's blocked on @totten acknowledging the response to his comments - but I don't know if that is necessary. The unit test ensures no regression I believe.