Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-23474

InnoDB fails to start with Invalid log block checksum after unsetting innodb_log_checksums dynamically

Details

    Description

      Setting to Minor because the variable has been deprecated in 10.5. However, it is useful to have it at least filed, if not fixed, in case we get complaints of a similar kind from users who wouldn't be able to provide the exact sequence of events prior to the problem.

      --source include/have_innodb.inc
      		 
      SET GLOBAL innodb_log_checksums= 0;
      		 
      --source include/restart_mysqld.inc

      10.4 05d62518

      		 
      2020-08-13 22:11:59 0 [ERROR] InnoDB: Invalid log block checksum. block: 135 checkpoint no: 4 expected: 1507941287 found: 3735928559
      		 
      2020-08-13 22:11:59 0 [ERROR] InnoDB: Missing MLOG_CHECKPOINT at 68859 between the checkpoint 68859 and the end 68608.
      		 
      2020-08-13 22:11:59 0 [ERROR] InnoDB: Plugin initialization aborted at srv0start.cc[1871] with error Generic error
      		 
      2020-08-13 22:12:00 0 [ERROR] Plugin 'InnoDB' init function returned error.
      		 
      2020-08-13 22:12:00 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

      The above minimal test case is only applicable to MTR, but originally the similar problem was observed on a server bootstrapped and started without MTR.

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-12353 Efficient InnoDB redo log record format

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed

          Task - A task that needs to be done. MDEV-19543 Deprecate and ignore innodb_log_checksums

          • Major - Major loss of function.
          • Closed

          Activity

            marko Marko Mäkelä added a comment -

            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.

            marko Marko Mäkelä added a comment - 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.

            People

              marko Marko Mäkelä
              elenst Elena Stepanova
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.