This repository has been archived by the owner on Jul 24, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 102
Problem: BR's internal TiDB version must match cluster's TiDB version. #166
Labels
question
Further information is requested
Comments
Developers from TiDB confirmed that We still need to upgrade the tidb deps in BR. |
Merged
Found tidb: v3.1.0.beta.1 before run br backup:
after:
password changed to authentication_string, then when use correct verion of br(v3.1.0.beta.1) will cause |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
.The text was updated successfully, but these errors were encountered: