I regret that I did not remove the parameter before the MySQL 5.7.9 GA release, related to
WL#8845 Implement an InnoDB redo log format version identifier.
As part of that change, I modified a parameter that had been added earlier:
We will also replace the configuration parameter innodb_log_checksum_algorithm with the Boolean parameter innodb_log_checksums. We make CRC-32C the only checksum on the InnoDB redo log pages when innodb_log_checksums=ON (the default). Checksums on the header page and the checkpoint pages are never disabled.
I was thinking to close this bug as “won’t fix”, but then I got a second thought that maybe we should just deprecate and partly ignore that harmful parameter. (Partly ignore, as in, always compute CRC-32C checksums writing log. But, we must obey this parameter when parsing the log.)
Given that the CRC-32C operations are accelerated on many processor platforms (AMD64 with SSE4.2; since MDEV-22669 also on IA-32 with SSE4.2, POWER 8 and later, ARMv8 with some extensions) and use lookup tables when only generic SISD instructions are available, there should be no valid reason to disable checksums. Performance might be improved a little further by making use of the carry-less multiplication PCLMUL instruction on more recent AMD64/IA-32 implementations.
In MariaDB 10.5.2, as a preparation for MDEV-12353, MDEV-19543 deprecated and ignored the parameter innodb_log_checksums altogether. I think that this means that after a clean shutdown with innodb_log_checksums=0 one cannot upgrade to 10.5. This upgrade bug would be another reason to deprecate and partly ignore the parameter already in 10.2.
The problematic parameter (originally called innodb_log_checksum_algorithm) first appeared in MySQL 5.7.8. This patch did both good and bad: it allowed the original unsafe and slow innodb checksum algorithm to be replaced with CRC-32C, but it also allowed redo log checksums to be disabled altogether.
Because the InnoDB changes from MySQL 5.7 were first applied to MariaDB Server in version 10.2, earlier versions are not affected.
I regret that I did not remove the parameter before the MySQL 5.7.9 GA release, related to
WL#8845 Implement an InnoDB redo log format version identifier.
As part of that change, I modified a parameter that had been added earlier:
I was thinking to close this bug as “won’t fix”, but then I got a second thought that maybe we should just deprecate and partly ignore that harmful parameter. (Partly ignore, as in, always compute CRC-32C checksums writing log. But, we must obey this parameter when parsing the log.)
Given that the CRC-32C operations are accelerated on many processor platforms (AMD64 with SSE4.2; since
MDEV-22669also on IA-32 with SSE4.2, POWER 8 and later, ARMv8 with some extensions) and use lookup tables when only generic SISD instructions are available, there should be no valid reason to disable checksums. Performance might be improved a little further by making use of the carry-less multiplication PCLMUL instruction on more recent AMD64/IA-32 implementations.In MariaDB 10.5.2, as a preparation for
MDEV-12353,MDEV-19543deprecated and ignored the parameter innodb_log_checksums altogether. I think that this means that after a clean shutdown with innodb_log_checksums=0 one cannot upgrade to 10.5. This upgrade bug would be another reason to deprecate and partly ignore the parameter already in 10.2.The problematic parameter (originally called innodb_log_checksum_algorithm) first appeared in MySQL 5.7.8. This patch did both good and bad: it allowed the original unsafe and slow innodb checksum algorithm to be replaced with CRC-32C, but it also allowed redo log checksums to be disabled altogether.
Because the InnoDB changes from MySQL 5.7 were first applied to MariaDB Server in version 10.2, earlier versions are not affected.