You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 24, 2024. It is now read-only.
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.
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.
br/pkg/conn/conn.go
Line 133 in 56e206e
This brings us to the problem:
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) toauthentication_string(v41) in the system tablemysql.user.