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

InnoDB history length and undo tablespace files keep growing

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Incomplete
    • 10.11.6
    • N/A
    • None
    • CloudLinux 7h

    Description

      Hello, after an upgrade from 10.5.19 to 10.11.6 on one of our servers we've started getting complaints on DDL not working on some databases.
      As we checked, we have noticed affected databases had `MDL_SHARED` `Table metadata lock` with thread_id 0 which led us to check innodb status and recently enabled innodb_undo_tablespaces, which are now 16GB and appear to be growing in tandem with history list length.

      Trx id counter 23795545285
      Purge done for trx's n:o < 23673930766 undo n:o < 0 state: running
      History list length 51823666
       
      -rw-rw---- 1 mysql mysql 16928210944 Jan 25 20:35 /var/lib/mysql/undo001
      -rw-rw---- 1 mysql mysql 15804137472 Jan 25 20:33 /var/lib/mysql/undo002
      -rw-rw---- 1 mysql mysql 15988686848 Jan 25 20:34 /var/lib/mysql/undo003
      

      It seems to be stuck at the `23673930766` trx. The only purge related configuration change was innodb_purge_threads to 32, rest are defaults:

      MariaDB [(none)]> show global variables like '%undo%';
      +--------------------------+----------+
      | Variable_name            | Value    |
      +--------------------------+----------+
      | innodb_max_undo_log_size | 10485760 |
      | innodb_undo_directory    | ./       |
      | innodb_undo_log_truncate | OFF      |
      | innodb_undo_tablespaces  | 3        |
      +--------------------------+----------+
      4 rows in set (0.041 sec)
       
      MariaDB [(none)]> show global variables like '%purge%';
      +--------------------------------------+------------+
      | Variable_name                        | Value      |
      +--------------------------------------+------------+
      | aria_log_purge_type                  | immediate  |
      | innodb_max_purge_lag                 | 0          |
      | innodb_max_purge_lag_delay           | 0          |
      | innodb_max_purge_lag_wait            | 4294967295 |
      | innodb_purge_batch_size              | 1000       |
      | innodb_purge_rseg_truncate_frequency | 128        |
      | innodb_purge_threads                 | 32         |
      | relay_log_purge                      | ON         |
      +--------------------------------------+------------+
      8 rows in set (0.001 sec)
       
      $ mysql --version
      mysql  Ver 15.1 Distrib 10.11.6-MariaDB, for Linux (x86_64) using readline 5.1
      

      Does seem very similar to https://jira.mariadb.org/browse/MDEV-31676, but our innodb_max_undo_log_size is default and is undo logs are way over limit, so purges should be going.

      We've already tried experimenting with max_purge_lag% variables, but nothing appeared to help. Also, not all servers from our fleet that got upgraded seem to be affected either, with same configuration.

      If there's any other information needed, please let us know.

      Attachments

        Issue Links

          Activity

            People

              marko Marko Mäkelä
              arnklo Arnas Klova
              Votes:
              0 Vote for this issue
              Watchers:
              4 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.