TiDB v7.5.0 LTS 升级必读 | 新特性补充说明

原创
2023/12/07 00:00
阅读数 12

作者: ShawnYan 原文来源:https://tidb.net/blog/be2db121

前言

12 月 1 日,期待已久的 TiDB v7.5.0 LTS 发版。 TiDB 7.5.0 Release Notes

作为 TiDB 7 系列的第二个长期支持版本 (LTS) ,TiDB 7.5 着眼于提升规模化场景下关键应用的稳定性。新版本中,TiDB 在可扩展性与性能、稳定性与高可用、SQL 以及可观测性等方面获得了持续的提升。TiDB 7.5 LTS 包含了已发布的 7.2.0-DMR、7.3.0-DMR 和 7.4.0-DMR 版本中的新功能、提升改进和错误修复,累计优化和修复功能 70 余项。

前文中,我们详细地介绍了 TiDB Server 在 v7.1 到 v7.4 的新特性,彼时 TiDB v7.5.0 LTS 尚未发版。

no-alt

本文作为前文的补充,来观察一下该版本中的其他新特性。

版本选择

前文中的彩蛋,这里更新了一下 TiDB v7.5.0 LTS 的发版日期。

no-alt

关于生产环境版本的选择,是论坛里经常讨论的问题,如果明年有项目上线,又期望使用到新特性,那么 TiDB v7.5 LTS 将是首选。

至于 DMR 版本,强烈不建议上生产,仅可用于功能验证。

DDL: ADD INDEX

支持并行运行多个 ADD INDEX 语句

通过该功能,为同一个表添加多个索引的任务可以变为并发运行。以前同时运行 2 个添加索引语句 X 和 Y 需要花费 X 的时间 + Y 的时间,现在在一个 SQL 语句中同时添加索引 X 和 Y,并发运行后,添加索引总耗时显著减少了。尤其是在宽表的场景,内部测试数据显示同时添加多个索引的性能最高可提升 94%。

支持设置 TiDB 节点的服务范围,用于选择适用的 TiDB 节点分布式执行 ADD INDEX (GA)

在资源密集型集群中,并行执行 ADD INDEXIMPORT INTO 任务可能占用大量 TiDB 节点的资源,从而导致集群性能下降。为了避免对已有业务造成性能影响,v7.4.0 以实验特性引入了变量 tidb_service_scope,用于控制 TiDB 后端任务分布式框架 下各 TiDB 节点的服务范围。你可以从现有 TiDB 节点中选择几个节点,或者对新增 TiDB 节点设置服务范围,所有分布式执行的 ADD INDEXIMPORT INTO 的任务只会运行在这些节点。该方法可以实现与其他 TiDB 节点的资源隔离,确保在执行上述语句时的最佳性能,并避免对已有业务造成性能影响。在 v7.5.0 中,该功能正式 GA。

在系统变量 tidb_service_scope 的相关文档中,有这样一段描述:

如果集群内所有节点均未配置 tidb_service_scope,所有节点均会执行分布式框架的任务。如果你担心对存量业务有性能影响,可以对其中几个 TiDB 节点设置为 background,只有这些节点才会执行分布式框架的任务。

实例演示

创建测试表,并行运行多个 ADD INDEX 语句,并在执行过程中,执行 DDL 的暂停、恢复。

  • SESSION 1
MySQL [test]> create table t2 (c1 int, c2 int, c3 int);
Query OK, 0 rows affected (0.191 sec)

MySQL [test]> alter table t2 add index idx_c1 (c1), add index idx_c2 (c2), add index idx_c3 (c3), add index idx_c1_c2 (c1, c2), add unique idx_uni_c3 (c3), add primary key (c1), add fulltext (c2);
Query OK, 0 rows affected, 1 warning (8 min 37.725 sec)

Warning (Code 1214): The used table type doesn't support FULLTEXT indexes
  • SESSION 2
