【TiDB 社区升级互助材料】TiDB 版本升级最全材料包

一、升级版本选择

  1. 主推版本 Release Notes

TiDB 7.5.1 Release Noteshttps://docs.pingcap.com/zh/tidb/stable/release-7.5.1

TiDB 7.1. 5 Release Noteshttps://docs.pingcap.com/zh/tidb/stable/release-7.1.5

TiDB 6.5.9 Release Noteshttps://docs.pingcap.com/zh/tidb/stable/release-6.5.9

  1. 主推版本特性解读

TiDB 6.X 版本和7.X 版本主要区别:7.X 版本有 Resource Control 资源管控功能

7.5.x 相关特性解读

7.1.x 相关特性解读

6.5.x 相关特性解读

二、升级方案选择


可参考:专栏 - TiDB 升级方案选择 | TiDB 社区

三、升级工具介绍&FAQ

  1. TiUP

在物理机或虚拟机上的 TiDB 包管理器,管理着 TiDB 的众多的组件,如 TiDB、PD、TiKV 等。当你想要运行 TiDB 生态中任何组件时,只需要执行一行 TiUP 命令即可(TiDB v4.0 起)。

TiUP 文档介绍:https://docs.pingcap.com/zh/tidb/stable/tiup-overview

TiUP FAQ:https://docs.pingcap.com/zh/tidb/stable/tiup-faq

  1. Dumpling

数据导出工具,可以把存储在 TiDB 或 MySQL 中的数据导出为 SQL 或 CSV 格式,用于逻辑全量备份。Dumpling 也支持将数据导出到 Amazon S3 中。

Dumpling 文档介绍:https://docs.pingcap.com/zh/tidb/stable/dumpling-overview

  1. Lightning

数据导入工具,用于从静态文件导入 TB 级数据到 TiDB 集群的工具,常用于 TiDB 集群的初始化数据导入。

Lighting 文档介绍:https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-overview

导入(新)数据库要求:https://docs.pingcap.com/zh/tidb/stable/tidb-lightning-requirements

Lightning 常见故障处理:https://docs.pingcap.com/zh/tidb/stable/troubleshoot-tidb-lightning

  1. TiCDC

增量数据同步工具,通过拉取 TiKV 变更日志实现的 TiDB 增量数据同步。TiCDC 典型的应用场景为搭建多套 TiDB 集群间的主从复制,或者配合其他异构的系统搭建数据集成服务。

TiCDC 文档介绍:https://docs.pingcap.com/zh/tidb/stable/ticdc-overview

TiCDC 常见故障和解决方案:https://docs.pingcap.com/zh/tidb/stable/troubleshoot-ticdc

四、升级前应做哪些准备?

  1. 升级前必看文档

  1. 了解系统的健康状况

  2. 确认集群拓扑结构是否满足高可用需求

  3. 集群拓扑是否健康

  4. 硬件配置是否达标

  5. 集群使用情况

  6. 集群数据量

  7. 大表情况

  8. 表宽度,字段数量

  9. SQL 语句 DDL\DML 执行情况 QPS

  10. 字符集等兼容情况

  11. 升级常见问题

(1)滚动升级有那些影响?

滚动升级 TiDB 期间,业务运行会受到一定影响。因此,不建议在业务高峰期进行滚动升级。需要配置最小集群拓扑 (TiDB * 2、PD * 3、TiKV * 3),如果集群环境中有 Pump 和 Drainer 服务,建议先停止 Drainer,然后滚动升级(升级 TiDB 时会升级 Pump)。

(2)集群在执行 DDL 请求期间可以进行升级操作吗?

  • 如果升级前 TiDB 的版本低于 v7.1.0:

    • 集群中有 DDL 语句正在被执行时(通常为 ADD INDEX 和列类型变更等耗时较久的 DDL 语句),请勿进行升级操作。在升级前,建议使用 ADMIN SHOW DDL 命令查看集群中是否有正在进行的 DDL Job。如需升级,请等待 DDL 执行完成或使用 ADMIN CANCEL DDL 命令取消该 DDL Job 后再进行升级。

    • 在升级 TiDB 集群的过程中,请勿执行 DDL 语句,否则可能会出现行为未定义的问题。

  • 如果升级前 TiDB 的版本为 v7.1.0 或更高的版本:

    • 不用遵循限制低版本升级时的限制,即在升级时可以接收用户 DDL 任务。建议参考平滑升级 TiDB
  1. 用户版本升级实践

7.5.x升级实践

7.1.x升级实践

升级中

使用 TiUP 升级 TiDB

本文档适用于以下升级路径:

  • 使用 TiUP 从 TiDB 4.0 版本升级至 TiDB 7.5。

  • 使用 TiUP 从 TiDB 5.0-5.4 版本升级至 TiDB 7.5。

  • 使用 TiUP 从 TiDB 6.0-6.6 版本升级至 TiDB 7.5。

  • 使用 TiUP 从 TiDB 7.0-7.4 版本升级至 TiDB 7.5。

