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.