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

PS 8.0 mysqldump crashes when innodb-optimize-keys used

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Done
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: 8.0, Not 5.7
    • Fix Version/s: 8.0.13-3
    • Component/s: None
    • Labels:
      None

      Description

      Mysqldump seems to crash if we use innodb-optimize-keys and table has a secondary key which should be optimized in the mysqldump output.

      Consider following:

      use test;
      create table t1 (a int primary key, b int not null, key k_b(b));
      insert into t1 values (1,1),(2,2),(3,3);
      

      PS 8.0 result:

      ### with --innodb-optimize-keys
      plavi@bender  ~/lab/mysql/bin/Percona-Server-8.0.12-2-Linux.x86_64  bin/mysqldump --innodb-optimize-keys --socket=/home/plavi/lab/mysql/bin/Percona-Server-8.0.12-2-Linux.x86_64/socket.sock --user root test t1 > backup-optimized.sql
      Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.
      [1]    1706 segmentation fault  bin/mysqldump --innodb-optimize-keys  --user root test t1 >
      
      # GDB INFO
      --
      -- Table structure for table `t1`
      --
      Program received signal SIGSEGV, Segmentation fault.
      0x00000000004238b5 in skip_secondary_keys (has_pk=true, create_str=<optimized out>) at ../../../../client/mysqldump.cc:2759
      2759    ../../../../client/mysqldump.cc: No such file or directory.
      
      ### without --innodb-optimize-keys works ok
      plavi@bender  ~/lab/mysql/bin/Percona-Server-8.0.12-2-Linux.x86_64  bin/mysqldump --socket=/home/plavi/lab/mysql/bin/Percona-Server-8.0.12-2-Linux.x86_64/socket.sock --user root test t1 > backup.sql
      Warning: A partial dump from a server that has GTIDs will by default include the GTIDs of all transactions, even those that changed suppressed parts of the database. If you don't want to restore GTIDs, pass --set-gtid-purged=OFF. To make a complete dump, pass --all-databases --triggers --routines --events.
      

      PS 5.7.23 result:

      # with --innodb-optimize-keys
      plavi@bender  ~/lab/mysql/bin/Percona-Server-5.7.23-23-Linux.x86_64.ssl102  bin/mysqldump --innodb-optimize-keys --socket=/home/plavi/lab/mysql/bin/Percona-Server-5.7.23-23-Linux.x86_64.ssl102/socket.sock --user root test t1 > backup-optimized.sql
      
      # without --innodb-optimize-keys
      plavi@bender  ~/lab/mysql/bin/Percona-Server-5.7.23-23-Linux.x86_64.ssl102  bin/mysqldump --socket=/home/plavi/lab/mysql/bin/Percona-Server-5.7.23-23-Linux.x86_64.ssl102/socket.sock --user root test t1 > backup.sql
      
      # file diff to prove that key generation was added after table create
      plavi@bender  ~/lab/mysql/bin/Percona-Server-5.7.23-23-Linux.x86_64.ssl102  diff backup.sql backup-optimized.sql
      37,38c37
      <   PRIMARY KEY (`a`),
      <   KEY `k_b` (`b`)
      ---
      >   PRIMARY KEY (`a`)
      48a48
      > ALTER TABLE `t1` ADD KEY `k_b` (`b`);
      65c65
      < -- Dump completed on 2018-10-29 14:34:47
      ---
      > -- Dump completed on 2018-10-29 14:34:31
      

        Smart Checklist

          Attachments

            Activity

              People

              • Assignee:
                przemyslaw.skibinski Przemyslaw Skibinski
                Reporter:
                tomislav.plavcic@percona.com Tomislav Plavcic
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 6 hours, 30 minutes
                  6h 30m