警告

  1. 不支持将 TiFlash 组件从 5.3 之前的老版本在线升级至 5.3 及之后的版本,只能采用停机升级。如果集群中其他组件(如 tidb,tikv)不能停机升级,参考不停机升级中的注意事项。

  2. 在升级 TiDB 集群的过程中,请勿执行 DDL 语句,否则可能会出现行为未定义的问题。

  3. 集群中有 DDL 语句正在被执行时(通常为 ADD INDEX 和列类型变更等耗时较久的 DDL 语句),请勿进行升级操作。在升级前,建议使用 ADMIN SHOW DDL 命令查看集群中是否有正在进行的 DDL Job。如需升级,请等待 DDL 执行完成或使用 ADMIN CANCEL DDL 命令取消该 DDL Job 后再进行升级。

从 TiDB v7.1 版本升级至更高的版本时,可以不遵循上面的限制 2 和 3,建议参考平滑升级 TiDB 的限制

升级后

升级后常见问题

本小节列出了一些升级后可能会遇到的问题与解决办法。

执行 DDL 操作时遇到的字符集 (charset) 问题

TiDB 在 v2.1.0 以及之前版本(包括 v2.0 所有版本)中,默认字符集是 UTF8。从 v2.1.1 开始,默认字符集变更为 UTF8MB4。如果在 v2.1.0 及之前版本中,建表时显式指定了 table 的 charset 为 UTF8,那么升级到 v2.1.1 之后,执行 DDL 操作可能会失败。

要避免该问题,需注意以下两个要点:

  • 在 v2.1.3 之前,TiDB 不支持修改 column 的 charset。所以,执行 DDL 操作时,新 column 的 charset 需要和旧 column 的 charset 保持一致。

  • 在 v2.1.3 之前,即使 column 的 charset 和 table 的 charset 不一样,show create table 也不会显示 column 的 charset,但可以通过 HTTP API 获取 table 的元信息来查看 column 的 charset,下文提供了示例。

unsupported modify column charset utf8mb4 not match origin utf8

  • 升级前:v2.1.0 及之前版本
