WL#11063: Update server version information in InnoDB tablespaces
Affects: Server-8.0 — Status: Complete — Priority: Medium
Update server version information in InnoDB tablespaces In 8.0 we write the "server version number" to the tablespace header in all relevant InnoDB tablespaces (i.e. user tablespaces and the data dictionary tablespace). Hence, we have a way to associate user-data with a given server version. Here we only register the '''birth-mark''', the server version number which either did major upgrade, created, or imported the tablespace. It will work like this: * Upgrade from 5.7 to 8.0 will establish the version number in all tablespaces, e.g. if user upgraded from 5.7 to "8.0.5" then "8.0.5" will be stored in all tablespaces. * The number will ''not'' be updated by MRUs. So even when a user upgrade to "8.0.6" , version "8.0.5" will remain in all tablespaces. The same will be true for downgrades. * Any new tablespace ''created'' by any "8.0" server will store its version number in the tablespaces, e.g. "8.0.13" will store "8.0.13". * Any tablespace ''imported'' by any "8.0" server will store its version number in the tablespaces, e.g. "8.0.20" importing a tablespace will store "8.0.20" (after accepting it as a valid "8.0" tablespace). * Upgrade from 8.0 to 9.0 will establish the version number in all tablespaces, e.g. if user upgraded from "8.0.5" to "9.0.10" then "9.0.10" will be stored in all tablespaces. Notes: * Later we might update the version numbers also during all upgrade and downgrade but for now we limit it to major upgrade * Server version number in tablespaces can be generalized to all disk artifacts, like configuration files.
- In-place upgrade from mysql-5.7 should add the server version number in every tablespace on the page 0 of the tablespace, at byte 8 - In-place upgrade from mysql-5.7 should add the space version number in every tablespace on the page 0 of the tablespace, at byte 12 - Importing any tablespace should add the current server version number in the tablespace on the page 0 of the tablespace, at byte 8 - Importing any tablespace should add the current space version number in the tablespace on the page 0 of the tablespace, at byte 12
While importing tablespace, mysql server version number and space version number will be written to the tablespace in page zero. It will be done before creating SDI Index page in the tablespace. WL#9461 mentions the upgrade flowchart when upgrading from mysql-5.7 to mysql-8.0. Version number will be added to tablespaces in step 17 along with creating SDI index in tablespaces (reference below). A new handlerton API will be added which can used by Storage engines to update version information in the tablespaces in case of upgrade. API signauture: typedef bool (*upgrade_space_version_t)(dd::Tablespace *tablespace); For reference, the following flowchart is copied from WL#9461 worklog page. Upgrade Flowchart: ================== Flowchart of Upgrade from mysql-5.7 to a version with global data dictionary after InnoDB changes will be as follows : 1. Slow shutdown 5.7 server. 2. Start 8.0 server on same data directory. 3. Check if we are upgrading or restarting. 4. Create a temporary file to record stages of upgrade to handle server crash in case server is upgrading. 5. Check that InnoDB undo log is empty, else empty undo log. (in scope of WL#9357). 6. Create Dictionary tables in old data directory. 7. Update the temporary file maintaining stages of upgrade to mark that data dictionary tables are created. This is important as InnoDB does not create entry in undo logs for dictionary table creation. 8. Initialize all stages of dictionary. 9. Upgrade schema, i.e., create dictionary entry for schema. 10 Upgrade tablespaces, i.e., create dictionary entry for tablespace. 11. In upgrading table, get se_private_data and foreign key data from storage engine. 12. Upgrade views without fixing view dependency. 13. Upgrade Events. 14. Upgrade SP/SF. 15. Fix view dependency. 16. Create a marking that we have migrated all meta data from other storage engines to dictionary. It is done in temporary file created to record progress of upgrade. InnoDB will change .ibd files after this stage. Even if server is killed after this step, upgrade will only roll forward and complete only steps after this ( step 18 onwards). Upgrade can't roll back its changes after this step is complete. 17. Iterate over all tablespaces and tables to create SDI information. 18. Cleanup after upgrade, delete all .frm, .TRG, .TRN, .opt and other files used by mysql-5.7. Drop mysql.proc and mysql.event system tables used by mysql-5.7. Delete the temporary file created to record progress of upgrade.
Copyright (c) 2000, 2019, Oracle Corporation and/or its affiliates. All rights reserved.