前言
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 尚未发版。
本文作为前文的补充,来观察一下该版本中的其他新特性。
版本选择
前文中的彩蛋,这里更新了一下 TiDB v7.5.0 LTS 的发版日期。
关于生产环境版本的选择,是论坛里经常讨论的问题,如果明年有项目上线,又期望使用到新特性,那么 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 INDEX
或 IMPORT INTO
任务可能占用大量 TiDB 节点的资源,从而导致集群性能下降。为了避免对已有业务造成性能影响,v7.4.0 以实验特性引入了变量 tidb_service_scope
,用于控制 TiDB 后端任务分布式框架 下各 TiDB 节点的服务范围。你可以从现有 TiDB 节点中选择几个节点,或者对新增 TiDB 节点设置服务范围,所有分布式执行的 ADD INDEX
和 IMPORT 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 两个版本的全局变量、配置参数差异。感谢 @人如其名 贡献的“炒鸡”好用小工具。
对比结果如下:
全局系统变量变更 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 来尝鲜、试用、推生产、升级生产。