MySQL New Releases and Percona XtraBackup Incompatibilities

MySQL Percona Backup IncompatibilitiesEarlier this week, Oracle released their Q4 releases series. As on the previous releases, backward compatibility has been broken with previous versions of the server. This time on both MySQL 5.7 and 8.0:

MySQL 5.7.32

While our QA team was performing an extensive test on it,  we found out this version introduced a new compression format version. This change breaks backward compatibility with older versions of MySQL, which is expected on the 8.0 series but is not on 5.7. As Percona XtraBackup (PXB) is based on MySQL code, it makes MySQL 5.7.32 incompatible with current versions of Percona XtraBackup 2.4.20 and prior.

The issue does not affect only Percona XtraBackup but also prevents users from downgrading the server from 5.7.32 to any lower version on the 5.7 series – More details at https://bugs.mysql.com/bug.php?id=101266.

In summary, if you have tables with compression flag as below:

The issue will manifest if a user using 5.7.32:

  • Creates a new compressed table.
  • Runs any ALTER TABLE  that uses the algorithm copy (table rebuild) on a compressed table.

At this moment, we advise users using compressed tables to hold the upgrade to 5.7.32.

We are currently working on making Percona XtraBackup 2.4.21 fully compatible with 5.7.32.

MySQL 8.0.22

Percona XtraBackup 8.0.14 (the latest version available) is not compatible with MySQL 8.0.22 due to disk format changes introduced in the 8.0.22 release.

WL#13782: InnoDB: Add dynamic config option to use fallocate() on Linux introduced a new redo log record MLOG_FILE_EXTEND which is written on the file extension and doesn’t depend on –innodb-extend-and-initialize option. Unfortunately this time, the redo log format version is not bumped up. Percona XtraBackup 8.0.14 during backup, cannot parse this new redo log record and so backup fails.

If by chance, MLOG_FILE_EXTEND is checkpointed, PXB during backup doesn’t see this new record. This leads to a misleading successful backup that cannot be prepared. Let’s see why.

Bug#31587625: PERFORMANCE DEGRADATION AFTER WL14073
This bug fix in 8.0.22, increased the DD version to 8022. PXB during prepare, de-serializes the SDI from IBD file to bootstrap dictionary. Due to the higher DD_VERSION in SDI, PXB 8.0.14 cannot deserialize the SDI and prepare fails.

At this moment, we advise all users to hold the upgrade to 8.0.22.

We are working on these incompatible issues, look out for an upcoming release of PXB release to take successful, consistent backups of 8.0.22

Share this post

Comments (5)

  • pontos Reply

    So when I restored the backup data will Error right?
    When I use Copyback command MySql service cant start !
    Plz Fixes it soon! Thank you.

    October 24, 2020 at 4:11 am
  • Marko Mäkelä Reply

    I believe that it was unnecessary to introduce that format-breaking MLOG_FILE_EXTEND record. MDEV-11556 in MariaDB Server 10.1.21 (back in December 2016) made the InnoDB recovery code properly extend data files without introducing any file format changes at all. The trick was to implement a ‘trigger’ for an existing redo log record that would update the FSP_SIZE field in the first page of the data file.

    October 27, 2020 at 3:37 pm
  • Federico Razzoli Reply

    I’m happy to see that Xtrabackup 2.4.21 has been released. Can you confirm wether the new version is compatible with the latest MySQL 5.7?

    November 25, 2020 at 7:42 am
    • Marcelo Altmann Reply

      Hi Federico,
      Yes 2.4.21 is compatible with 5.7.32. You can double check which underlying mysql source code its used by running –version command:

      ./xtrabackup –version
      xtrabackup: recognized server arguments:
      ./xtrabackup version 2.4.21 based on MySQL server 5.7.32 Linux (x86_64) (revision id: 5b0f89e0e71)

      November 25, 2020 at 7:51 am

Leave a Reply