Earlier 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:
1 | CREATE TABLE t1 (c1 INT) COMPRESSION="zlib"; |
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
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.
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.
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?
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)
Thank you Marcelo, this is great news.
Hi, is there any update concerning percona 8.0.14 and mysql 8.0.22 ?
PXB 8.0.22 was released today and it’s fully compatible with MySQL 8.0.22 / Percona Server 8.0.22
will this fix be available for rh6 backup?
Is there a planned update for MySQL 8.0.23?