Deprecate ARCHIVE format for CiviCRM Database Logging

The ARCHIVE format seemed like a good idea at the time (it takes less space), but my sense is that very few organisations actively involved with CiviCRM choose to use ARCHIVE. I believe the experience of most has been that ARCHIVE storage format is unreliable and the cause of various issues affecting site performance, backup reliability and other issues.

I propose that we switch the default storage format for sites activating Database Logging to the current default for that site's database.

Alternative approach might be to ship nz.co.fuzion.innodbtriggers activated by default on new installs (but this feels like it could add more complexity than just removing the ARCHIVE statements on new logging activation).

"The INNODB format is arguablly a better format for CiviCRM logging. Although INNODB tables take more space, they can be queried much more effectively, which is useful when you want to consult the logs. Consulting the change log for ARCHIVE tables is phohibitivley slow once your logging has been running a while." - Fuzion InnoDB Triggers extension README.

IMO this could be a "missing stair" situation - a known issue to those familiar with CiviCRM, but a gotcha for those unfamiliar, and therefore something which can go unfixed for a long time and has impact primarily on those new to the community/userbase.

Of particular consideration is the risk to sites who would be impacted by InnoDB using more diskspace - we don't want to ship a change which triggers disk outages as ARCHIVE tables are unzipped. I propose that we not do that.

I'm interested to hear from CiviCRM community members who do prefer the ARCHIVE format?

Edited Sep 11, 2020 by eileen

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information