WL#4729: Test that server serialize objects in the same way in different versions

Affects: Server-6.x   —   Status: On-Hold

Minimum requirements
====================
1. Backup images are created with older version of mysql server and  restore of
 old backup images with a newer version of the server should work.
(Upgrade scenario)

2. Backup images are created with newer version of server and restore of newer
backup images with older server version should work as long as  backup image
version doesn't change.
(Downgrade scenario but with constraint on backup image version)

Description
===========
Whenever a change is made to si_objects that results in a different
object byte comparison, the version number of the interface needs to change.
A developer may not be aware that a code change results in different
bytes, but the fact that they are different requires a new version.

This worklog shall produce a method to automatically detect this
change. The upgrade tests need to be run for every new MySQL release
that has a new interface version.

Needs to be considered: upgrade tests may have to be run for every new
MySQL release even if si_objects version has not changed. 


SOME OLD NOTES THAT MIGHT BE USEFUL FOR THIS:
Task: Test that server serialize objects in the same way in different
versions.

Reworded: Test that a new version of the si_objects library can still
restore objects created using the old si_objects library.

Worklog: “Test version compatibility with si_objects”

HLD
---
Goal: Verify that a new version of the si_objects library can still
restore objects created using the old si_objects library.

When a change is made to the si_objects library concerning serialization
(backup) or materialization (restore) of objects, the code must support
the following scenarios:

* Server is upgraded after backup: backup is done with an older version of
the server and si_objects then later restored with a newer version of the
server and si_objects.

* Server is downgraded after backup: restore is done on an older server
and si_objects than what was used to create the backup image. Note: This
scenario requires consideration before supporting. A decision must be made
to support this scenario.

This work shall identify methods for testing these scenarios, changes to
the documentation for how the upgrade/downgrade is supported, and produce
tests for testing the above scenarios. If new testing methods are
identified, these shall become sub tasks of this worklog.

Notes: A decision must be made to the depth of the upgrade/downgrade tests
– how many versions of the si_objects code will be supported?


Proposals
---------
A new backup image shall be created and archived for each new release of
the si_objects code – (e.g. si_objects_1.1.bak). The test shall use these
known backup images for the upgrade/downgrade scenarios.

A plan for what forms of upgrade (mix of versions) shall be officially
supported.

Tests can be designed to detect version changes in the si_objects by
examining the bytes included in the serialization data (metadata in the
backup image) either by byte comparison and/or checksums. The test should
fail if the serialization data from si_objects has changed indicating the
si_objects has changed (and should be a new version). If the test passes,
no upgrade/downgrade tests need to be performed.

Versions used in the backup code
--------------------------------
* si_objects.cc : m_image_version – The version of the serialization format.
* api_types.h : version_t - The reference to version of backup interfaces
* backup_aux.h : se_version() - The version of the plugin for the storage
engine.
* stream_v1.h : version – The snapshot format version number.
* stream.cc : write_magic_and_version() - The magic number and version
number of the stream (current set to 0x0100).
* stream_v1.cc : server version – The server version is stored in the
stream (major, minor, etc.).

Problems to Solve
-----------------
The backup image format version may not coincide with a chance to
si_objects. A procedure for how this is done as well as additional test
cases are needed.
(The following is data collected when the WL was created. It may be incomplete -
JL - Backup Camp, Jan 14 2009)

An excellent way of testing that serializations are equal would be to
add a unit-test to si_objects. The unit test could query si_objects
for all objects in the database and compare the checksum with what it
was in the previous version of si_objects. 

(Backup Camp Bangalore, Jan 18, 2010)
If mysqlbackup can support option to extract si_objects, a test can be written
to generate images in current version and compared with the si_objects from a
baseline version.