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

mariabackup 10.2+ should default to innodb_checksum_algorithm=crc32

Details

    • Bug
    • Status: Closed (View Workflow)
    • Critical
    • Resolution: Fixed
    • 10.2.15, 10.3.7
    • 10.2.16, 10.3.8
    • Backup
    • None
    • Ubuntu 18.04 "Bionic" 64bit, using packages from mariadb.com apt repository

    Description

      Bcakups taken with mariabackup take a significant higher amount of user CPU time than with XtraBackup on the same data set. The extra time needed is roughly proportional to the amount of data to back up.

      All tests were done on an otherwise idle server, an AMD machine with 8 cores and 48GB RAM.

      Different backup formats (simply to a backup directory, stream in xbstream format) where tried, along with different settings for --parallel and --compress.

      Backup size in the first test series was ~50GB:

      +--------+----------+----------+------------+-------------+-------+----------+
      | target | parallel | compress | xtrabackup | mariabackup | diff  | % slower |
      +--------+----------+----------+------------+-------------+-------+----------+
      | dir    |        1 |        0 |       9.19 |       82.37 | 73.18 |      796 |
      | dir    |        2 |        0 |       9.09 |       82.38 | 73.29 |      806 |
      | dir    |        4 |        0 |       9.06 |        84.1 | 75.04 |      828 |
      | dir    |        1 |        1 |     151.86 |      224.64 | 72.78 |       48 |
      | dir    |        2 |        1 |     155.67 |      225.55 | 69.88 |       45 |
      | dir    |        4 |        1 |     156.05 |      224.93 | 68.88 |       44 |
      | stream |        1 |        0 |      42.78 |      114.75 | 71.97 |      168 |
      | stream |        2 |        0 |      42.98 |      116.28 | 73.30 |      171 |
      | stream |        4 |        0 |      42.19 |      114.57 | 72.38 |      172 |
      | stream |        1 |        1 |     165.32 |      240.84 | 75.52 |       46 |
      | stream |        2 |        1 |     170.08 |      239.74 | 69.66 |       41 |
      | stream |        4 |        1 |     171.62 |       239.9 | 68.28 |       40 |
      +--------+----------+----------+------------+-------------+-------+----------+
      

      In the 2nd series the backup size was close to 90GB:

      +--------+----------+----------+------------+-------------+--------+----------+
      | target | parallel | compress | xtrabackup | mariabackup | diff   | % slower |
      +--------+----------+----------+------------+-------------+--------+----------+
      | dir    |        1 |        0 |      15.23 |      144.99 | 129.76 |      852 |
      | dir    |        2 |        0 |      15.25 |       143.9 | 128.65 |      844 |
      | dir    |        4 |        0 |      15.31 |      146.64 | 131.33 |      858 |
      | dir    |        1 |        1 |      271.1 |      402.57 | 131.47 |       48 |
      | dir    |        2 |        1 |     279.34 |      401.67 | 122.33 |       44 |
      | dir    |        4 |        1 |     281.94 |      399.81 | 117.87 |       42 |
      | stream |        1 |        0 |      73.08 |       200.5 | 127.42 |      174 |
      | stream |        2 |        0 |      74.39 |      201.75 | 127.36 |      171 |
      | stream |        4 |        0 |      73.28 |      200.19 | 126.91 |      173 |
      | stream |        1 |        1 |     299.54 |      428.48 | 128.94 |       43 |
      | stream |        2 |        1 |     306.58 |      425.01 | 118.43 |       39 |
      | stream |        4 |        1 |     308.71 |      430.44 | 121.73 |       39 |
      +--------+----------+----------+------------+-------------+--------+----------+
      

      So regardless of backup options used mariabackup always needed an extra ~70 seconds of user CPU time for the 50GB test, and an extra ~120s for the 90GB test.

      The database was idle while taking the backup, and for the stream output tests the output stream was directed to /dev/null to cut out write costs as much as possible.

      System CPU time was similar across all tests as it mostly just measured the kernel time needed to read and write the backup data.

      Attachments

        Activity

          hholzgra Hartmut Holzgraefe created issue -
          elenst Elena Stepanova made changes -
          Field Original Value New Value
          Fix Version/s 10.2 [ 14601 ]
          Assignee Vladislav Vaintroub [ wlad ]
          hholzgra Hartmut Holzgraefe made changes -
          Attachment mariabackup.gprof [ 45730 ]
          Attachment xtrabackup.gprof [ 45731 ]
          julien.fritsch Julien Fritsch made changes -
          Priority Major [ 3 ] Critical [ 2 ]
          ralf.gebhardt Ralf Gebhardt made changes -
          Affects Version/s 10.3.7 [ 23005 ]
          marko Marko Mäkelä made changes -
          Assignee Vladislav Vaintroub [ wlad ] Marko Mäkelä [ marko ]
          marko Marko Mäkelä made changes -
          Summary mariabackup consuming much more CPU time than XtraBackup mariabackup 10.2+ should default to innodb_checksum_algorithm=crc32
          marko Marko Mäkelä made changes -
          issue.field.resolutiondate 2018-06-14 11:26:56.0 2018-06-14 11:26:56.78
          marko Marko Mäkelä made changes -
          Fix Version/s 10.2.16 [ 23110 ]
          Fix Version/s 10.3.8 [ 23113 ]
          Fix Version/s 10.2 [ 14601 ]
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]
          serg Sergei Golubchik made changes -
          Workflow MariaDB v3 [ 87777 ] MariaDB v4 [ 154494 ]
          mariadb-jira-automation Jira Automation (IT) made changes -
          Zendesk Related Tickets 146446 124448

          People

            marko Marko Mäkelä
            hholzgra Hartmut Holzgraefe
            Votes:
            3 Vote for this issue
            Watchers:
            8 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.