create table t(a varchar(10)) charset=utf8;
Query OK, 0 rows affected
Time: 0.106s
show create table t
+-------+-------------------------------------------------------+
| Table | Create Table                                          |
+-------+-------------------------------------------------------+
| t     | CREATE TABLE `t` (                                    |
|       |   `a` varchar(10) DEFAULT NULL                        |
|       | ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin |
+-------+-------------------------------------------------------+
1 row in set
Time: 0.006s
  • 升级后:v2.1.1、v2.1.2 会出现下面的问题,v2.1.3 以及之后版本不会出现下面的问题。
alter table t change column a a varchar(20);
ERROR 1105 (HY000): unsupported modify column charset utf8mb4 not match origin utf8

解决方案:显式指定 column charset,保持和原来的 charset 一致即可。

alter table t change column a a varchar(22) character set utf8;
  • 根据要点 1,此处如果不指定 column 的 charset,会用默认的 UTF8MB4,所以需要指定 column charset 保持和原来一致。

  • 根据要点 2,用 HTTP API 获取 table 元信息,然后根据 column 名字和 Charset 关键字搜索即可找到 column 的 charset。

curl "http://$IP:10080/schema/test/t" | python -m json.tool
  • 这里用了 python 的格式化 json 的工具,也可以不加,此处只是为了方便注释。

{“ShardRowIDBits”: 0,“auto_inc_id”: 0,“charset”: “utf8”,table 的 charset"collate": “”,“cols”: [ # 从这里开始列举 column 的相关信息{ …“id”: 1,“name”: {“L”: “a”,“O”: “a"column 的名字},“offset”: 0,“origin_default”: null,“state”: 5,“type”: {“Charset”: “utf8”,column a 的 charset"Collate”: “utf8_bin”,“Decimal”: 0,“Elems”: null,“Flag”: 0,“Flen”: 10,“Tp”: 15}}], … }

unsupported modify charset from utf8mb4 to utf8

  • 升级前:v2.1.1,v2.1.2
create table t(a varchar(10)) charset=utf8;
Query OK, 0 rows affected
Time: 0.109s
show create table t;
+-------+-------------------------------------------------------+
| Table | Create Table                                          |
+-------+-------------------------------------------------------+
| t     | CREATE TABLE `t` (                                    |
|       |   `a` varchar(10) DEFAULT NULL                        |
|       | ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin |
+-------+-------------------------------------------------------+
  • 上面 show create table 只显示出了 table 的 charset,但其实 column 的 charset 是 UTF8MB4,这可以通过 HTTP API 获取 schema 来确认。这是一个 bug,即此处建表时 column 的 charset 应该要和 table 保持一致为 UTF8,该问题在 v2.1.3 中已经修复。

  • 升级后:v2.1.3 及之后版本

show create table t;
+-------+--------------------------------------------------------------------+
| Table | Create Table                                                       |
+-------+--------------------------------------------------------------------+
| t     | CREATE TABLE `t` (                                                 |
|       |   `a` varchar(10) CHARSET utf8mb4 COLLATE utf8mb4_bin DEFAULT NULL |
|       | ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin              |
+-------+--------------------------------------------------------------------+
1 row in set
Time: 0.007s
alter table t change column a a varchar(20);
ERROR 1105 (HY000): unsupported modify charset from utf8mb4 to utf8

解决方案:

  • 因为在 v2.1.3 之后,TiDB 支持修改 column 和 table 的 charset,所以这里推荐修改 table 的 charset 为 UTF8MB4。
alter table t convert to character set utf8mb4;
  • 也可以像问题 1 一样指定 column 的 charset,保持和 column 原来的 charset (UTF8MB4) 一致即可。
alter table t change column a a varchar(20) character set utf8mb4;

ERROR 1366 (HY000): incorrect utf8 value f09f8c80(🌀) for column a

TiDB 在 v2.1.1 及之前版本中,如果 charset 是 UTF8,没有对 4-byte 的插入数据进行 UTF8 Unicode encoding 检查。在 v2.1.2 及之后版本中,添加了该检查。

  • 升级前:v2.1.1 及之前版本
create table t(a varchar(100) charset utf8);
Query OK, 0 rows affected
insert t values (unhex('f09f8c80'));
Query OK, 1 row affected
  • 升级后:v2.1.2 及之后版本
insert t values (unhex('f09f8c80'));
ERROR 1366 (HY000): incorrect utf8 value f09f8c80(🌀) for column a

解决方案:

  • v2.1.2 版本:该版本不支持修改 column charset,所以只能跳过 UTF8 的检查。
set @@session.tidb_skip_utf8_check=1;
Query OK, 0 rows affected
insert t values (unhex('f09f8c80'));
Query OK, 1 row affected
  • v2.1.3 及之后版本:建议修改 column 的 charset 为 UTF8MB4。或者也可以设置 tidb_skip_utf8_check 变量跳过 UTF8 的检查。如果跳过 UTF8 的检查,在需要将数据从 TiDB 同步回 MySQL 的时候,可能会失败,因为 MySQL 会执行该检查。
alter table t change column a a varchar(100) character set utf8mb4;
Query OK, 0 rows affected
insert t values (unhex('f09f8c80'));
Query OK, 1 row affected
  • 关于 tidb_skip_utf8_check 变量,具体来说是指跳过 UTF8 和 UTF8MB4 类型对数据的合法性检查。如果跳过这个检查,在需要将数据从 TiDB 同步回 MySQL 的时候,可能会失败,因为 MySQL 执行该检查。如果只想跳过 UTF8 类型的检查,可以设置 tidb_check_mb4_value_in_utf8 变量。

  • tidb_check_mb4_value_in_utf8 在 v2.1.3 版本加入 config.toml 文件,可以修改配置文件里面的 check-mb4-value-in-utf8 后重启集群生效。

  • tidb_check_mb4_value_in_utf8 在 v2.1.5 版本开始可以用 HTTP API 来设置,也可以用 session 变量来设置。

    • HTTP API(HTTP API 只在单台服务器上生效)

      • 执行下列命令启用 HTTP API:
curl -X POST -d "check_mb4_value_in_utf8=1" http://{TiDBIP}:10080/settings
* 执行下列命令禁用 HTTP API:
curl -X POST -d "check_mb4_value_in_utf8=0" http://{TiDBIP}:10080/settings
  • Session 变量

    • 执行下列命令启用 Session 变量:
set @@session.tidb_check_mb4_value_in_utf8 = 1;
* 执行下列命令禁用 Session 变量:
set @@session.tidb_check_mb4_value_in_utf8 = 0;
  • v2.1.7 及之后版本,如果对表和 column 的字符集没有严格要求为 UTF8,也不想修改客户端代码去跳过 UTF8 检查或者手动修改 column 的 charset,可以在配置文件中把 treat-old-version-utf8-as-utf8mb4 打开。该配置的作用是自动把 v2.1.7 版本之前创建的旧版本的表和 column 的 UTF8 字符集转成 UTF8MB4。这个转换是在 TiDB load schema 时在内存中将 UTF8 转成 UTF8MB4,不会对实际存储的数据做任何修改。在配置文件中关闭 treat-old-version-utf8-as-utf8mb4 并重启 TiDB 后,以前字符集为 UTF8 的表和 column 的字符集仍然还是 UTF8。

  • 注意

  • treat-old-version-utf8-as-utf8mb4 参数默认打开,如果客户端强制需要用 UTF8 而不用 UTF8MB4,需要在配置文件中关闭。

拓展阅读

测试&对比&评测

4 个赞

牛牛牛犇

TiCDC 需要好好优化下

表妹的大作~ 相当强大

认同 +4000

非常赞的互助材料,表妹版人工智能4.0 :smile: