| Bug #75444 | copy-back-and-apply-log forgets to copy back some tables | ||
|---|---|---|---|
| Submitted: | 8 Jan 2015 7:55 | Modified: | 17 Feb 2015 15:25 |
| Reporter: | Daniël van Eeden (OCA) | Email Updates: | |
| Status: | Duplicate | Impact on me: | |
| Category: | MySQL Enterprise Backup | Severity: | S2 (Serious) |
| Version: | 3.11.0 | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
| Tags: | compressed, copy-back, innodb | ||
[8 Jan 2015 8:00]
Daniël van Eeden
Most files are Barracuda/Compact. The missing files are Barracuda/Compressed.
[8 Jan 2015 9:45]
Daniël van Eeden
There is a work-around: use apply-log and then copy-back
[16 Jan 2015 19:36]
Sveta Smirnova
Thank you for the report. I cannot repeat described behavior with backup, taken by version 3.11. Please send output of `ls -lR backup_dir` and `ls -lR restore_dir`
[17 Jan 2015 8:36]
Daniël van Eeden
Please use the exact same versions. Setup MySQL 5.5.40 with some tables. Make sure to set innodb_file_per_table and innodb_file_format=Barracuda. Then create some tables with the default row_format and some with row_format=compressed and key_block_size=4 Then use MEB 3.8.1 to make a compressed full backup. Then use MEB 3.11.0 to restore using copy-back-and-apply-log Some ideas about what might happen: - At some moment (3.10?) some changes were made in compression - The already compressed tables are stored as-is in the backup (without compression) and the regular Antelope/Barracuda+REDUNDANT tables do get compressed. - At restore time all tables except the Barracuda+COMPRESSED tables are restored. This is probably due to a combination of uncompress and moving the tables which is combined.
[22 Jan 2015 22:33]
Sveta Smirnova
Thank you for the feedback. But acording to http://dev.mysql.com/doc/mysql-enterprise-backup/3.11/en/meb-meb-compatibility.html: "MySQL Enterprise Backup 3.11 can be used to restore backups created with MySQL Enterprise Backup 3.9, 3.10, and 3.11." MEB 3.11 is not supposed to restore backups, made by version 3.8 and earlier. This is not a bug.
[24 Jan 2015 9:50]
Daniël van Eeden
It looks there was a major change between 3.10 and 3.11 as 3.10 can restore backups from any 3.x version and 3.11 can only restore from 3.9+. https://dev.mysql.com/doc/mysql-enterprise-backup/3.10/en/meb-meb-compatibility.html https://dev.mysql.com/doc/mysql-enterprise-backup/3.11/en/meb-meb-compatibility.html This was in the release notes. https://dev.mysql.com/doc/relnotes/mysql-enterprise-backup/3.11/en/news-3-11-0.html I think a big change like this should have caused a new major version (4.0) instead of a minor version 3.11 (http://semver.org) and should have made it into the release notes. I can't easily find the version of the software which was used to make the backup. See Bug #74063 for more details. I looks like there isn't a technical reason for dropping the support for older backups. This also means I need to have old (maybe vulnerable) versions of MEB installed to be able to restore backups made a while ago. Shouldn't the MEB RPM contain multiple versions of the software for restore purposes? Solution 1 (best): Ship multiple versions of MEB in the MEB RPM and choose the correct one based on meta/backup_create.xml at restore time. Solution 2 (okay): Detect if it is a supported version based on meta/backup_create.xml and throw an error for unsuported versions (point to correct version and/or manual) Solution 3 (worst): Only update the changelogs
[26 Jan 2015 18:51]
Sveta Smirnova
Thank you for the feedback. Verified as feature request. I personally vote for solution 1.
[30 Jan 2015 9:52]
Rahul Sisondia
This issue happened due to a behavior change in meb 3.10 to fix Bug#17992297. Fix in that bug doesn't not fix the problem with old compressed backups that contain uncompressed datafiles. The workaround for these backups is to do the apply-log before copy-back. It is recommended to use the same procedure to restore backup as it used to be in MEB version when backup was taken. Since backup was taken on 3.8.1 release and at that time copy-back and apply-log were two separate operations. hence apply-log first and copy-back later should work.
[14 Feb 2015 0:59]
Daniel So
The related Bug#17992297 has now been probably documented in the 3.10.0 changelog. The workaround for that and this bug (do apply-log and copy-back in separate steps) has also been documented in the MySQL Enterprise Backup 3.10 and 3.11 manuals, in the description for copy-back-and-apply-log.
[17 Feb 2015 15:25]
Daniel So
This bug is a duplicate of Bug# 17992297--see its entry in the MySQL Enterprise Backup 3.10.0 changelog.
[17 Feb 2015 15:33]
Daniel So
Posted by developer: This bug is a duplicate of Bug# 17992297--see its entry in the MySQL Enterprise Backup 3.10.0 changelog.
Description: After a copy-back-and-apply-log not all files are copied back to the datadir. How to repeat: A backup made of 5.5.40 with MEB 3.8.1 --------------------------------------------------- /foo/mysqlbackup --defaults-file=/foo/mysqlbackup.cnf --user=dbadm --backup_dir=/bar --with-timestamp --compress --compress-level=9 backup mysqlbackup: INFO: MySQL server version is '5.5.40-enterprise-commercial-advanced-log'. mysqlbackup: INFO: Got some server configuration information from running server. --------------------------------------------------- Then a restore with MEB 3.11.0 --------------------------------------------------- mysqlbackup: INFO: Starting with following command line ... /foobar/mysqlbackup --backup-dir=/barfoo/2014-12-28_23-00-00 --datadir=/foobar/restore --uncompress copy-back-and-apply-log --------------------------------------------------- In the backup_content.xml I see *.ibz files and *.ibd files. The *.ibd files are Barracuda/COMRESSED files.