-
bin.x.su@oracle.com authored
== Analysis == Windows format string is wrong, we should use "%016llx" rather than "%016llu" == Solution == This patch will force all the aux tables to be renamed from "%016llu" format to "%016llx" only in Windows, keeping aux table names in Linux unchanged. Suppose all users who want to upgrade server will start the new server in read/write mode at the first time. Macro definitions are fixed first. Only one format "%016llx" will be used in fts_write(read)_object_id. And a table flags2 bit named DICT_TF2_FTS_AUX_HEX_NAME(HEX_NAME for short) is introduced which is used in the following way: 1. If an aux table is renamed to "%016llx" format, set this aux table's flags2 with this bit. And if a parent table's aux tables are all renamed to "%016llx" format, set this parent table's flags2 with this bit. (Win) 2. Set a parent table and all its aux tables' flags2 with this bit. (Linux) 3. For all existing tables, this bit will be set for a parent table and all its aux tables, or none of them will be set. (Win/Linux) 4. Set all new created and/or altered tables(aux tables)' flags2 with this bit. (Win/Linux) During the upgrade which only happens in Windows, we do these: 1. sort all aux tables by their parent table IDs in case rename will fail. 2. prepare a vector(V) to store aux tables which need to be renamed. 3. try to open an aux table, whose table id is always correct. 4. if fail to open the table or the table opened is a different table, skip this table. 5. if the opened aux table doesn't have flags2 set with HEX_NAME, convert all ids on it to the correct ones. 6. then we can open the parent table with a correct id. 7. do things like original codes do. 8. if this aux table won't be dropped, put this aux table to V. 9. if all aux tables belonging to the same parent table are collected, try to rename them(stored in V) in a batch mode. If all rename operations succeed, set all flags2 with HEX_NAME, otherwise, rollback all the rename operations for this parent table. For Linux, It needs to set the flags2 for every parent and aux tables. If the server crashes during the upgrade, all those aux common tables, which have already been renamed, should be renamed to their original names while renamed index tables will roll back automatically. Otherwise, these tables' names in innodb_sys_tables will not consist with their data file's names. After that, the server can upgrade again when it restart. In case the upgrade fails, the server can access both tables with AUX_HEX_NAME set and without AUX_HEX_NAME set. The tables fail to rename will upgrade themselves when server restart. One restriction is that we can't do in-place add fulltext to those tables fail to rename(we will get an new error from server), to make sure that either the AUX_HEX_NAME flags are set in parent table and its aux tables or not. Other DDL operations are allowed. rb#2396, approved by Jimmy.
bin.x.su@oracle.com authored== Analysis == Windows format string is wrong, we should use "%016llx" rather than "%016llu" == Solution == This patch will force all the aux tables to be renamed from "%016llu" format to "%016llx" only in Windows, keeping aux table names in Linux unchanged. Suppose all users who want to upgrade server will start the new server in read/write mode at the first time. Macro definitions are fixed first. Only one format "%016llx" will be used in fts_write(read)_object_id. And a table flags2 bit named DICT_TF2_FTS_AUX_HEX_NAME(HEX_NAME for short) is introduced which is used in the following way: 1. If an aux table is renamed to "%016llx" format, set this aux table's flags2 with this bit. And if a parent table's aux tables are all renamed to "%016llx" format, set this parent table's flags2 with this bit. (Win) 2. Set a parent table and all its aux tables' flags2 with this bit. (Linux) 3. For all existing tables, this bit will be set for a parent table and all its aux tables, or none of them will be set. (Win/Linux) 4. Set all new created and/or altered tables(aux tables)' flags2 with this bit. (Win/Linux) During the upgrade which only happens in Windows, we do these: 1. sort all aux tables by their parent table IDs in case rename will fail. 2. prepare a vector(V) to store aux tables which need to be renamed. 3. try to open an aux table, whose table id is always correct. 4. if fail to open the table or the table opened is a different table, skip this table. 5. if the opened aux table doesn't have flags2 set with HEX_NAME, convert all ids on it to the correct ones. 6. then we can open the parent table with a correct id. 7. do things like original codes do. 8. if this aux table won't be dropped, put this aux table to V. 9. if all aux tables belonging to the same parent table are collected, try to rename them(stored in V) in a batch mode. If all rename operations succeed, set all flags2 with HEX_NAME, otherwise, rollback all the rename operations for this parent table. For Linux, It needs to set the flags2 for every parent and aux tables. If the server crashes during the upgrade, all those aux common tables, which have already been renamed, should be renamed to their original names while renamed index tables will roll back automatically. Otherwise, these tables' names in innodb_sys_tables will not consist with their data file's names. After that, the server can upgrade again when it restart. In case the upgrade fails, the server can access both tables with AUX_HEX_NAME set and without AUX_HEX_NAME set. The tables fail to rename will upgrade themselves when server restart. One restriction is that we can't do in-place add fulltext to those tables fail to rename(we will get an new error from server), to make sure that either the AUX_HEX_NAME flags are set in parent table and its aux tables or not. Other DDL operations are allowed. rb#2396, approved by Jimmy.
Loading