Fresh cPanel w/ MariaDB: innodb_checksum_algorithm = strict_crc32


Jul 29, 2015
Portland, Oregon
cPanel Access Level
Root Administrator
Hi, I have searched all around for some guidance on this (including the forums here), hoping to get some input =)

We are starting from a a fresh cPanel setup w/ MariaDB... we have not yet created any user databases/users.

a) will placing innodb_checksum_algorithm = strict_crc32 in /etc/my.cnf [mysqld] likely
1) cause issues w/ cPanel default setup
2) affect all user databases created (or imported)
3) if alternatively could be done (for instance) /etc/my.cnf.d/checksums.cnf

b) will placing this in a cPanel account home directory, for instance user-home-dir/.my.cnf
(looking at
1) cause this option to affect only the that accounts databases
2) allow simultaneous use of more relaxed innodb_checksum_algorithm = crc32 in /etc/my.cnf

I hope this is clear enough... thanks for insights =)


# A replacement for InnoDB's innodb_checksums and XtraDB's innodb_fast_checksum,
# specifies how the InnoDB tablespace checksum is generated and verified.
# innodb - Backwards compatible with earlier versions.
# crc32 - A newer, faster algorithm, but incompatible with earlier versions.
# Tablespace blocks will be converted to the new format over time, meaning that
# a mix of checksums may be present.
# none - Writes a constant rather than calculate a checksum.
# strict_* - The strict_* options are the same as the regular options, but InnoDB
# will halt if it comes across a mix of checksum values. These are faster, as both
# new and old checksum values are not required, but can only be used when setting
# up tablespaces for the first time.
# Scope: Global
# Default: innodb
# See:
#innodb_checksum_algorithm =

Cheers, Max


Staff member
Jul 17, 2014
cPanel Access Level
Root Administrator
Heya Max,

If you're creating your tables from the ground up within a crc32 environment (or strict_crc32 right out of the gate, for that matter), then I wouldn't guess that you'd run into any compatibility issues or conflicts that would not already be an issue for any MySQL environment attempting to use strict_crc32 (which is essentially just going to relate to any tables still using other algorithms). This has not been extensively tested, however, so I would absolutely recommend setting it up in a non-production, testing environment and monitoring it for a brief period of time to ensure that everything is working like it should be.

On that note I personally support the general, eventual migration to crc32 as the overall InnoDB/XtraDB default, so I certainly on the lookout to determine if there may be any unexpected issues that could crop up from this change specifically in a cPanel environment. I can't imagine anything internally that would throw a fit at CRC32, as there's nothing more complicated or lower-level than simple queries being sent to MySQL from the cPanel back-end, which are not impacted by the algorithm change. That said, as I've learned a long time ago that, just because I can't imagine it, doesn't mean it can't happen, so always use care and of course make backups!

Let us know how it pans out or if you run into any bumps along the way.