Skip to content
This repository was archived by the owner on Jul 24, 2024. It is now read-only.
This repository was archived by the owner on Jul 24, 2024. It is now read-only.

Problem: BR's internal TiDB version must match cluster's TiDB version. #166

@kennytm

Description

@kennytm

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.

dom, err := session.BootstrapSession(storage)

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionFurther information is requested

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions