Uploaded image for project: 'Percona Server for MySQL'
  1. Percona Server for MySQL
  2. PS-3003

LP #1210098: innodb_force_recovery is more efficient with InnoDB plugin than XtraDB on certain cases

    Details

    • Type: Bug
    • Status: Done
    • Priority: Low
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None

      Description

      **Reported in Launchpad by Sergei Golubchik last update 04-02-2014 04:17:22

      Originally reported as https://mariadb.atlassian.net/browse/MDEV-4777
      ===================================
      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 data.

      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.
      ===================================

      As further comments indicate, a possible reason could be innodb_corrupt_table_action variable.

        Smart Checklist

          Attachments

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                lpjirasync lpjirasync (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: