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

innodb_force_recovery is more efficient with InnoDB plugin than XtraDB on certain cases

Details

    Description

      This "bug" is XtraDB related but it could be interesting to put in the KB the fact that trying to restore/access damaged InnoDB datas could work differently when using XtraDB or InnoDB plugin.

      It is the second time that i have a serious power shortage on a server with a RAID card with wright through cache enabled and that has its battery depleted (the RAID card flushes its cache to disk not on a FIFO manner) with InnoDB tables on a MariaDB 5.5 ending up badly corrupted and i encounter this very issue.

      These tables are write intensive as they store monitoring datas.

      The only way to start the server is to set innodb_force_recovery = 6 and to disable XtraDB and load InnoDB plugin instead.

      Setting the innodb_force_recovery to any parameter with XtraDB will end up on either the server crashing at start (with values from 1 to 5 in my case) either with this messages looping in the error log while stays still unavailable : InnoDB: Waiting for the background threads to start

      Here are the kind of errors shown on the error log when starting with innodb_force_recovery = 6 and InnoDB plugin :

      130711  3:09:36  InnoDB: error: space object of table 'zabbix/acknowledges',
      InnoDB: space id 10 did not exist in memory. Retrying an open.
      130711  3:09:36  InnoDB: Warning: allocated tablespace 10, old maximum was 0
      130711  3:09:36  InnoDB: error: space object of table 'zabbix/actions',
      InnoDB: space id 11 did not exist in memory. Retrying an open.
      130711  3:09:36  InnoDB: error: space object of table 'zabbix/alerts',

      Accessing certain rows on certain tables will crash MariaDB but at least the other tables can be dumped completely and these tables can also be partially dumped using a LIMIT clause.

      Attachments

        Activity

          did you report it on percona server bug tracker in launchpad?

          serg Sergei Golubchik added a comment - did you report it on percona server bug tracker in launchpad?
          jb-boin Jean Weisbuch added a comment -

          No, i didnt.

          jb-boin Jean Weisbuch added a comment - No, i didnt.
          jb-boin Jean Weisbuch added a comment - - edited

          Found a possible reason of the difference in behavior, XtraDB has an extra variable to control the response it should have in case it would find corrupted InnoDB tables.
          This variable is called : innodb_corrupt_table_action

          From the official XtraDB documentation (http://www.percona.com/doc/percona-server/5.5/reliability/innodb_corrupt_table_action.html) : With the default value XtraDB will intentionally crash the server with an assertion failure as it would normally do when detecting corrupted data in a single-table tablespace.

          jb-boin Jean Weisbuch added a comment - - edited Found a possible reason of the difference in behavior, XtraDB has an extra variable to control the response it should have in case it would find corrupted InnoDB tables. This variable is called : innodb_corrupt_table_action From the official XtraDB documentation ( http://www.percona.com/doc/percona-server/5.5/reliability/innodb_corrupt_table_action.html ) : With the default value XtraDB will intentionally crash the server with an assertion failure as it would normally do when detecting corrupted data in a single-table tablespace.

          reported on Percona bug tracker as lp:1210098

          serg Sergei Golubchik added a comment - reported on Percona bug tracker as lp:1210098

          Jean, could you subscribe to the lp:1210098 bug report? It's not verified still — they have additional questions, and I don't even have a setup to repeat this bug, so I cannot answer.

          serg Sergei Golubchik added a comment - Jean, could you subscribe to the lp:1210098 bug report? It's not verified still — they have additional questions, and I don't even have a setup to repeat this bug, so I cannot answer.
          jb-boin Jean Weisbuch added a comment -

          Thanks for the report on Percona LP, i am following it now.

          jb-boin Jean Weisbuch added a comment - Thanks for the report on Percona LP, i am following it now.

          People

            Unassigned Unassigned
            jb-boin Jean Weisbuch
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

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