MySQL Bugs: #59218: Backward compatibilty breaks for new meb version

Bug #59218	Backward compatibilty breaks for new meb version
Submitted:	29 Dec 2010 18:14	Modified:	20 Jun 2011 16:47
Reporter:	Hema Sridharan	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Enterprise Backup	Severity:	S3 (Non-critical)
Version:	mysqll-5.5-meb meb-3.5.2	OS:	Any
Assigned to:	Ingo Strüwing	CPU Architecture:	Any

Description:
The backup images were created using older MEB version in mysql-5.5-meb tree. These images produces result mismatch in latest version of meb (MEB 3.5.2) and also new mysql-5.5-meb tree.
Please find the attached zipped file and try restoring this in latest mysql-5.5-meb tree. It will result in errors.
Note that issue occurs only in 5.5-meb tree and not in 5.1-meb tree.

How to repeat:
Place the attached zip file in std_data/backups/mysql-5.5/meb-3.5/ in mysql-5.5-meb tree.
Now execute the backward_compat_3_5.test

==============================================================================

TEST                                      RESULT   TIME (ms)
------------------------------------------------------------

worker[1] Using MTR_BUILD_THREAD 303, with reserved ports 13030..13039
meb.backward_compat_3_5                  [ fail ]
        Test ended at 2010-12-29 18:28:40

CURRENT_TEST: meb.backward_compat_3_5
mysqltest: In included file "./suite/meb/include/backward_compat.inc": At line 117: command "diff_files" failed with error 1

The result from queries just before the failure was:
< snip >
 4
 Table  Checksum
-db1.t1 3837626536
+db1.t1 3565476320
 Table  Checksum
 db1.t2 2199111321
 Table  Checksum
@@ -45,10 +45,10 @@
 Table  Checksum
 db2.t2 2199111321
 Table  Checksum
-db2.t3 3837626536
+db2.t3 3565476320
 Table  Checksum
 db3.t1 2199111321
 Table  Checksum
-db3.t2 3837626536
+db3.t2 3565476320
 Table  Checksum
 db3.t3 2199111321

I executed the test with latest version of meb-3.5.2 using old backup image file. It will be good to verify that issue with the old version of meb(MEB 3.5) and check if the test passes.

Suggested fix:
The restore should pass with out any result mismatches even old version of backups

Old backup file

Attachment: extreme_backup-linux-x86.zip (application/zip, text), 115.07 KiB.

Thank you for the report.

Verified as described.

The cause of the test failure is that the backup images have been created with a premature MySQL 5.5 server. That server produced different checksums for the same table content than the current MySQL 5.5 server.

The current MySQL 5.5 server produces identical checksums as the MySQL 5.1 server. Hence, newly created images solve the problem.

To test the above claim, I did the following: I used an image, created from a 5.1 server on a 5.5 server. This produced a couple of entries in the error log, which I suppressed by "CALL mtr.add_suppression". The result was a passing test. This clearly means that the checksums, as contained in the result file, were created identically.

I did also download a backup image as created with MEB 3.5 (not 3.5.2) on a MySQL 5.5 server. The test passed too.

So I dare to claim that there is no compatibility problem with released MySQL servers, just a compatibility problem with a premature 5.5 server. I think, we can ignore this. Note that only the checksums compared differently. All selected data was idendical.

In the course of my analyze, I noticed that we have backup images in the test suite for Linux-x86 only. I think, we need to add more. I keep this bug report open for this purpose.

Fixed in 3.5.3.