MySQL [(none)]> admin show ddl jobs;
+--------+---------+-------------------------+-------------------------------------+----------------------+-----------+----------+-----------+---------------------+---------------------+---------------------+----------+
| JOB_ID | DB_NAME | TABLE_NAME              | JOB_TYPE                            | SCHEMA_STATE         | SCHEMA_ID | TABLE_ID | ROW_COUNT | CREATE_TIME         | START_TIME          | END_TIME            | STATE    |
+--------+---------+-------------------------+-------------------------------------+----------------------+-----------+----------+-----------+---------------------+---------------------+---------------------+----------+
|    107 | test    | t2                      | alter table multi-schema change     | none                 |         2 |      105 |         0 | 2023-12-07 11:15:47 | 2023-12-07 11:15:47 | NULL                | running  |
|    107 | test    | t2                      | add index /* subjob */ /* ingest */ | write reorganization |         2 |      105 |         0 | 2023-12-07 11:15:47 | 2023-12-07 11:15:47 | NULL                | running  |
|    107 | test    | t2                      | add index /* subjob */ /* ingest */ | write reorganization |         2 |      105 |         0 | 2023-12-07 11:15:47 | 2023-12-07 11:15:49 | NULL                | running  |
|    107 | test    | t2                      | add index /* subjob */              | none                 |         2 |      105 |         0 | 2023-12-07 11:15:47 | NULL                | NULL                | queueing |
|    107 | test    | t2                      | add index /* subjob */              | none                 |         2 |      105 |         0 | 2023-12-07 11:15:47 | NULL                | NULL                | queueing |
|    107 | test    | t2                      | add index /* subjob */              | none                 |         2 |      105 |         0 | 2023-12-07 11:15:47 | NULL                | NULL                | queueing |
|    107 | test    | t2                      | add primary key /* subjob */        | none                 |         2 |      105 |         0 | 2023-12-07 11:15:47 | NULL                | NULL                | queueing |
|    106 | test    | t2                      | create table                        | public               |         2 |      105 |         0 | 2023-12-07 11:12:52 | 2023-12-07 11:12:52 | 2023-12-07 11:12:52 | synced   |
...

MySQL [(none)]> ADMIN PAUSE DDL JOBS 107;
+--------+------------+
| JOB_ID | RESULT     |
+--------+------------+
| 107    | successful |
+--------+------------+
1 row in set (2 min 48.559 sec)

MySQL [(none)]> admin show ddl jobs;
+--------+---------+-------------------------+-------------------------------------+----------------------+-----------+----------+-----------+---------------------+---------------------+---------------------+----------+
| JOB_ID | DB_NAME | TABLE_NAME              | JOB_TYPE                            | SCHEMA_STATE         | SCHEMA_ID | TABLE_ID | ROW_COUNT | CREATE_TIME         | START_TIME          | END_TIME            | STATE    |
+--------+---------+-------------------------+-------------------------------------+----------------------+-----------+----------+-----------+---------------------+---------------------+---------------------+----------+
|    107 | test    | t2                      | alter table multi-schema change     | none                 |         2 |      105 |         0 | 2023-12-07 11:15:47 | 2023-12-07 11:15:47 | NULL                | paused   |
|    107 | test    | t2                      | add index /* subjob */ /* ingest */ | write reorganization |         2 |      105 |         0 | 2023-12-07 11:15:47 | 2023-12-07 11:15:47 | NULL                | running  |
|    107 | test    | t2                      | add index /* subjob */ /* ingest */ | write reorganization |         2 |      105 |         0 | 2023-12-07 11:15:47 | 2023-12-07 11:15:49 | NULL                | running  |
|    107 | test    | t2                      | add index /* subjob */ /* ingest */ | write reorganization |         2 |      105 |         0 | 2023-12-07 11:15:47 | 2023-12-07 11:15:50 | NULL                | running  |
|    107 | test    | t2                      | add index /* subjob */ /* ingest */ | write reorganization |         2 |      105 |         0 | 2023-12-07 11:15:47 | 2023-12-07 11:15:51 | NULL                | running  |
|    107 | test    | t2                      | add index /* subjob */              | none                 |         2 |      105 |         0 | 2023-12-07 11:15:47 | NULL                | NULL                | queueing |
|    107 | test    | t2                      | add primary key /* subjob */        | none                 |         2 |      105 |         0 | 2023-12-07 11:15:47 | NULL                | NULL                | queueing |
|    106 | test    | t2                      | create table                        | public               |         2 |      105 |         0 | 2023-12-07 11:12:52 | 2023-12-07 11:12:52 | 2023-12-07 11:12:52 | synced   |
...

