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

MariaDB 10.6.7 issue after import (innodb_stats_persistent issue)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 10.6.7
    • Fix Version/s: None
    • Component/s: None
    • Environment:
      Centos 7

      Description

      I have a bunch of CentOS 7 servers that I manage and we recently upgraded MariaDB from 10.5 to 10.6 on those servers. Now I'm seeing some odd problems which manifest as serious performance issues after I import a database. Meaning that SQL queries that were running in a short time suddenly became very slow.

      I then found that simply running "mysqlcheck -a" totally fixes the problem and I can reproduce this issue every time but I can't figure out what is causing it.

      In addition to the performance issues that I see, I also see odd stats from information_schema and the cardinality of the indexes. The latter part is I think why the SQL queries become slower.

      You can see a full test of this issue in the attached screenshot. I can put that into a code box but I thought the annotations made it easier to see the problems here. Anyone seen this before or have any idea what it going on?

      EDIT: additional info

      I found that disabling innodb_stats_persistent completely fixes the problem. Of course, that is likely not a real fix. Is there a problem with innodb_stats_persistent in MariaDB 10.6?

        Attachments

          Activity

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            wk_bradp Brad
            Votes:
            0 Vote for this issue
            Watchers:
            6 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.