Description:
We have recently been making some intrusive modifications to test the reliability of MySQL upgrades and have discovered that the community upgrade process lacks atomicity after the DD (Data Dictionary) upgrade phase.
If a failure occurs during the process after the DD upgrade, even with --upgrade=FORCE, tables in performance_schema and views in information_schema that are not relied on DD will not be created again.
In creating tables in performance, the relative code in initialize_pfs() is follows
if (thd->system_thread == SYSTEM_THREAD_DD_RESTART &&
check_perf_schema_has_correct_version(thd))
return false;
and in creating views in I_S, relative code in update_server_I_S_metadata() is follows
if (d->get_target_I_S_version() == actual_version &&
!dd::bootstrap::DD_bootstrap_ctx::instance().dd_upgrade_done())
return false;
When upgrade is failed for sqls in upgrade_system_schemas()，versions of I_S and PS have already changed to high version, so even with --upgrade=FORCE, initialize_pfs() and create_non_dd_based_system_views() can not create tables or views again. If the table or view is new in high version, it is missed and cannot be recovered unless adding version number.
I wonder what do community think about this scene.
How to repeat:
Here have no direct repeat method.
In debug mode, modify 'global_system_variables.default_collation_for_utf8mb4 =&my_charset_utf8mb4_general_ci' instead of 'global_system_variables.default_collation_for_utf8mb4 =&my_charset_utf8mb4_0900_ai_ci' in init_common_variables() in
sql\mysqld.cc.
Using this code to initialize and start mysqld, and then upgrade the mysqld, views in I_S, such as ENABLED_ROLES,APPLICABLE_ROLES, are missed
Description: We have recently been making some intrusive modifications to test the reliability of MySQL upgrades and have discovered that the community upgrade process lacks atomicity after the DD (Data Dictionary) upgrade phase. If a failure occurs during the process after the DD upgrade, even with --upgrade=FORCE, tables in performance_schema and views in information_schema that are not relied on DD will not be created again. In creating tables in performance, the relative code in initialize_pfs() is follows if (thd->system_thread == SYSTEM_THREAD_DD_RESTART && check_perf_schema_has_correct_version(thd)) return false; and in creating views in I_S, relative code in update_server_I_S_metadata() is follows if (d->get_target_I_S_version() == actual_version && !dd::bootstrap::DD_bootstrap_ctx::instance().dd_upgrade_done()) return false; When upgrade is failed for sqls in upgrade_system_schemas()，versions of I_S and PS have already changed to high version, so even with --upgrade=FORCE, initialize_pfs() and create_non_dd_based_system_views() can not create tables or views again. If the table or view is new in high version, it is missed and cannot be recovered unless adding version number. I wonder what do community think about this scene. How to repeat: Here have no direct repeat method. In debug mode, modify 'global_system_variables.default_collation_for_utf8mb4 =&my_charset_utf8mb4_general_ci' instead of 'global_system_variables.default_collation_for_utf8mb4 =&my_charset_utf8mb4_0900_ai_ci' in init_common_variables() in sql\mysqld.cc. Using this code to initialize and start mysqld, and then upgrade the mysqld, views in I_S, such as ENABLED_ROLES,APPLICABLE_ROLES, are missed