TiDB has a concept called "bootstrap version" (tidb_server_version). It represents the schemas of the system tables. If a TiDB server with a newer bootstrap version (e.g. v41) is started on a storage with older version (e.g. v40), the TiDB server will perform a "rolling upgrade" (execute some DDL statements) to migrate the schemas to v41.

This action is also performed when BR uses its own TiDB to bootstrap the session.

This brings us to the problem:

• If BR version < cluster TiDB version, BR cannot understand system schemas and thus won't run.
• If BR version > cluster TiDB version, BR will "rolling upgrade" and TiDB can't use the cluster anymore unless user also upgrades TiDB.

Thus the only safe solution is to ensure BR version = cluster TiDB version.

How should our version management cope with this?

This was revealed in #158 (https://internal.pingcap.net/idc-jenkins/blue/organizations/jenkins/br_ghpr_unit_and_integration_test/detail/br_ghpr_unit_and_integration_test/828/pipeline/) due to pingcap/tidb#14598 renaming the column password (v40) to authentication_string (v41) in the system table mysql.user.