MySQL [information_schema]> ADMIN RESUME DDL JOBS 107;
+--------+------------+
| JOB_ID | RESULT     |
+--------+------------+
| 107    | successful |
+--------+------------+
1 row in set (0.024 sec)

DDL: IMPORT INTO

IMPORT INTO 语句使用 TiDB Lightning 的物理导入模式,用于将 CSV、SQL、PARQUET 等格式的数据导入到 TiDB 的一张空表中。

IMPORT INTO 支持导入存储在 Amazon S3、GCS、Azure Blob Storage 和 TiDB 本地的数据文件。

在 v7.5.0 中,IMPORT INTO SQL 语句正式 GA。这种导入方式无需单独部署和管理 TiDB Lightning,在降低了数据导入难度的同时,大幅提升了数据导入效率。

实例演示

演示将表数据导出到本地文件,创建新表,并使用 IMPORT INTO 语句将数据导入。

MySQL [test]> SELECT * FROM t1 INTO OUTFILE '/tmp/t1.csv' FIELDS TERMINATED BY ',' ENCLOSED BY '"';
Query OK, 2 rows affected (0.004 sec)

MySQL [test]> \! cat /tmp/t1.csv
"1","1","1"
"1","2","3"

MySQL [test]> create table t1_1 like t1;
Query OK, 0 rows affected (0.375 sec)

MySQL [test]> IMPORT INTO t1_1 FROM '/tmp/t1.csv';
+--------+-------------+---------------+----------+-------+----------+------------------+---------------+----------------+----------------------------+----------------------------+----------------------------+------------+
| Job_ID | Data_Source | Target_Table  | Table_ID | Phase | Status   | Source_File_Size | Imported_Rows | Result_Message | Create_Time                | Start_Time                 | End_Time                   | Created_By |
+--------+-------------+---------------+----------+-------+----------+------------------+---------------+----------------+----------------------------+----------------------------+----------------------------+------------+
|      2 | /tmp/t1.csv | `test`.`t1_1` |      110 |       | finished | 24B              |             2 |                | 2023-12-07 11:59:36.500342 | 2023-12-07 11:59:39.038744 | 2023-12-07 11:59:45.550724 | root@%     |
+--------+-------------+---------------+----------+-------+----------+------------------+---------------+----------------+----------------------------+----------------------------+----------------------------+------------+
1 row in set (9.382 sec)

MySQL [test]> select * from t1_1;
+------+------+------+
| c1   | c2   | c3   |
+------+------+------+
|    1 |    1 |    1 |
|    1 |    2 |    3 |
+------+------+------+
2 rows in set (0.013 sec)

全局变量、配置参数对比 v7.1.2 vs v7.5.0

关于 TiDB Server 的系统变量和配置参数,可从 Release Notes 获取信息,官方文档中,更直接的办法是用工具直接对比。

下面将列举 v7.1.2 和 v7.5.0 两个版本的全局变量、配置参数差异。感谢 @人如其名 贡献的“炒鸡”好用小工具。

对比结果如下:

no-alt

no-alt

全局系统变量变更 24 项,tidb-server 配置参数新增 6 项。全局系统变量变更 5 项,tidb-server 配置参数变更 3 项。合计,38 项。

此外, 需要注意的是,如下系统变量已被废弃,请勿使用。

  • tidb_enable_fast_analyze
  • tidb_enable_tiflash_pipeline_model
MySQL [(none)]> set global tidb_enable_fast_analyze=1;
Query OK, 0 rows affected, 1 warning (0.071 sec)

Warning (Code 1105): the fast analyze feature has already been removed in TiDB v7.5.0, so this will have no effect
MySQL [(none)]>
MySQL [(none)]> set global tidb_enable_tiflash_pipeline_model=1;
Query OK, 0 rows affected, 1 warning (0.013 sec)

Warning (Code 1681): tidb_enable_tiflash_pipeline_model is deprecated and will be removed in a future release.

尾声

今年第二个 LTS 版本 TiDB v7.5.0 LTS 已发布上线,欢迎各位 TiDBer 来尝鲜、试用、推生产、升级生产。

参考阅读

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部