diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index b8105d16a8a0..9bd160c060b0 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -1,198 +1,199 @@ ---- -title: TiDB 最佳实践 -aliases: ['/docs-cn/dev/best-practices/tidb-best-practices/'] ---- - -# TiDB 最佳实践 - -本文档总结使用 TiDB 时的一些最佳实践，主要涉及 SQL 使用和 OLAP/OLTP 优化技巧，特别是一些 TiDB 专有的优化开关。 - -建议先阅读讲解 TiDB 原理的三篇文章（[讲存储](https://pingcap.com/blog-cn/tidb-internal-1/)，[说计算](https://pingcap.com/blog-cn/tidb-internal-2/)，[谈调度](https://pingcap.com/blog-cn/tidb-internal-3/)），再来看这篇文章。 - -## 前言 - -数据库是一个通用的基础组件，在开发过程中会考虑到多种目标场景，在具体的业务场景中，需要根据业务的实际情况对数据的参数或者使用方式进行调整。 - -TiDB 是一个兼容 MySQL 协议和语法的分布式数据库，但是由于其内部实现，特别是支持分布式存储以及分布式事务，使得一些使用方法和 MySQL 有所区别。 - -## 基本概念 - -TiDB 的最佳实践与其实现原理密切相关，建议读者先了解一些基本的实现机制，包括 Raft、分布式事务、数据分片、负载均衡、SQL 到 KV 的映射方案、二级索引的实现方法、分布式执行引擎。下面会做一点简单的介绍，更详细的信息可以参考 PingCAP 公众号以及知乎专栏的一些文章。 - -### Raft - -Raft 是一种一致性协议，能提供强一致的数据复制保证，TiDB 最底层用 Raft 来同步数据。每次写入都要写入多数副本，才能对外返回成功，这样即使丢掉少数副本，也能保证系统中还有最新的数据。比如最大 3 副本的话，每次写入 2 副本才算成功，任何时候，只丢失一个副本的情况下，存活的两个副本中至少有一个具有最新的数据。 - -相比 Master-Slave 方式的同步，同样是保存三副本，Raft 的方式更为高效，写入的延迟取决于最快的两个副本，而不是最慢的那个副本。所以使用 Raft 同步的情况下，异地多活成为可能。在典型的两地三中心场景下，每次写入只需要本数据中心以及离得近的一个数据中心写入成功就能保证数据的一致性，而并不需要三个数据中心都写成功。但是这并不意味着在任何场景都能构建跨机房部署的业务，当写入量比较大时候，机房之间的带宽和延迟成为关键因素，如果写入速度超过机房之间的带宽，或者是机房之间延迟过大，整个 Raft 同步机制依然无法很好的运转。 - -### 分布式事务 - -TiDB 提供完整的分布式事务，事务模型是在 [Google Percolator](https://research.google.com/pubs/pub36726.html) 的基础上做了一些优化。具体的实现可以参考[《Percolator 和 TiDB 事务算法》](https://pingcap.com/blog-cn/percolator-and-txn/)这篇文章。本文档只讨论以下几点： - -+ 乐观锁 - - TiDB 的乐观事务模型，只有在真正提交的时候，才会做冲突检测。如果有冲突，则需要重试。这种模型在冲突严重的场景下，会比较低效，因为重试之前的操作都是无效的，需要重复做。举一个比较极端的例子，就是把数据库当做计数器用，如果访问的并发度比较高，那么一定会有严重的冲突，导致大量的重试甚至是超时。但是如果访问冲突并不十分严重，那么乐观锁模型具备较高的效率。在冲突严重的场景下，推荐使用悲观锁，或在系统架构层面解决问题，比如将计数器放在 Redis 中。 - -+ 悲观锁 - - TiDB 的悲观事务模式，悲观事务的行为和 MySQL 基本一致，在执行阶段就会上锁，先到先得，避免冲突情况下的重试，可以保证有较多冲突的事务的成功率。悲观锁同时解决了希望通过 `select for update` 对数据提前锁定的场景。但如果业务场景本身冲突较少，乐观锁的性能会更有优势。 - -+ 事务大小限制 - - 由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，会使得提交过程非常慢，并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况，我们对事务的大小做了限制： - - - 单个事务包含的 SQL 语句不超过 5000 条（默认） - - 单条 KV entry 不超过 6MB（默认） - - KV entry 的总大小不超过 10G - - 在 Google 的 Cloud Spanner 上面，也有[类似的限制](https://cloud.google.com/spanner/docs/limits)。 - -### 数据分片 - -TiKV 自动将底层数据按照 Key 的 Range 进行分片。每个 Region 是一个 Key 的范围，从 `StartKey` 到 `EndKey` 的左闭右开区间。Region 中的 Key-Value 总量超过一定值，就会自动分裂。这部分用户不需要担心。 - -### 负载均衡 - -PD 会根据整个 TiKV 集群的状态，对集群的负载进行调度。调度是以 Region 为单位，以 PD 配置的策略为调度逻辑，自动完成。 - -### SQL on KV - -TiDB 自动将 SQL 结构映射为 KV 结构。具体的可以参考[《三篇文章了解 TiDB 技术内幕 - 说计算》](https://pingcap.com/blog-cn/tidb-internal-2/)这篇文档。简单来说，TiDB 执行了以下操作： - -+ 一行数据映射为一个 KV，Key 以 `TableID` 构造前缀，以行 ID 为后缀 -+ 一条索引映射为一个 KV，Key 以 `TableID+IndexID` 构造前缀，以索引值构造后缀 - -可以看到，对于一个表中的数据或者索引，会具有相同的前缀，这样在 TiKV 的 Key 空间内，这些 Key-Value 会在相邻的位置。那么当写入量很大，并且集中在一个表上面时，就会造成写入的热点，特别是连续写入的数据中某些索引值也是连续的（比如 update time 这种按时间递增的字段），会在很少的几个 Region 上形成写入热点，成为整个系统的瓶颈。同样，如果所有的数据读取操作也都集中在很小的一个范围内（比如在连续的几万或者十几万行数据上），那么可能造成数据的访问热点。 - -### 二级索引 - -TiDB 支持完整的二级索引，并且是全局索引，很多查询可以通过索引来优化。如果利用好二级索引，对业务非常重要，很多 MySQL 上的经验在 TiDB 这里依然适用，不过 TiDB 还有一些自己的特点，需要注意，这一节主要讨论在 TiDB 上使用二级索引的一些注意事项。 - -+ 二级索引是否越多越好 - - 二级索引能加速查询，但是要注意新增一个索引是有副作用的。上一节介绍了索引的存储模型，那么每增加一个索引，在插入一条数据的时候，就要新增一个 Key-Value，所以索引越多，写入越慢，并且空间占用越大。另外过多的索引也会影响优化器运行时间，并且不合适的索引会误导优化器。所以索引并不是越多越好。 - -+ 对哪些列建索引比较合适 - - 上文提到，索引很重要但不是越多越好，因此需要根据具体的业务特点创建合适的索引。原则上需要对查询中需要用到的列创建索引，目的是提高性能。下面几种情况适合创建索引： - - - 区分度比较大的列，通过索引能显著地减少过滤后的行数 - - 有多个查询条件时，可以选择组合索引，注意需要把等值条件的列放在组合索引的前面 - - 这里举一个例子，假设常用的查询是 `select * from t where c1 = 10 and c2 = 100 and c3 > 10`，那么可以考虑建立组合索引 `Index cidx (c1, c2, c3)`，这样可以用查询条件构造出一个索引前缀进行 Scan。 - -+ 通过索引查询和直接扫描 Table 的区别 - - TiDB 实现了全局索引，所以索引和 Table 中的数据并不一定在一个数据分片上。通过索引查询的时候，需要先扫描索引，得到对应的行 ID，然后通过行 ID 去取数据，所以可能会涉及到两次网络请求，会有一定的性能开销。 - - 如果查询涉及到大量的行，那么扫描索引是并发进行，只要第一批结果已经返回，就可以开始去取 Table 的数据，所以这里是一个并行 + Pipeline 的模式，虽然有两次访问的开销，但是延迟并不会很大。 - - 以下情况不会涉及到两次访问的问题： - - - 索引中的列已经满足了查询需求。比如 Table `t` 上面的列 `c` 有索引，查询是 `select c from t where c > 10;`，这个时候，只需要访问索引，就可以拿到所需要的全部数据。这种情况称之为覆盖索引 (Covering Index)。所以如果很关注查询性能，可以将部分不需要过滤但是需要在查询结果中返回的列放入索引中，构造成组合索引，比如这个例子：`select c1, c2 from t where c1 > 10;`，要优化这个查询可以创建组合索引 `Index c12 (c1, c2)`。 - - 表的 Primary Key 是整数类型。在这种情况下，TiDB 会将 Primary Key 的值当做行 ID，所以如果查询条件是在 PK 上面，那么可以直接构造出行 ID 的范围，直接扫描 Table 数据，获取结果。 - -+ 查询并发度 - - 数据分散在很多 Region 上，所以 TiDB 在做查询的时候会并发进行，默认的并发度比较保守，因为过高的并发度会消耗大量的系统资源，且对于 OLTP 类型的查询，往往不会涉及到大量的数据，较低的并发度已经可以满足需求。对于 OLAP 类型的 Query，往往需要较高的并发度。所以 TiDB 支持通过 System Variable 来调整查询并发度。 - - - [tidb_distsql_scan_concurrency](/system-variables.md#tidb_distsql_scan_concurrency) - - 在进行扫描数据的时候的并发度，这里包括扫描 Table 以及索引数据。 - - - [tidb_index_lookup_size](/system-variables.md#tidb_index_lookup_size) - - 如果是需要访问索引获取行 ID 之后再访问 Table 数据，那么每次会把一批行 ID 作为一次请求去访问 Table 数据，这个参数可以设置 Batch 的大小，较大的 Batch 会使得延迟增加，较小的 Batch 可能会造成更多的查询次数。这个参数的合适大小与查询涉及的数据量有关。一般不需要调整。 - - - [tidb_index_lookup_concurrency](/system-variables.md#tidb_index_lookup_concurrency) - - 如果是需要访问索引获取行 ID 之后再访问 Table 数据，每次通过行 ID 获取数据时候的并发度通过这个参数调节。 - -+ 通过索引保证结果顺序 - - 索引除了可以用来过滤数据之外，还能用来对数据排序，首先按照索引的顺序获取行 ID，然后再按照行 ID 的返回顺序返回行的内容，这样可以保证返回结果按照索引列有序。前面提到了扫索引和获取 Row 之间是并行 + Pipeline 模式，如果要求按照索引的顺序返回 Row，那么这两次查询之间的并发度设置的太高并不会降低延迟，所以默认的并发度比较保守。可以通过 [tidb_index_serial_scan_concurrency](/system-variables.md#tidb_index_serial_scan_concurrency) 变量进行并发度调整。 - -+ 逆序索引 - - 目前 TiDB 支持对索引进行逆序 Scan，目前速度比顺序 Scan 慢一些，通常情况下慢 20%，在数据频繁修改造成版本较多的情况下，会慢的更多。如果可能，建议避免对索引的逆序 Scan。 - -## 场景与实践 - -上一节我们讨论了一些 TiDB 基本的实现机制及其对使用带来的影响，本节我们从具体的使用场景出发，谈一些更为具体的操作实践。我们以从部署到支撑业务这条链路为序，进行讨论。 - -### 部署 - -在部署之前请务必阅读 [TiDB 部署建议以及对硬件的需求](/hardware-and-software-requirements.md)。 - -推荐通过 [TiUP](/production-deployment-using-tiup.md) 部署 TiDB 集群，这个工具可以部署、停止、销毁、升级整个集群，非常方便易用。非常不推荐手动部署，后期的维护和升级会很麻烦。 - -### 导入数据 - -为了提高导入数据期间的写入性能，可以对 TiKV 的参数进行调优，具体的文档查看 [TiKV 性能参数调优](/tune-tikv-memory-performance.md)。 - -### 写入 - -上面提到了 TiDB 对单个事务的大小有限制，这层限制是在 KV 层面，反映在 SQL 层面的话，简单来说一行数据会映射为一个 KV entry，每多一个索引，也会增加一个 KV entry。 - -> **注意：** -> -> 对事务的大小限制，要考虑 TiDB 做编码以及事务额外 Key 的开销，在使用的时候，**建议每个事务的行数不超过 200 行，且单行数据小于 100k**，否则可能性能不佳。 - -建议无论是 Insert，Update 还是 Delete 语句，都通过分 Batch 或者是加 Limit 的方式限制。 - -在删除大量数据的时候，建议使用 `Delete from t where xx limit 5000;` 这样的方案，通过循环来删除，用 `Affected Rows == 0` 作为循环结束条件。 - -如果一次删除的数据量非常大，这种循环的方式会越来越慢，因为每次删除都是从前向后遍历，前面的删除之后，短时间内会残留不少删除标记（后续会被 GC 清理掉），影响后面的 `Delete` 语句。如果有可能，建议把 `Where` 条件细化。举个例子，假设要删除 2017-05-26 当天的所有数据，那么可以这样做： - -```SQL -for i from 0 to 23: - while affected_rows > 0: - delete from t where insert_time >= i:00:00 and insert_time < (i+1):00:00 limit 5000; - affected_rows = select affected_rows() -``` - -上面是一段伪代码，意思就是要把大块的数据拆成小块删除，以避免删除过程中前面的 Delete 语句影响后面的 Delete 语句。 - -### 查询 - -看业务的查询需求以及具体的语句，可以参考 [TiDB 专用系统变量和语法](/system-variables.md)这篇文档。可以通过 SET 语句控制 SQL 执行的并发度，另外通过 Hint 控制 Join 物理算子选择。 - -另外 MySQL 标准的索引选择 Hint 语法，也可以用，通过 `Use Index/Ignore Index hint` 控制优化器选择索引。 - -如果是个 OLTP 和 OLAP 混合类型的业务，可以把 TP 请求和 AP 请求发送到不同的 tidb-server 上，这样能够减小 AP 业务对于 TP 业务的影响。 承载 AP 业务的 tidb-server 推荐使用高配的机器，比如 CPU 核数比较多，内存比较大。 - -但彻底的隔离 OLTP 和 OLAP，推荐将 OLAP 的业务跑在 TiFlash 上。TiFlash 是列存引擎，在 OLAP 的分析查询场景上，性能极具亮点，TiFlash 可以在存储层上做到物理隔离，并可做到一致性读取。 - -### 监控和日志 - -Metrics 系统是了解系统状态的最佳方法，建议所有的用户都部署监控系统。 - -TiDB [使用 Grafana + Prometheus 监控系统状态](/tidb-monitoring-framework.md)。如果使用 TiUP 部署集群，那么会自动部署和配置监控系统。 - -监控系统中的监控项很多，大部分是给 TiDB 开发者查看的内容，如果没有对源代码比较深入的了解，并没有必要了解这些监控项。我们会精简出一些和业务相关或者是系统关键组件状态相关的监控项，放在一个独立的 `overview` 面板中，供用户使用。 - -除了监控之外，查看日志也是了解系统状态的常用方法。TiDB 的三个组件 tidb-server/tikv-server/pd-server 都有一个 `--log-file` 的参数。如果启动的时候设置了这个参数，那么日志会保存着参数所设置的文件的位置，另外会自动的按天对 Log 文件做归档。如果没有设置 `--log-file` 参数，日志会输出在 `stderr` 中。 - -从 4.0 版本开始，从解决易用性的角度出发，提供了 [TiDB Dashboard](/dashboard/dashboard-intro.md) UI 系统，通过浏览器访问 `http://PD_IP:PD_PORT/dashboard` 即可打开 TiDB Dashboard。TiDB Dashboard 可以提供集群状态、性能分析、流量可视化、SQL 诊断、日志搜索等功能。 - -### 文档 - -了解一个系统或者解决使用中的问题最好的方法是阅读文档，明白实现原理。TiDB 有大量的官方文档，希望大家在遇到问题的时候能先尝试通过文档或者搜索 Issue list 寻找解决方案。官方文档查看 [docs-cn](https://github.com/pingcap/docs-cn)。如果希望阅读英文文档，可以查看 [docs](https://github.com/pingcap/docs)。 - -其中的 [FAQ](/faq/tidb-faq.md) 和[故障诊断](/troubleshoot-tidb-cluster.md)章节建议大家仔细阅读。另外 TiDB 还有一些不错的工具，也有配套的文档，具体的见各项工具的 GitHub 页面。 - -除了文档之外，还有很多不错的文章介绍 TiDB 的各项技术细节内幕，大家可以关注下面这些文章发布渠道： - -+ 公众号：微信搜索 PingCAP -+ 知乎专栏：[TiDB 的后花园](https://zhuanlan.zhihu.com/newsql) -+ [官方博客](https://pingcap.com/blog-cn/) - -## TiDB 的最佳适用场景 - -简单来说，TiDB 适合具备下面这些特点的场景： - -+ 数据量大，单机保存不下 -+ 不希望做 Sharding 或者懒得做 Sharding -+ 访问模式上没有明显的热点 -+ 需要事务、需要强一致、需要灾备 -+ 希望 Real-Time HTAP，减少存储链路 +--- +title: TiDB 最佳实践 +aliases: ['/docs-cn/dev/best-practices/tidb-best-practices/'] +summary: TiDB 最佳实践总结了使用 TiDB 的一些优化技巧，包括 Raft 一致性协议、分布式事务、数据分片、负载均衡、SQL 到 KV 的映射方案、二级索引的实现方法等。建议阅读官方文档和知乎专栏了解更多细节。部署时推荐使用 TiUP，导入数据时可对 TiKV 参数进行调优。在写入和查询时需注意事务大小限制和并发度设置。监控系统和日志查看也是了解系统状态的重要方法。适用场景包括数据量大、不希望做 Sharding、需要事务和强一致性等。 +--- + +# TiDB 最佳实践 + +本文档总结使用 TiDB 时的一些最佳实践，主要涉及 SQL 使用和 OLAP/OLTP 优化技巧，特别是一些 TiDB 专有的优化开关。 + +建议先阅读讲解 TiDB 原理的三篇文章（[讲存储](https://pingcap.com/blog-cn/tidb-internal-1/)，[说计算](https://pingcap.com/blog-cn/tidb-internal-2/)，[谈调度](https://pingcap.com/blog-cn/tidb-internal-3/)），再来看这篇文章。 + +## 前言 + +数据库是一个通用的基础组件，在开发过程中会考虑到多种目标场景，在具体的业务场景中，需要根据业务的实际情况对数据的参数或者使用方式进行调整。 + +TiDB 是一个兼容 MySQL 协议和语法的分布式数据库，但是由于其内部实现，特别是支持分布式存储以及分布式事务，使得一些使用方法和 MySQL 有所区别。 + +## 基本概念 + +TiDB 的最佳实践与其实现原理密切相关，建议读者先了解一些基本的实现机制，包括 Raft、分布式事务、数据分片、负载均衡、SQL 到 KV 的映射方案、二级索引的实现方法、分布式执行引擎。下面会做一点简单的介绍，更详细的信息可以参考 PingCAP 公众号以及知乎专栏的一些文章。 + +### Raft + +Raft 是一种一致性协议，能提供强一致的数据复制保证，TiDB 最底层用 Raft 来同步数据。每次写入都要写入多数副本，才能对外返回成功，这样即使丢掉少数副本，也能保证系统中还有最新的数据。比如最大 3 副本的话，每次写入 2 副本才算成功，任何时候，只丢失一个副本的情况下，存活的两个副本中至少有一个具有最新的数据。 + +相比 Master-Slave 方式的同步，同样是保存三副本，Raft 的方式更为高效，写入的延迟取决于最快的两个副本，而不是最慢的那个副本。所以使用 Raft 同步的情况下，异地多活成为可能。在典型的两地三中心场景下，每次写入只需要本数据中心以及离得近的一个数据中心写入成功就能保证数据的一致性，而并不需要三个数据中心都写成功。但是这并不意味着在任何场景都能构建跨机房部署的业务，当写入量比较大时候，机房之间的带宽和延迟成为关键因素，如果写入速度超过机房之间的带宽，或者是机房之间延迟过大，整个 Raft 同步机制依然无法很好的运转。 + +### 分布式事务 + +TiDB 提供完整的分布式事务，事务模型是在 [Google Percolator](https://research.google.com/pubs/pub36726.html) 的基础上做了一些优化。具体的实现可以参考[《Percolator 和 TiDB 事务算法》](https://pingcap.com/blog-cn/percolator-and-txn/)这篇文章。本文档只讨论以下几点： + ++ 乐观锁 + + TiDB 的乐观事务模型，只有在真正提交的时候，才会做冲突检测。如果有冲突，则需要重试。这种模型在冲突严重的场景下，会比较低效，因为重试之前的操作都是无效的，需要重复做。举一个比较极端的例子，就是把数据库当做计数器用，如果访问的并发度比较高，那么一定会有严重的冲突，导致大量的重试甚至是超时。但是如果访问冲突并不十分严重，那么乐观锁模型具备较高的效率。在冲突严重的场景下，推荐使用悲观锁，或在系统架构层面解决问题，比如将计数器放在 Redis 中。 + ++ 悲观锁 + + TiDB 的悲观事务模式，悲观事务的行为和 MySQL 基本一致，在执行阶段就会上锁，先到先得，避免冲突情况下的重试，可以保证有较多冲突的事务的成功率。悲观锁同时解决了希望通过 `select for update` 对数据提前锁定的场景。但如果业务场景本身冲突较少，乐观锁的性能会更有优势。 + ++ 事务大小限制 + + 由于分布式事务要做两阶段提交，并且底层还需要做 Raft 复制，如果一个事务非常大，会使得提交过程非常慢，并且会卡住下面的 Raft 复制流程。为了避免系统出现被卡住的情况，我们对事务的大小做了限制： + + - 单个事务包含的 SQL 语句不超过 5000 条（默认） + - 单条 KV entry 不超过 6MB（默认） + - KV entry 的总大小不超过 10G + + 在 Google 的 Cloud Spanner 上面，也有[类似的限制](https://cloud.google.com/spanner/docs/limits)。 + +### 数据分片 + +TiKV 自动将底层数据按照 Key 的 Range 进行分片。每个 Region 是一个 Key 的范围，从 `StartKey` 到 `EndKey` 的左闭右开区间。Region 中的 Key-Value 总量超过一定值，就会自动分裂。这部分用户不需要担心。 + +### 负载均衡 + +PD 会根据整个 TiKV 集群的状态，对集群的负载进行调度。调度是以 Region 为单位，以 PD 配置的策略为调度逻辑，自动完成。 + +### SQL on KV + +TiDB 自动将 SQL 结构映射为 KV 结构。具体的可以参考[《三篇文章了解 TiDB 技术内幕 - 说计算》](https://pingcap.com/blog-cn/tidb-internal-2/)这篇文档。简单来说，TiDB 执行了以下操作： + ++ 一行数据映射为一个 KV，Key 以 `TableID` 构造前缀，以行 ID 为后缀 ++ 一条索引映射为一个 KV，Key 以 `TableID+IndexID` 构造前缀，以索引值构造后缀 + +可以看到，对于一个表中的数据或者索引，会具有相同的前缀，这样在 TiKV 的 Key 空间内，这些 Key-Value 会在相邻的位置。那么当写入量很大，并且集中在一个表上面时，就会造成写入的热点，特别是连续写入的数据中某些索引值也是连续的（比如 update time 这种按时间递增的字段），会在很少的几个 Region 上形成写入热点，成为整个系统的瓶颈。同样，如果所有的数据读取操作也都集中在很小的一个范围内（比如在连续的几万或者十几万行数据上），那么可能造成数据的访问热点。 + +### 二级索引 + +TiDB 支持完整的二级索引，并且是全局索引，很多查询可以通过索引来优化。如果利用好二级索引，对业务非常重要，很多 MySQL 上的经验在 TiDB 这里依然适用，不过 TiDB 还有一些自己的特点，需要注意，这一节主要讨论在 TiDB 上使用二级索引的一些注意事项。 + ++ 二级索引是否越多越好 + + 二级索引能加速查询，但是要注意新增一个索引是有副作用的。上一节介绍了索引的存储模型，那么每增加一个索引，在插入一条数据的时候，就要新增一个 Key-Value，所以索引越多，写入越慢，并且空间占用越大。另外过多的索引也会影响优化器运行时间，并且不合适的索引会误导优化器。所以索引并不是越多越好。 + ++ 对哪些列建索引比较合适 + + 上文提到，索引很重要但不是越多越好，因此需要根据具体的业务特点创建合适的索引。原则上需要对查询中需要用到的列创建索引，目的是提高性能。下面几种情况适合创建索引： + + - 区分度比较大的列，通过索引能显著地减少过滤后的行数 + - 有多个查询条件时，可以选择组合索引，注意需要把等值条件的列放在组合索引的前面 + + 这里举一个例子，假设常用的查询是 `select * from t where c1 = 10 and c2 = 100 and c3 > 10`，那么可以考虑建立组合索引 `Index cidx (c1, c2, c3)`，这样可以用查询条件构造出一个索引前缀进行 Scan。 + ++ 通过索引查询和直接扫描 Table 的区别 + + TiDB 实现了全局索引，所以索引和 Table 中的数据并不一定在一个数据分片上。通过索引查询的时候，需要先扫描索引，得到对应的行 ID，然后通过行 ID 去取数据，所以可能会涉及到两次网络请求，会有一定的性能开销。 + + 如果查询涉及到大量的行，那么扫描索引是并发进行，只要第一批结果已经返回，就可以开始去取 Table 的数据，所以这里是一个并行 + Pipeline 的模式，虽然有两次访问的开销，但是延迟并不会很大。 + + 以下情况不会涉及到两次访问的问题： + + - 索引中的列已经满足了查询需求。比如 Table `t` 上面的列 `c` 有索引，查询是 `select c from t where c > 10;`，这个时候，只需要访问索引，就可以拿到所需要的全部数据。这种情况称之为覆盖索引 (Covering Index)。所以如果很关注查询性能，可以将部分不需要过滤但是需要在查询结果中返回的列放入索引中，构造成组合索引，比如这个例子：`select c1, c2 from t where c1 > 10;`，要优化这个查询可以创建组合索引 `Index c12 (c1, c2)`。 + - 表的 Primary Key 是整数类型。在这种情况下，TiDB 会将 Primary Key 的值当做行 ID，所以如果查询条件是在 PK 上面，那么可以直接构造出行 ID 的范围，直接扫描 Table 数据，获取结果。 + ++ 查询并发度 + + 数据分散在很多 Region 上，所以 TiDB 在做查询的时候会并发进行，默认的并发度比较保守，因为过高的并发度会消耗大量的系统资源，且对于 OLTP 类型的查询，往往不会涉及到大量的数据，较低的并发度已经可以满足需求。对于 OLAP 类型的 Query，往往需要较高的并发度。所以 TiDB 支持通过 System Variable 来调整查询并发度。 + + - [tidb_distsql_scan_concurrency](/system-variables.md#tidb_distsql_scan_concurrency) + + 在进行扫描数据的时候的并发度，这里包括扫描 Table 以及索引数据。 + + - [tidb_index_lookup_size](/system-variables.md#tidb_index_lookup_size) + + 如果是需要访问索引获取行 ID 之后再访问 Table 数据，那么每次会把一批行 ID 作为一次请求去访问 Table 数据，这个参数可以设置 Batch 的大小，较大的 Batch 会使得延迟增加，较小的 Batch 可能会造成更多的查询次数。这个参数的合适大小与查询涉及的数据量有关。一般不需要调整。 + + - [tidb_index_lookup_concurrency](/system-variables.md#tidb_index_lookup_concurrency) + + 如果是需要访问索引获取行 ID 之后再访问 Table 数据，每次通过行 ID 获取数据时候的并发度通过这个参数调节。 + ++ 通过索引保证结果顺序 + + 索引除了可以用来过滤数据之外，还能用来对数据排序，首先按照索引的顺序获取行 ID，然后再按照行 ID 的返回顺序返回行的内容，这样可以保证返回结果按照索引列有序。前面提到了扫索引和获取 Row 之间是并行 + Pipeline 模式，如果要求按照索引的顺序返回 Row，那么这两次查询之间的并发度设置的太高并不会降低延迟，所以默认的并发度比较保守。可以通过 [tidb_index_serial_scan_concurrency](/system-variables.md#tidb_index_serial_scan_concurrency) 变量进行并发度调整。 + ++ 逆序索引 + + 目前 TiDB 支持对索引进行逆序 Scan，目前速度比顺序 Scan 慢一些，通常情况下慢 20%，在数据频繁修改造成版本较多的情况下，会慢的更多。如果可能，建议避免对索引的逆序 Scan。 + +## 场景与实践 + +上一节我们讨论了一些 TiDB 基本的实现机制及其对使用带来的影响，本节我们从具体的使用场景出发，谈一些更为具体的操作实践。我们以从部署到支撑业务这条链路为序，进行讨论。 + +### 部署 + +在部署之前请务必阅读 [TiDB 部署建议以及对硬件的需求](/hardware-and-software-requirements.md)。 + +推荐通过 [TiUP](/production-deployment-using-tiup.md) 部署 TiDB 集群，这个工具可以部署、停止、销毁、升级整个集群，非常方便易用。非常不推荐手动部署，后期的维护和升级会很麻烦。 + +### 导入数据 + +为了提高导入数据期间的写入性能，可以对 TiKV 的参数进行调优，具体的文档查看 [TiKV 性能参数调优](/tune-tikv-memory-performance.md)。 + +### 写入 + +上面提到了 TiDB 对单个事务的大小有限制，这层限制是在 KV 层面，反映在 SQL 层面的话，简单来说一行数据会映射为一个 KV entry，每多一个索引，也会增加一个 KV entry。 + +> **注意：** +> +> 对事务的大小限制，要考虑 TiDB 做编码以及事务额外 Key 的开销，在使用的时候，**建议每个事务的行数不超过 200 行，且单行数据小于 100k**，否则可能性能不佳。 + +建议无论是 Insert，Update 还是 Delete 语句，都通过分 Batch 或者是加 Limit 的方式限制。 + +在删除大量数据的时候，建议使用 `Delete from t where xx limit 5000;` 这样的方案，通过循环来删除，用 `Affected Rows == 0` 作为循环结束条件。 + +如果一次删除的数据量非常大，这种循环的方式会越来越慢，因为每次删除都是从前向后遍历，前面的删除之后，短时间内会残留不少删除标记（后续会被 GC 清理掉），影响后面的 `Delete` 语句。如果有可能，建议把 `Where` 条件细化。举个例子，假设要删除 2017-05-26 当天的所有数据，那么可以这样做： + +```SQL +for i from 0 to 23: + while affected_rows > 0: + delete from t where insert_time >= i:00:00 and insert_time < (i+1):00:00 limit 5000; + affected_rows = select affected_rows() +``` + +上面是一段伪代码，意思就是要把大块的数据拆成小块删除，以避免删除过程中前面的 Delete 语句影响后面的 Delete 语句。 + +### 查询 + +看业务的查询需求以及具体的语句，可以参考 [TiDB 专用系统变量和语法](/system-variables.md)这篇文档。可以通过 SET 语句控制 SQL 执行的并发度，另外通过 Hint 控制 Join 物理算子选择。 + +另外 MySQL 标准的索引选择 Hint 语法，也可以用，通过 `Use Index/Ignore Index hint` 控制优化器选择索引。 + +如果是个 OLTP 和 OLAP 混合类型的业务，可以把 TP 请求和 AP 请求发送到不同的 tidb-server 上，这样能够减小 AP 业务对于 TP 业务的影响。 承载 AP 业务的 tidb-server 推荐使用高配的机器，比如 CPU 核数比较多，内存比较大。 + +但彻底的隔离 OLTP 和 OLAP，推荐将 OLAP 的业务跑在 TiFlash 上。TiFlash 是列存引擎，在 OLAP 的分析查询场景上，性能极具亮点，TiFlash 可以在存储层上做到物理隔离，并可做到一致性读取。 + +### 监控和日志 + +Metrics 系统是了解系统状态的最佳方法，建议所有的用户都部署监控系统。 + +TiDB [使用 Grafana + Prometheus 监控系统状态](/tidb-monitoring-framework.md)。如果使用 TiUP 部署集群，那么会自动部署和配置监控系统。 + +监控系统中的监控项很多，大部分是给 TiDB 开发者查看的内容，如果没有对源代码比较深入的了解，并没有必要了解这些监控项。我们会精简出一些和业务相关或者是系统关键组件状态相关的监控项，放在一个独立的 `overview` 面板中，供用户使用。 + +除了监控之外，查看日志也是了解系统状态的常用方法。TiDB 的三个组件 tidb-server/tikv-server/pd-server 都有一个 `--log-file` 的参数。如果启动的时候设置了这个参数，那么日志会保存着参数所设置的文件的位置，另外会自动的按天对 Log 文件做归档。如果没有设置 `--log-file` 参数，日志会输出在 `stderr` 中。 + +从 4.0 版本开始，从解决易用性的角度出发，提供了 [TiDB Dashboard](/dashboard/dashboard-intro.md) UI 系统，通过浏览器访问 `http://PD_IP:PD_PORT/dashboard` 即可打开 TiDB Dashboard。TiDB Dashboard 可以提供集群状态、性能分析、流量可视化、SQL 诊断、日志搜索等功能。 + +### 文档 + +了解一个系统或者解决使用中的问题最好的方法是阅读文档，明白实现原理。TiDB 有大量的官方文档，希望大家在遇到问题的时候能先尝试通过文档或者搜索 Issue list 寻找解决方案。官方文档查看 [docs-cn](https://github.com/pingcap/docs-cn)。如果希望阅读英文文档，可以查看 [docs](https://github.com/pingcap/docs)。 + +其中的 [FAQ](/faq/tidb-faq.md) 和[故障诊断](/troubleshoot-tidb-cluster.md)章节建议大家仔细阅读。另外 TiDB 还有一些不错的工具，也有配套的文档，具体的见各项工具的 GitHub 页面。 + +除了文档之外，还有很多不错的文章介绍 TiDB 的各项技术细节内幕，大家可以关注下面这些文章发布渠道： + ++ 公众号：微信搜索 PingCAP ++ 知乎专栏：[TiDB 的后花园](https://zhuanlan.zhihu.com/newsql) ++ [官方博客](https://pingcap.com/blog-cn/) + +## TiDB 的最佳适用场景 + +简单来说，TiDB 适合具备下面这些特点的场景： + ++ 数据量大，单机保存不下 ++ 不希望做 Sharding 或者懒得做 Sharding ++ 访问模式上没有明显的热点 ++ 需要事务、需要强一致、需要灾备 ++ 希望 Real-Time HTAP，减少存储链路 diff --git a/choose-index.md b/choose-index.md index d0314c6bbfb8..21c8b7851999 100644 --- a/choose-index.md +++ b/choose-index.md @@ -1,5 +1,6 @@ --- title: 索引的选择 +summary: 介绍 TiDB 如何选择索引去读入数据，以及相关的一些控制索引选择的方式。 aliases: ['/docs-cn/dev/choose-index/'] --- diff --git a/configure-memory-usage.md b/configure-memory-usage.md index ef2e0ecf690e..284cd8c71699 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -1,6 +1,7 @@ --- title: TiDB 内存控制文档 aliases: ['/docs-cn/dev/configure-memory-usage/','/docs-cn/dev/how-to/configure/memory-control/'] +summary: TiDB 内存控制文档介绍了如何追踪和控制 SQL 查询过程中的内存使用情况，以及配置内存使用阈值和 tidb-server 实例的内存使用阈值。还介绍了使用 INFORMATION_SCHEMA 系统表查看内存使用情况，以及降低写入事务内存使用的方法。另外还介绍了流量控制和数据落盘的内存控制策略，以及通过设置环境变量 GOMEMLIMIT 缓解 OOM 问题。 --- # TiDB 内存控制文档 diff --git a/ecosystem-tool-user-case.md b/ecosystem-tool-user-case.md index c36501d30d42..87db4d1dbc03 100644 --- a/ecosystem-tool-user-case.md +++ b/ecosystem-tool-user-case.md @@ -1,45 +1,45 @@ ---- -title: TiDB 工具的使用场景 -summary: 本文档介绍 TiDB 工具的常见使用场景与工具选择。 -aliases: ['/docs-cn/dev/ecosystem-tool-user-case/'] ---- - -# TiDB 工具的使用场景 - -本文档从数据迁移工具的使用场景出发，介绍部分常见场景下的迁移工具的选择。 - -## 在物理机或虚拟机上部署运维 TiDB - -当需要在物理机或虚拟机上部署运维 TiDB 时，你可以先安装 [TiUP](/tiup/tiup-overview.md)，再通过 TiUP 管理 TiDB 的众多组件，如 TiDB、PD、TiKV 等。 - -## 在 Kubernetes 上部署运维 TiDB - -当需要在 Kubernetes 上部署运维 TiDB 时，你可以先创建 Kubernetes 集群，部署[TiDB Operator](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable)，然后使用 TiDB Operator 部署运维 TiDB 集群。 - -## 从 CSV 导入数据到 TiDB - -当需要将其他工具导出的格式兼容的 CSV files 导入到 TiDB 时，可使用 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)。 - -## 从 MySQL/Aurora 导入全量数据 - -当需要从 MySQL/Aurora 导入全量数据时，可先使用 [Dumpling](/dumpling-overview.md) 将数据导出为 SQL dump files，然后再使用 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 将数据导入到 TiDB 集群。 - -## 从 MySQL/Aurora 迁移数据 - -当既需要从 MySQL/Aurora 导入全量数据，又需要迁移增量数据时，可使用 [TiDB Data Migration (DM)](/dm/dm-overview.md) 完成[从 Amazon Aurora 迁移数据到 TiDB](/migrate-aurora-to-tidb.md)。 - -如果全量数据量较大（TB 级别），则可先使用 [Dumpling](/dumpling-overview.md) 与 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 完成全量数据的迁移，再使用 DM 完成增量数据的迁移。 - -## TiDB 集群备份与恢复 - -当需要对 TiDB 集群进行备份或在之后对 TiDB 集群进行恢复时，可使用 [BR](/br/backup-and-restore-overview.md)。 - -## 迁出数据到 TiDB - -当需要将 TiDB 集群的数据迁出到其他 TiDB 集群时，可使用 [Dumpling](/dumpling-overview.md) 从 TiDB 将全量数据导出为 SQL dump files，然后再使用 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 将数据导入到 TiDB。 - -如果还需要执行增量数据的迁移，则可使用 [TiCDC](/ticdc/ticdc-overview.md)。 - -## TiDB 增量数据订阅 - -当需要订阅 TiDB 增量数据的变更时，可使用 [TiCDC](/ticdc/ticdc-overview.md)。 +--- +title: TiDB 工具的使用场景 +summary: 本文档介绍 TiDB 工具的常见使用场景与工具选择。 +aliases: ['/docs-cn/dev/ecosystem-tool-user-case/'] +--- + +# TiDB 工具的使用场景 + +本文档从数据迁移工具的使用场景出发，介绍部分常见场景下的迁移工具的选择。 + +## 在物理机或虚拟机上部署运维 TiDB + +当需要在物理机或虚拟机上部署运维 TiDB 时，你可以先安装 [TiUP](/tiup/tiup-overview.md)，再通过 TiUP 管理 TiDB 的众多组件，如 TiDB、PD、TiKV 等。 + +## 在 Kubernetes 上部署运维 TiDB + +当需要在 Kubernetes 上部署运维 TiDB 时，你可以先创建 Kubernetes 集群，部署[TiDB Operator](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable)，然后使用 TiDB Operator 部署运维 TiDB 集群。 + +## 从 CSV 导入数据到 TiDB + +当需要将其他工具导出的格式兼容的 CSV files 导入到 TiDB 时，可使用 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)。 + +## 从 MySQL/Aurora 导入全量数据 + +当需要从 MySQL/Aurora 导入全量数据时，可先使用 [Dumpling](/dumpling-overview.md) 将数据导出为 SQL dump files，然后再使用 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 将数据导入到 TiDB 集群。 + +## 从 MySQL/Aurora 迁移数据 + +当既需要从 MySQL/Aurora 导入全量数据，又需要迁移增量数据时，可使用 [TiDB Data Migration (DM)](/dm/dm-overview.md) 完成[从 Amazon Aurora 迁移数据到 TiDB](/migrate-aurora-to-tidb.md)。 + +如果全量数据量较大（TB 级别），则可先使用 [Dumpling](/dumpling-overview.md) 与 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 完成全量数据的迁移，再使用 DM 完成增量数据的迁移。 + +## TiDB 集群备份与恢复 + +当需要对 TiDB 集群进行备份或在之后对 TiDB 集群进行恢复时，可使用 [BR](/br/backup-and-restore-overview.md)。 + +## 迁出数据到 TiDB + +当需要将 TiDB 集群的数据迁出到其他 TiDB 集群时，可使用 [Dumpling](/dumpling-overview.md) 从 TiDB 将全量数据导出为 SQL dump files，然后再使用 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 将数据导入到 TiDB。 + +如果还需要执行增量数据的迁移，则可使用 [TiCDC](/ticdc/ticdc-overview.md)。 + +## TiDB 增量数据订阅 + +当需要订阅 TiDB 增量数据的变更时，可使用 [TiCDC](/ticdc/ticdc-overview.md)。 diff --git a/faq/high-reliability-faq.md b/faq/high-reliability-faq.md index ad8431f5b624..e81f5cfb5e4e 100644 --- a/faq/high-reliability-faq.md +++ b/faq/high-reliability-faq.md @@ -1,44 +1,44 @@ ---- -title: 高可靠常见问题 -summary: 介绍高可靠相关的常见问题。 -aliases: ['/docs-cn/dev/faq/high-reliability-faq/'] ---- - -# 高可靠常见问题 - -本文档介绍高可靠相关的常见问题。 - -## TiDB 是否支持数据加密？ - -支持。要加密传输中的数据，可以[在 TiDB 客户端和服务器之间启用 TLS](/enable-tls-between-clients-and-servers.md)。要加密存储引擎中的数据，可以启用[透明数据加密 (TDE)](/encryption-at-rest.md)。 - -## 我们的安全漏洞扫描工具对 MySQL version 有要求，TiDB 是否支持修改 server 版本号呢？ - -TiDB 在 v3.0.8 后支持通过 TiDB 配置文件中的 [`server-version`](/tidb-configuration-file.md#server-version) 配置项来修改 server 版本号。 - -对于 v4.0 及以上版本的集群，如果使用 TiUP 部署集群，可以通过 `tiup cluster edit-config ` 修改配置文件中以下部分来设置合适的版本号： - -``` -server_configs: - tidb: - server-version: 'YOUR_VERSION_STRING' -``` - -修改完成后，使用 `tiup cluster reload -R tidb` 命令使得以上修改生效，以避免出现安全漏洞扫描不通过的问题。 - -## TiDB 支持哪些认证协议？过程是怎样的？ - -TiDB 和 MySQL 一样，在用户登录认证时使用 SASL 认证协议对密码进行处理。 - -客户端连接 TiDB 的时候，使用 challenge-response（挑战-应答）的认证模式，过程如下： - -1. 客户端连接服务器。 -2. 服务器发送随机字符串 `challenge` 给客户端。 -3. 客户端发送 `username` + `response` 给服务器。 -4. 服务器验证 `response`。 - -## 如何修改用户名密码和权限？ - -因为 TiDB 是分布式数据库，想要在 TiDB 中修改用户密码，建议使用 `ALTER USER` 的方法，例如 `ALTER USER 'test'@'localhost' IDENTIFIED BY 'mypass';`。 - -不推荐使用 `UPDATE mysql.user` 的方法，因为这种方法可能会造成其它节点刷新不及时的情况。修改权限也一样，建议参考 [TiDB 用户账户管理](/user-account-management.md)文档中的方法。 +--- +title: 高可靠常见问题 +summary: 介绍高可靠相关的常见问题。 +aliases: ['/docs-cn/dev/faq/high-reliability-faq/'] +--- + +# 高可靠常见问题 + +本文档介绍高可靠相关的常见问题。 + +## TiDB 是否支持数据加密？ + +支持。要加密传输中的数据，可以[在 TiDB 客户端和服务器之间启用 TLS](/enable-tls-between-clients-and-servers.md)。要加密存储引擎中的数据，可以启用[透明数据加密 (TDE)](/encryption-at-rest.md)。 + +## 我们的安全漏洞扫描工具对 MySQL version 有要求，TiDB 是否支持修改 server 版本号呢？ + +TiDB 在 v3.0.8 后支持通过 TiDB 配置文件中的 [`server-version`](/tidb-configuration-file.md#server-version) 配置项来修改 server 版本号。 + +对于 v4.0 及以上版本的集群，如果使用 TiUP 部署集群，可以通过 `tiup cluster edit-config ` 修改配置文件中以下部分来设置合适的版本号： + +``` +server_configs: + tidb: + server-version: 'YOUR_VERSION_STRING' +``` + +修改完成后，使用 `tiup cluster reload -R tidb` 命令使得以上修改生效，以避免出现安全漏洞扫描不通过的问题。 + +## TiDB 支持哪些认证协议？过程是怎样的？ + +TiDB 和 MySQL 一样，在用户登录认证时使用 SASL 认证协议对密码进行处理。 + +客户端连接 TiDB 的时候，使用 challenge-response（挑战-应答）的认证模式，过程如下： + +1. 客户端连接服务器。 +2. 服务器发送随机字符串 `challenge` 给客户端。 +3. 客户端发送 `username` + `response` 给服务器。 +4. 服务器验证 `response`。 + +## 如何修改用户名密码和权限？ + +因为 TiDB 是分布式数据库，想要在 TiDB 中修改用户密码，建议使用 `ALTER USER` 的方法，例如 `ALTER USER 'test'@'localhost' IDENTIFIED BY 'mypass';`。 + +不推荐使用 `UPDATE mysql.user` 的方法，因为这种方法可能会造成其它节点刷新不及时的情况。修改权限也一样，建议参考 [TiDB 用户账户管理](/user-account-management.md)文档中的方法。 diff --git a/faq/sql-faq.md b/faq/sql-faq.md index f439010f3060..199d6233f18b 100644 --- a/faq/sql-faq.md +++ b/faq/sql-faq.md @@ -1,413 +1,413 @@ ---- -title: SQL 操作常见问题 -summary: 介绍 SQL 操作相关的常见问题。 -aliases: ['/docs-cn/dev/faq/sql-faq/'] ---- - -# SQL 操作常见问题 - -本文档介绍 TiDB 中常见的 SQL 操作问题。 - -## TiDB 是否支持二级键？ - -支持。你可以在具有唯一[二级索引](/develop/dev-guide-create-secondary-indexes.md)的非主键列上设置 [`NOT NULL` 约束](/constraints.md#非空约束)。在这种情况下，该列用作二级键。 - -## TiDB 在对大表执行 DDL 操作时，性能表现如何？ - -TiDB 在对大表执行 DDL 操作时，一般不会有什么问题。TiDB 支持在线 DDL 操作，且这些 DDL 操作不会阻塞 DML 操作。 - -对于添加列、删除列或删除索引等 DDL 操作，TiDB 可以快速完成这些操作。 - -对于添加索引等 DDL 操作，TiDB 需要进行回填 (backfill) 操作，这个过程需要较长的时间（取决于表的大小）和额外的资源消耗。对在线业务的影响可调节。TiDB 可以通过多线程进行 backfill，资源消耗可通过以下系统变量进行设置： - -- [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) -- [`tidb_ddl_reorg_priority`](/system-variables.md#tidb_ddl_reorg_priority) -- [`tidb_ddl_error_count_limit`](/system-variables.md#tidb_ddl_error_count_limit) -- [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) - -## 如何选择正确的查询计划？是否需要使用优化器提示？还是可以使用提示？ - -TiDB 包含一个基于成本的优化器。在大多数情况下，优化器会为你选择最优的查询计划。如果优化器工作欠佳，你可以使用[优化器提示](/optimizer-hints.md)来干预优化器。 - -另外，你还可以使用[执行计划绑定](/sql-plan-management.md#执行计划绑定-sql-binding)来为特定的 SQL 语句固定查询计划。 - -## 如何阻止特定的 SQL 语句执行（或者将某个 SQL 语句加入黑名单）？ - -你可以使用 [`MAX_EXECUTION_TIME`](/optimizer-hints.md#max_execution_timen) Hint 来创建 [SQL 绑定](/sql-plan-management.md#执行计划绑定-sql-binding)，将特定语句的执行时间限制为一个较小的值（例如 1ms）。这样，语句就会在超过限制时自动终止。 - -例如，要阻止执行 `SELECT * FROM t1, t2 WHERE t1.id = t2.id`，可以使用以下 SQL 绑定将语句的执行时间限制为 1ms： - -```sql -CREATE GLOBAL BINDING for - SELECT * FROM t1, t2 WHERE t1.id = t2.id -USING - SELECT /*+ MAX_EXECUTION_TIME(1) */ * FROM t1, t2 WHERE t1.id = t2.id; -``` - -> **注意：** -> -> `MAX_EXECUTION_TIME` 的精度大约为 100ms。在 TiDB 终止 SQL 语句之前，TiKV 中的任务可能已经开始执行。为了减少这种情况下 TiKV 的资源消耗，建议将系统变量 [`tidb_enable_paging`](/system-variables.md#tidb_enable_paging-从-v540-版本开始引入) 的值设置为 `ON`。 - -删除该 SQL 绑定可以移除限制。 - -```sql -DROP GLOBAL BINDING for - SELECT * FROM t1, t2 WHERE t1.id = t2.id; -``` - -## TiDB 对哪些 MySQL variables 兼容？ - -详细可参考[系统变量](/system-variables.md)。 - -## 省略 `ORDER BY` 条件时 TiDB 中返回结果的顺序与 MySQL 中的不一致 - -这不是 bug。返回结果的顺序视不同情况而定，不保证顺序统一。 - -MySQL 中，返回结果的顺序可能较为固定，因为查询是通过单线程执行的。但升级到新版本后，查询计划也可能变化。无论是否期待返回结果有序，都推荐使用 `ORDER BY` 条件。 - -[ISO/IEC 9075:1992, Database Language SQL- July 30, 1992](http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt) 对此有如下表述： - -> If an `` is not specified, then the table specified by the `` is T and the ordering of rows in T is implementation-dependent.（如果未指定 ``，通过 `` 指定的表为 T，那么 T 表中的行顺序视执行情况而定。） - -以下两条查询的结果都是合法的： - -```sql -> select * from t; -+------+------+ -| a | b | -+------+------+ -| 1 | 1 | -| 2 | 2 | -+------+------+ -2 rows in set (0.00 sec) -``` - -```sql -> select * from t; -- 不确定返回结果的顺序 -+------+------+ -| a | b | -+------+------+ -| 2 | 2 | -| 1 | 1 | -+------+------+ -2 rows in set (0.00 sec) -``` - -如果 `ORDER BY` 中使用的列不是唯一列，就无法确定该语句返回结果的顺序。在以下示例中，`a` 列有重复值，因此只有 `ORDER BY a, b` 能确定返回结果的顺序。 - -```sql -> select * from t order by a; -+------+------+ -| a | b | -+------+------+ -| 1 | 1 | -| 2 | 1 | -| 2 | 2 | -+------+------+ -3 rows in set (0.00 sec) -``` - -在以下示例中，`order by a` 能确定 a 列的顺序，但不能确定 b 列的顺序。 - -```sql -> select * from t order by a; -+------+------+ -| a | b | -+------+------+ -| 1 | 1 | -| 2 | 2 | -| 2 | 1 | -+------+------+ -3 rows in set (0.00 sec) -``` - -在 TiDB 中，你还可以使用系统变量 [`tidb_enable_ordered_result_mode`](/system-variables.md#tidb_enable_ordered_result_mode) 来指定是否对最终的输出结果进行自动排序。 - -## TiDB 是否支持 `SELECT FOR UPDATE`？ - -支持。当 TiDB 使用悲观锁（自 TiDB v3.0.8 起默认使用）时，TiDB 中 `SELECT FOR UPDATE` 的行为与 MySQL 中的基本一致。 - -当 TiDB 使用乐观锁时，`SELECT FOR UPDATE` 不会在事务启动时对数据加锁，而是在提交事务时检查冲突。如果检查出冲突，会回滚待提交的事务。 - -详情参考 [SELECT 语句语法元素说明](/sql-statements/sql-statement-select.md#语法元素说明)。 - -## TiDB 的 codec 能保证 UTF8 的字符串是 memcomparable 的吗？我们的 key 需要支持 UTF8，有什么编码建议吗？ - -TiDB 字符集默认就是 UTF8 而且目前只支持 UTF8，字符串就是 memcomparable 格式的。 - -## 一个事务中的语句数量最大是多少？ - -一个事务中的语句数量，默认限制最大为 5000 条。 - -在使用乐观事务并开启事务重试的情况下，默认限制 5000，可通过 [`stmt-count-limit`](/tidb-configuration-file.md#stmt-count-limit) 调整。 - -## TiDB 中，为什么出现后插入数据的自增 ID 反而小？ - -TiDB 的自增 ID (`AUTO_INCREMENT`) 只保证自增且唯一，并不保证连续分配。TiDB 目前采用批量分配的方式，所以如果在多台 TiDB server 上同时插入数据，分配的自增 ID 会不连续。当多个线程并发往不同的 TiDB server 插入数据的时候，有可能会出现后插入的数据自增 ID 小的情况。此外，TiDB 允许给整型类型的字段指定 AUTO_INCREMENT，且一个表只允许一个属性为 `AUTO_INCREMENT` 的字段。详情可参考[自增 ID](/mysql-compatibility.md#自增-id)和 [AUTO_INCREMENT](/auto-increment.md)。 - -## 如何在 TiDB 中修改 `sql_mode`？ - -TiDB 支持在会话或全局作用域上修改 [`sql_mode`](/system-variables.md#sql_mode) 系统变量。 - -- 对全局作用域变量的修改，设置后将作用于集群中的其它服务器，并且重启后更改依然有效。因此，你无需在每台 TiDB 服务器上都更改 `sql_mode` 的值。 -- 对会话作用域变量的修改，设置后只影响当前会话，重启后更改消失。 - -## 用 Sqoop 批量写入 TiDB 数据，虽然配置了 `--batch` 选项，但还是会遇到 `java.sql.BatchUpdateException:statement count 5001 exceeds the transaction limitation` 的错误，该如何解决？ - -问题原因：在 Sqoop 中，`--batch` 是指每个批次提交 100 条 statement，但是默认每个 statement 包含 100 条 SQL 语句，所以此时 100 * 100 = 10000 条 SQL 语句，超出了 TiDB 的事务限制 5000 条。 - -解决办法： - -- 增加选项 `-Dsqoop.export.records.per.statement=10`，完整的用法如下： - - ```bash - sqoop export \ - -Dsqoop.export.records.per.statement=10 \ - --connect jdbc:mysql://mysql.example.com/sqoop \ - --username sqoop ${user} \ - --password ${passwd} \ - --table ${tab_name} \ - --export-dir ${dir} \ - --batch - ``` - -- 也可以选择增大 TiDB 的单个事物语句数量限制，不过此操作会导致内存增加。详情参见 [SQL 语句的限制](/tidb-limitations.md#sql-statements-的限制)。 - -## TiDB 有像 Oracle 那样的 Flashback Query 功能么，DDL 支持么？ - -有，也支持 DDL。详细参考[使用 AS OF TIMESTAMP 语法读取历史数据](/as-of-timestamp.md)。 - -## TiDB 中删除数据后会立即释放空间吗？ - -在 TiDB 中使用 `DELETE`，`TRUNCATE` 和 `DROP` 语句删除数据都不会立即释放空间。对于 `TRUNCATE` 和 `DROP` 操作，在达到 TiDB 的 GC (garbage collection) 时间后（默认 10 分钟），TiDB 的 GC 机制会删除数据并释放空间。对于 DELETE 操作，TiDB 的 GC 机制会删除数据，但不会立即释放空间，而是等到后续进行 compaction 时释放空间。 - -## 删除数据后查询速度为何会变慢？ - -删除大量数据后，会有很多无用的 key 存在，影响查询效率。要解决该问题，可以尝试开启 [Region Merge](/best-practices/massive-regions-best-practices.md#方法五开启-region-merge) 功能，具体可参考[最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/)中的删除数据部分。 - -## 对数据做删除操作之后，空间回收比较慢，如何处理？ - -TiDB 采用了多版本并发控制 (MVCC) 机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。为了使并发事务能查看到早期版本的数据，删除数据时 TiDB 不会立即回收空间，而是等待一段时间后再进行垃圾回收 (GC)。要配置历史数据的保留时限，你可以修改系统变量 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-从-v50-版本开始引入)的值（默认值为 `10m0s`）。 - -## `SHOW PROCESSLIST` 是否显示系统进程号？ - -TiDB 中的 `SHOW PROCESSLIST` 与 MySQL 中的 `SHOW PROCESSLIST` 显示内容基本一致，不会显示系统进程号。而返回结果中的 ID 表示当前的 session ID。其中 TiDB 的 `SHOW PROCESSLIST` 和 MySQL 的 `SHOW PROCESSLIST` 区别如下： - -+ 由于 TiDB 是分布式数据库，TiDB server 实例是无状态的 SQL 解析和执行引擎（详情可参考 [TiDB 整体架构](/tidb-architecture.md)），用户使用 MySQL 客户端登录的是哪个 TiDB server，`SHOW PROCESSLIST` 就会显示当前连接的这个 TiDB server 中执行的 session 列表，不是整个集群中运行的全部 session 列表；而 MySQL 是单机数据库，`SHOW PROCESSLIST` 列出的是当前整个 MySQL 数据库的全部执行 SQL 列表。 - -+ 在查询执行期间，TiDB 中的 `State` 列不会持续更新。由于 TiDB 支持并行查询，每个语句可能同时处于多个状态，因此很难显示为某一种状态。 - -## 在 TiDB 中如何控制或改变 SQL 提交的执行优先级？ - -TiDB 支持改变[全局](/system-variables.md#tidb_force_priority)或单个语句的优先级。优先级包括： - -- `HIGH_PRIORITY`：该语句为高优先级语句，TiDB 在执行阶段会优先处理这条语句 -- `LOW_PRIORITY`：该语句为低优先级语句，TiDB 在执行阶段会降低这条语句的优先级 -- `DELAYED`：该语句为正常优先级语句，TiDB 不强制改变这条语句的优先级，与 `tidb_force_priority` 设置为 `NO_PRIORITY` 相同 - -> **注意：** -> -> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。 - -以上两种参数可以结合 TiDB 的 DML 语言进行使用，使用方法举例如下： - -1. 通过在数据库中写 SQL 的方式来调整优先级： - - ```sql - SELECT HIGH_PRIORITY | LOW_PRIORITY | DELAYED COUNT(*) FROM table_name; - INSERT HIGH_PRIORITY | LOW_PRIORITY | DELAYED INTO table_name insert_values; - DELETE HIGH_PRIORITY | LOW_PRIORITY | DELAYED FROM table_name; - UPDATE HIGH_PRIORITY | LOW_PRIORITY | DELAYED table_reference SET assignment_list WHERE where_condition; - REPLACE HIGH_PRIORITY | LOW_PRIORITY | DELAYED INTO table_name; - ``` - -2. 全表扫会自动调整为低优先级，[`ANALYZE`](/sql-statements/sql-statement-analyze-table.md) 也是默认低优先级。 - -## 在 TiDB 中 `auto analyze` 的触发策略是怎样的？ - -当一张表或分区表的单个分区达到 1000 条记录，且表或分区的（修改数/当前总行数）比例大于 [`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio) 的时候，会自动触发 [`ANALYZE`](/sql-statements/sql-statement-analyze-table.md) 语句。 - -`tidb_auto_analyze_ratio` 的默认值为 `0.5`，即默认开启触发 `auto analyze`。注意该变量值不建议大于等于 [`pseudo-estimate-ratio`](/tidb-configuration-file.md#pseudo-estimate-ratio)（默认值为 `0.8`），否则优化器可能会使用 pseudo 统计信息。TiDB 从 v5.3.0 开始引入 [`tidb_enable_pseudo_for_outdated_stats`](/system-variables.md#tidb_enable_pseudo_for_outdated_stats-从-v530-版本开始引入) 变量，当设置为 `OFF` 时，即使统计信息过期也不会使用 pseudo 统计信息。 - -你可以用系统变量 [`tidb_enable_auto_analyze`](/system-variables.md#tidb_enable_auto_analyze-从-v610-版本开始引入) 关闭 `auto analyze`。 - -## 可以使用 Optimizer Hints 控制优化器行为吗？ - -在 TiDB 中，你可以用多种方法控制查询优化器的默认行为，包括使用 [Optimizer Hints](/optimizer-hints.md) 和 [SQL 执行计划管理 (SPM)](/sql-plan-management.md)。基本用法同 MySQL 中的一致，还包含若干 TiDB 特有的用法，例如：`select column_name from table_name use index（index_name）where where_condition;`。 - -## DDL 执行 - -本节列出了 DDL 语句执行的相关问题。DDL 执行原理的详细说明，参见 [TiDB 中 DDL 执行原理及最佳实践](/ddl-introduction.md)。 - -### 各类 DDL 操作的预估耗时是多长？ - -假设 DDL 操作没有被阻塞，各个 TiDB server 能够正常更新 Schema 版本，DDL Owner 节点正常运行。在此情况下，各类 DDL 操作的预估耗时如下： - -| DDL 操作类型 | 预估耗时 | -|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------| -| Reorg DDL：例如 `ADD INDEX`、`MODIFY COLUMN`（Reorg 类型的数据更改） | 取决于数据量、系统负载以及 DDL 参数的设置 | -| General DDL（除 Reorg DDL 外的 DDL 类型）：例如 `CREATE DATABASE`、`CREATE TABLE`、`DROP DATABASE`、`DROP TABLE`、`TRUNCATE TABLE`、`ALTER TABLE ADD`、`ALTER TABLE DROP`、`MODIFY COLUMN`（只更改元数据）、`DROP INDEX` | 1 秒左右 | - -> **注意：** -> -> 以上为各类操作的预估耗时，请以实际操作耗时为准。 - -## 执行 DDL 会慢的可能原因 - -- 在一个用户会话中，DDL 语句之前有非 auto-commit 的 DML 语句，并且该 DML 语句的提交操作比较慢，会导致 DDL 语句执行慢。即执行 DDL 语句前，会先提交之前没有提交的 DML 语句。 -- 多个 DDL 语句一起执行的时候，后面的几个 DDL 语句可能会比较慢，因为可能需要排队等待。排队场景包括： - - 同一类型 DDL 语句需要排队（例如 `CREATE TABLE` 和 `CREATE DATABASE` 都是 General DDL，两个操作同时执行时，需要排队）。自 TiDB v6.2.0 起，支持并行 DDL 语句，但为了避免 DDL 使用过多 TiDB 的计算资源，也有并发度限制，因此会有一定的排队情况。 - - 对同一张表上执行的 DDL 操作存在依赖关系，后面的 DDL 语句需要等待前面的 DDL 操作完成。 -- 在集群正常启动后，第一个 DDL 操作的执行时间可能会比较久，可能是因为 DDL 模块在进行 DDL Owner 的选举。 - -- 终止 TiDB 时，TiDB 不能与 PD 正常通信（包括停电的情况），或者用 `kill -9` 命令终止 TiDB 导致 TiDB 没有及时从 PD 清理注册数据。 -- 集群中某个 TiDB 与 PD 或者 TiKV 之间发生通信问题，即 TiDB 不能及时获取最新版本信息。 - -### 触发 Information schema is changed 错误的原因？ - -TiDB 在执行 SQL 语句时，会根据隔离级别确定一个对象的 `schema` 版本来处理该 SQL 语句，而且 TiDB 支持在线异步变更 DDL。那么，在执行 DML 的时候可能有 DDL 语句也在执行，而你需要确保每个 SQL 语句在同一个 `schema` 上执行。所以当执行 DML 时，如果遇到正在执行中的 DDL 操作，TiDB 可能会报 `Information schema is changed` 的错误。 - -从 v6.4.0 开始，TiDB 实现了[元数据锁机制](/metadata-lock.md)，可以让 DML 语句的执行和 DDL Schema 变更协同进行，可以避免大部分 `Information schema is changed` 错误的发生。 - -报错的可能原因如下： - -- 原因 1：正在执行的 DML 所涉及的表和集群中正在执行的 DDL 的表有相同的，那么这个 DML 语句就会报此错。可以通过命令 `admin show ddl job` 查看正在执行的 DDL 操作。 -- 原因 2：这个 DML 执行时间很久，而这段时间内执行了很多 DDL 语句，导致中间 `schema` 版本变更次数超过 1024 （此为默认值，可以通过 `tidb_max_delta_schema_count` 变量修改）。 -- 原因 3：接受 DML 请求的 TiDB 长时间不能加载到 `schema information`（TiDB 与 PD 或 TiKV 之间的网络连接故障等会导致此问题），而这段时间内执行了很多 DDL 语句，导致中间 `schema` 版本变更次数超过 100。 -- 原因 4：TiDB 重启后执行第一个 DDL 操作前，执行 DML 操作，并且在执行过程中遇到了第 1 个 DDL 操作（即在执行第 1 个 DDL 操作前，启动该 DML 对应的事务，且在该 DDL 变更第一个 `schema` 版本后，提交该 DML 对应的事务），那么这个 DML 会报此错。 - -以上原因中，只有原因 1 与表有关。原因 1 和原因 2 都不会导致业务问题，相应的 DML 会在失败后重试。对于原因 3，需要检查 TiDB 实例和 PD 及 TiKV 的网络情况。 - -> **注意：** -> -> + 目前 TiDB 未缓存所有的 `schema` 版本信息。 -> + 对于每个 DDL 操作，`schema` 版本变更的数量与对应 `schema state` 变更的次数一致。 -> + 不同的 DDL 操作版本变更次数不一样。例如，`create table` 操作会有 1 次 `schema` 版本变更；`add column` 操作有 4 次 `schema` 版本变更。 - -### 触发 Information schema is out of date 错误的原因？ - -在 v6.5.0 之前，当执行 DML 时，TiDB 超过一个 DDL lease 时间（默认 45s）没能加载到最新的 schema 就可能会报 `Information schema is out of date` 的错误。遇到此错的可能原因如下： - -- 执行此 DML 的 TiDB 被 kill 后准备退出，且此 DML 对应的事务执行时间超过一个 DDL lease，在事务提交时会报这个错误。 -- TiDB 在执行此 DML 时，有一段时间内连不上 PD 或者 TiKV，导致 TiDB 超过一个 DDL lease 时间没有 load schema，或者导致 TiDB 断开与 PD 之间带 keep alive 设置的连接。 - -### 高并发情况下执行 DDL 时报错的原因？ - -高并发场景下执行 DDL 语句（比如批量建表）时，极少部分的 DDL 语句可能会由于并发执行时 key 冲突而执行失败。 - -并发执行 DDL 语句时，建议将 DDL 语句数量保持在 20 以下，否则你需要在应用端重试失败的 DDL 语句。 - -### DDL 执行被阻塞的原因 - -在 TiDB v6.2.0 前，TiDB 按照 DDL 语句类型将 DDL 分配到两个先入先出的队列中，即 Reorg DDL 进入 Reorg 队列中，General DDL 进入 general 队列中。由于先入先出以及同一张表上的 DDL 语句需要串行执行，多个 DDL 语句在执行过程中可能会出现阻塞的问题。 - -例如对于以下 DDL 语句： - -- DDL 1：`CREATE INDEX idx on t(a int);` -- DDL 2：`ALTER TABLE t ADD COLUMN b int;` -- DDL 3：`CREATE TABLE t1(a int);` - -由于队列先入先出的限制，DDL 3 需要等待 DDL 2 执行。同时又因为同一张表上的 DDL 语句需要串行执行，DDL 2 需要等待 DDL 1 执行。因此，DDL 3 需要等待 DDL 1 先执行完，即使它们操作在不同的表上。 - -在 TiDB v6.2.0 及之后的版本中，TiDB DDL 模块采用了并发框架。在并发的框架下，不再有同一个队列先进先出的问题，而是从所有 DDL 任务中选出可以执行的 DDL 来执行。并且对 Reorg worker 的数量进行了扩充，大概为节点 `CPU/4`，这使得在并发框架中 TiDB 可以同时为多张表建索引。 - -无论是新集群还是从旧版本升级的集群，在 TiDB v6.2 及以上版本中，TiDB 都会自动使用并发框架，用户无需进行调整。 - -### 定位 DDL 执行卡住的问题 - -1. 先排除 DDL 语句通常执行慢的可能原因。 -2. 使用以下任一方法找出 DDL owner 节点： - + 通过 `curl http://{TiDBIP}:10080/info/all` 获取当前集群的 Owner - + 通过监控 **DDL** > **DDL META OPM** 查看某个时间段的 Owner - -- 如果 Owner 不存在，尝试手动触发 Owner 选举：`curl -X POST http://{TiDBIP}:10080/ddl/owner/resign`。 -- 如果 Owner 存在，导出 Goroutine 堆栈并检查可能卡住的地方。 - -## SQL 优化 - -### TiDB 执行计划解读 - -详细解读[理解 TiDB 执行计划](/explain-overview.md)。 - -### 统计信息收集 - -详细解读[统计信息](/statistics.md)。 - -### Count 如何加速？ - -Count 就是暴力扫表，提高并发度能显著提升扫表速度。如要调整并发度，可以使用 `tidb_distsql_scan_concurrency` 变量，但调整并发度需要同时考虑 CPU 和 I/O 资源。TiDB 每次执行查询时，都要访问 TiKV。在数据量小的情况下，MySQL 的数据都在内存里，而 TiDB 还需要进行一次网络访问。 - -加速建议： - -- 提升硬件配置，可以参考[部署建议](/hardware-and-software-requirements.md)。 -- 提升并发度，默认是 10，可以尝试提升到 50，但是一般提升幅度在 2-4 倍之间。 -- 测试大数据量的 count。 -- 调优 TiKV 配置，可以参考[性能调优](/tune-tikv-memory-performance.md)。 -- 参考[下推计算结果缓存](/coprocessor-cache.md)。 - -### 查看当前 DDL 的进度？ - -通过 `ADMIN SHOW DDL` 语句查看当前 job 进度。操作如下： - -```sql -ADMIN SHOW DDL; -``` - -```sql -*************************** 1. row *************************** - SCHEMA_VER: 140 - OWNER: 1a1c4174-0fcd-4ba0-add9-12d08c4077dc -RUNNING_JOBS: ID:121, Type:add index, State:running, SchemaState:write reorganization, SchemaID:1, TableID:118, RowCount:77312, ArgLen:0, start time: 2018-12-05 16:26:10.652 +0800 CST, Err:, ErrCount:0, SnapshotVersion:404749908941733890 - SELF_ID: 1a1c4174-0fcd-4ba0-add9-12d08c4077dc -``` - -从以上返回结果可知，当前正在处理的是 `ADD INDEX` 操作。且从 `RUNNING_JOBS` 列的 `RowCount` 字段可以知道当前 `ADD INDEX` 操作已经添加了 77312 行索引。 - -### 如何查看 DDL job？ - -可以使用 `ADMIN SHOW DDL` 语句查看正在运行的 DDL 作业。 - -- `ADMIN SHOW DDL JOBS`：用于查看当前 DDL 作业队列中的所有结果（包括正在运行以及等待运行的任务）以及已执行完成的 DDL 作业队列中的最近十条结果。 -- `ADMIN SHOW DDL JOBS QUERIES 'job_id' [, 'job_id'] ...`：用于显示 `job_id` 对应的 DDL 任务的原始 SQL 语句。此 `job_id` 只搜索正在执行中的任务以及 DDL 历史作业队列中的最近十条结果。 - -### TiDB 是否支持基于 COST 的优化 (CBO)？如果支持，实现到什么程度？ - -是的，TiDB 基于成本的优化器 (CBO) 对代价模型、统计信息进行持续优化。除此之外，TiDB 还支持 hash join、sort-merge join 等 join 算法。 - -### 如何确定某张表是否需要做 analyze ？ - -可以通过 `SHOW STATS_HEALTHY` 来查看 Healthy 字段，一般该字段值小于等于 60 的表需要做 analyze。 - -### SQL 的执行计划展开成了树，ID 的序号有什么规律吗？这棵树的执行顺序会是怎么样的？ - -ID 没什么规律，只要是唯一就行。不过在生成执行计划时，有一个计数器，生成一个计划 ID 后序号就加 1，执行的顺序和序号无关。整个执行计划是一颗树，执行时从根节点开始，不断地向上返回数据。要理解执行计划，请参考[理解 TiDB 执行计划](/explain-overview.md)。 - -### TiDB 执行计划中，task cop 在一个 root 下，这个是并行的吗？ - -目前 TiDB 的计算任务隶属于两种不同的 task：cop task 和 root task。cop task 是指被下推到 KV 端分布式执行的计算任务，root task 是指在 TiDB 端单点执行的计算任务。 - -一般来讲 root task 的输入数据是来自于 cop task 的，但是 root task 在处理数据的时候，TiKV 上的 cop task 也可以同时处理数据，等待 TiDB 的 root task 拉取。所以从这个过程来看，root task 和 cop task 是并行的，同时存在数据上下游关系。 - -在执行的过程中，某些时间段也可能是并行的，第一个 cop task 在处理 [100, 200] 的数据，第二个 cop task 在处理 [1, 100] 的数据。执行计划的理解，请参考[理解 TiDB 执行计划](/explain-overview.md)。 - -## 数据库优化 - -### TiDB 参数及调整 - -详情参考 [TiDB 配置参数](/command-line-flags-for-tidb-configuration.md)。 - -### 如何避免热点问题并实现负载均衡？TiDB 中是否有热分区或热范围问题？ - -要了解热点问题的场景，请参考[常见热点问题](/troubleshoot-hot-spot-issues.md#常见热点场景)。TiDB 的以下特性旨在帮助解决热点问题： - -- [`SHARD_ROW_ID_BITS`](/troubleshoot-hot-spot-issues.md#使用-shard_row_id_bits-处理热点表) 属性。设置该属性后，行 ID 会被打散并写入多个 Region，以缓解写入热点问题。 -- [`AUTO_RANDOM`](/troubleshoot-hot-spot-issues.md#使用-auto_random-处理自增主键热点表) 属性，用于解决自增主键带来的热点问题。 -- [Coprocessor Cache](/coprocessor-cache.md)，针对小表的读热点问题。 -- [Load Base Split](/configure-load-base-split.md)，针对因 Region 访问不均衡（例如小表全表扫）而导致的热点问题。 -- [缓存表](/cached-tables.md)，针对被频繁访问但更新较少的小热点表。 - -如果你遇到因热点引起的性能问题，可参考[处理热点问题](/troubleshoot-hot-spot-issues.md)。 - -### TiKV 性能参数调优 - -详情参考 [TiKV 性能参数调优](/tune-tikv-memory-performance.md)。 +--- +title: SQL 操作常见问题 +summary: 介绍 SQL 操作相关的常见问题。 +aliases: ['/docs-cn/dev/faq/sql-faq/'] +--- + +# SQL 操作常见问题 + +本文档介绍 TiDB 中常见的 SQL 操作问题。 + +## TiDB 是否支持二级键？ + +支持。你可以在具有唯一[二级索引](/develop/dev-guide-create-secondary-indexes.md)的非主键列上设置 [`NOT NULL` 约束](/constraints.md#非空约束)。在这种情况下，该列用作二级键。 + +## TiDB 在对大表执行 DDL 操作时，性能表现如何？ + +TiDB 在对大表执行 DDL 操作时，一般不会有什么问题。TiDB 支持在线 DDL 操作，且这些 DDL 操作不会阻塞 DML 操作。 + +对于添加列、删除列或删除索引等 DDL 操作，TiDB 可以快速完成这些操作。 + +对于添加索引等 DDL 操作，TiDB 需要进行回填 (backfill) 操作，这个过程需要较长的时间（取决于表的大小）和额外的资源消耗。对在线业务的影响可调节。TiDB 可以通过多线程进行 backfill，资源消耗可通过以下系统变量进行设置： + +- [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) +- [`tidb_ddl_reorg_priority`](/system-variables.md#tidb_ddl_reorg_priority) +- [`tidb_ddl_error_count_limit`](/system-variables.md#tidb_ddl_error_count_limit) +- [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) + +## 如何选择正确的查询计划？是否需要使用优化器提示？还是可以使用提示？ + +TiDB 包含一个基于成本的优化器。在大多数情况下，优化器会为你选择最优的查询计划。如果优化器工作欠佳，你可以使用[优化器提示](/optimizer-hints.md)来干预优化器。 + +另外，你还可以使用[执行计划绑定](/sql-plan-management.md#执行计划绑定-sql-binding)来为特定的 SQL 语句固定查询计划。 + +## 如何阻止特定的 SQL 语句执行（或者将某个 SQL 语句加入黑名单）？ + +你可以使用 [`MAX_EXECUTION_TIME`](/optimizer-hints.md#max_execution_timen) Hint 来创建 [SQL 绑定](/sql-plan-management.md#执行计划绑定-sql-binding)，将特定语句的执行时间限制为一个较小的值（例如 1ms）。这样，语句就会在超过限制时自动终止。 + +例如，要阻止执行 `SELECT * FROM t1, t2 WHERE t1.id = t2.id`，可以使用以下 SQL 绑定将语句的执行时间限制为 1ms： + +```sql +CREATE GLOBAL BINDING for + SELECT * FROM t1, t2 WHERE t1.id = t2.id +USING + SELECT /*+ MAX_EXECUTION_TIME(1) */ * FROM t1, t2 WHERE t1.id = t2.id; +``` + +> **注意：** +> +> `MAX_EXECUTION_TIME` 的精度大约为 100ms。在 TiDB 终止 SQL 语句之前，TiKV 中的任务可能已经开始执行。为了减少这种情况下 TiKV 的资源消耗，建议将系统变量 [`tidb_enable_paging`](/system-variables.md#tidb_enable_paging-从-v540-版本开始引入) 的值设置为 `ON`。 + +删除该 SQL 绑定可以移除限制。 + +```sql +DROP GLOBAL BINDING for + SELECT * FROM t1, t2 WHERE t1.id = t2.id; +``` + +## TiDB 对哪些 MySQL variables 兼容？ + +详细可参考[系统变量](/system-variables.md)。 + +## 省略 `ORDER BY` 条件时 TiDB 中返回结果的顺序与 MySQL 中的不一致 + +这不是 bug。返回结果的顺序视不同情况而定，不保证顺序统一。 + +MySQL 中，返回结果的顺序可能较为固定，因为查询是通过单线程执行的。但升级到新版本后，查询计划也可能变化。无论是否期待返回结果有序，都推荐使用 `ORDER BY` 条件。 + +[ISO/IEC 9075:1992, Database Language SQL- July 30, 1992](http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt) 对此有如下表述： + +> If an `` is not specified, then the table specified by the `` is T and the ordering of rows in T is implementation-dependent.（如果未指定 ``，通过 `` 指定的表为 T，那么 T 表中的行顺序视执行情况而定。） + +以下两条查询的结果都是合法的： + +```sql +> select * from t; ++------+------+ +| a | b | ++------+------+ +| 1 | 1 | +| 2 | 2 | ++------+------+ +2 rows in set (0.00 sec) +``` + +```sql +> select * from t; -- 不确定返回结果的顺序 ++------+------+ +| a | b | ++------+------+ +| 2 | 2 | +| 1 | 1 | ++------+------+ +2 rows in set (0.00 sec) +``` + +如果 `ORDER BY` 中使用的列不是唯一列，就无法确定该语句返回结果的顺序。在以下示例中，`a` 列有重复值，因此只有 `ORDER BY a, b` 能确定返回结果的顺序。 + +```sql +> select * from t order by a; ++------+------+ +| a | b | ++------+------+ +| 1 | 1 | +| 2 | 1 | +| 2 | 2 | ++------+------+ +3 rows in set (0.00 sec) +``` + +在以下示例中，`order by a` 能确定 a 列的顺序，但不能确定 b 列的顺序。 + +```sql +> select * from t order by a; ++------+------+ +| a | b | ++------+------+ +| 1 | 1 | +| 2 | 2 | +| 2 | 1 | ++------+------+ +3 rows in set (0.00 sec) +``` + +在 TiDB 中，你还可以使用系统变量 [`tidb_enable_ordered_result_mode`](/system-variables.md#tidb_enable_ordered_result_mode) 来指定是否对最终的输出结果进行自动排序。 + +## TiDB 是否支持 `SELECT FOR UPDATE`？ + +支持。当 TiDB 使用悲观锁（自 TiDB v3.0.8 起默认使用）时，TiDB 中 `SELECT FOR UPDATE` 的行为与 MySQL 中的基本一致。 + +当 TiDB 使用乐观锁时，`SELECT FOR UPDATE` 不会在事务启动时对数据加锁，而是在提交事务时检查冲突。如果检查出冲突，会回滚待提交的事务。 + +详情参考 [SELECT 语句语法元素说明](/sql-statements/sql-statement-select.md#语法元素说明)。 + +## TiDB 的 codec 能保证 UTF8 的字符串是 memcomparable 的吗？我们的 key 需要支持 UTF8，有什么编码建议吗？ + +TiDB 字符集默认就是 UTF8 而且目前只支持 UTF8，字符串就是 memcomparable 格式的。 + +## 一个事务中的语句数量最大是多少？ + +一个事务中的语句数量，默认限制最大为 5000 条。 + +在使用乐观事务并开启事务重试的情况下，默认限制 5000，可通过 [`stmt-count-limit`](/tidb-configuration-file.md#stmt-count-limit) 调整。 + +## TiDB 中，为什么出现后插入数据的自增 ID 反而小？ + +TiDB 的自增 ID (`AUTO_INCREMENT`) 只保证自增且唯一，并不保证连续分配。TiDB 目前采用批量分配的方式，所以如果在多台 TiDB server 上同时插入数据，分配的自增 ID 会不连续。当多个线程并发往不同的 TiDB server 插入数据的时候，有可能会出现后插入的数据自增 ID 小的情况。此外，TiDB 允许给整型类型的字段指定 AUTO_INCREMENT，且一个表只允许一个属性为 `AUTO_INCREMENT` 的字段。详情可参考[自增 ID](/mysql-compatibility.md#自增-id)和 [AUTO_INCREMENT](/auto-increment.md)。 + +## 如何在 TiDB 中修改 `sql_mode`？ + +TiDB 支持在会话或全局作用域上修改 [`sql_mode`](/system-variables.md#sql_mode) 系统变量。 + +- 对全局作用域变量的修改，设置后将作用于集群中的其它服务器，并且重启后更改依然有效。因此，你无需在每台 TiDB 服务器上都更改 `sql_mode` 的值。 +- 对会话作用域变量的修改，设置后只影响当前会话，重启后更改消失。 + +## 用 Sqoop 批量写入 TiDB 数据，虽然配置了 `--batch` 选项，但还是会遇到 `java.sql.BatchUpdateException:statement count 5001 exceeds the transaction limitation` 的错误，该如何解决？ + +问题原因：在 Sqoop 中，`--batch` 是指每个批次提交 100 条 statement，但是默认每个 statement 包含 100 条 SQL 语句，所以此时 100 * 100 = 10000 条 SQL 语句，超出了 TiDB 的事务限制 5000 条。 + +解决办法： + +- 增加选项 `-Dsqoop.export.records.per.statement=10`，完整的用法如下： + + ```bash + sqoop export \ + -Dsqoop.export.records.per.statement=10 \ + --connect jdbc:mysql://mysql.example.com/sqoop \ + --username sqoop ${user} \ + --password ${passwd} \ + --table ${tab_name} \ + --export-dir ${dir} \ + --batch + ``` + +- 也可以选择增大 TiDB 的单个事物语句数量限制，不过此操作会导致内存增加。详情参见 [SQL 语句的限制](/tidb-limitations.md#sql-statements-的限制)。 + +## TiDB 有像 Oracle 那样的 Flashback Query 功能么，DDL 支持么？ + +有，也支持 DDL。详细参考[使用 AS OF TIMESTAMP 语法读取历史数据](/as-of-timestamp.md)。 + +## TiDB 中删除数据后会立即释放空间吗？ + +在 TiDB 中使用 `DELETE`，`TRUNCATE` 和 `DROP` 语句删除数据都不会立即释放空间。对于 `TRUNCATE` 和 `DROP` 操作，在达到 TiDB 的 GC (garbage collection) 时间后（默认 10 分钟），TiDB 的 GC 机制会删除数据并释放空间。对于 DELETE 操作，TiDB 的 GC 机制会删除数据，但不会立即释放空间，而是等到后续进行 compaction 时释放空间。 + +## 删除数据后查询速度为何会变慢？ + +删除大量数据后，会有很多无用的 key 存在，影响查询效率。要解决该问题，可以尝试开启 [Region Merge](/best-practices/massive-regions-best-practices.md#方法五开启-region-merge) 功能，具体可参考[最佳实践](https://pingcap.com/blog-cn/tidb-best-practice/)中的删除数据部分。 + +## 对数据做删除操作之后，空间回收比较慢，如何处理？ + +TiDB 采用了多版本并发控制 (MVCC) 机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。为了使并发事务能查看到早期版本的数据，删除数据时 TiDB 不会立即回收空间，而是等待一段时间后再进行垃圾回收 (GC)。要配置历史数据的保留时限，你可以修改系统变量 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-从-v50-版本开始引入)的值（默认值为 `10m0s`）。 + +## `SHOW PROCESSLIST` 是否显示系统进程号？ + +TiDB 中的 `SHOW PROCESSLIST` 与 MySQL 中的 `SHOW PROCESSLIST` 显示内容基本一致，不会显示系统进程号。而返回结果中的 ID 表示当前的 session ID。其中 TiDB 的 `SHOW PROCESSLIST` 和 MySQL 的 `SHOW PROCESSLIST` 区别如下： + ++ 由于 TiDB 是分布式数据库，TiDB server 实例是无状态的 SQL 解析和执行引擎（详情可参考 [TiDB 整体架构](/tidb-architecture.md)），用户使用 MySQL 客户端登录的是哪个 TiDB server，`SHOW PROCESSLIST` 就会显示当前连接的这个 TiDB server 中执行的 session 列表，不是整个集群中运行的全部 session 列表；而 MySQL 是单机数据库，`SHOW PROCESSLIST` 列出的是当前整个 MySQL 数据库的全部执行 SQL 列表。 + ++ 在查询执行期间，TiDB 中的 `State` 列不会持续更新。由于 TiDB 支持并行查询，每个语句可能同时处于多个状态，因此很难显示为某一种状态。 + +## 在 TiDB 中如何控制或改变 SQL 提交的执行优先级？ + +TiDB 支持改变[全局](/system-variables.md#tidb_force_priority)或单个语句的优先级。优先级包括： + +- `HIGH_PRIORITY`：该语句为高优先级语句，TiDB 在执行阶段会优先处理这条语句 +- `LOW_PRIORITY`：该语句为低优先级语句，TiDB 在执行阶段会降低这条语句的优先级 +- `DELAYED`：该语句为正常优先级语句，TiDB 不强制改变这条语句的优先级，与 `tidb_force_priority` 设置为 `NO_PRIORITY` 相同 + +> **注意：** +> +> TiDB 从 v6.6.0 版本开始支持[使用资源管控 (Resource Control) 实现资源隔离](/tidb-resource-control.md)功能。该功能可以将不同优先级的语句放在不同的资源组中执行，并为这些资源组分配不同的配额和优先级，可以达到更好的资源管控效果。在开启资源管控功能后，语句的调度主要受资源组的控制，`PRIORITY` 将不再生效。建议在支持资源管控的版本优先使用资源管控功能。 + +以上两种参数可以结合 TiDB 的 DML 语言进行使用，使用方法举例如下： + +1. 通过在数据库中写 SQL 的方式来调整优先级： + + ```sql + SELECT HIGH_PRIORITY | LOW_PRIORITY | DELAYED COUNT(*) FROM table_name; + INSERT HIGH_PRIORITY | LOW_PRIORITY | DELAYED INTO table_name insert_values; + DELETE HIGH_PRIORITY | LOW_PRIORITY | DELAYED FROM table_name; + UPDATE HIGH_PRIORITY | LOW_PRIORITY | DELAYED table_reference SET assignment_list WHERE where_condition; + REPLACE HIGH_PRIORITY | LOW_PRIORITY | DELAYED INTO table_name; + ``` + +2. 全表扫会自动调整为低优先级，[`ANALYZE`](/sql-statements/sql-statement-analyze-table.md) 也是默认低优先级。 + +## 在 TiDB 中 `auto analyze` 的触发策略是怎样的？ + +当一张表或分区表的单个分区达到 1000 条记录，且表或分区的（修改数/当前总行数）比例大于 [`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio) 的时候，会自动触发 [`ANALYZE`](/sql-statements/sql-statement-analyze-table.md) 语句。 + +`tidb_auto_analyze_ratio` 的默认值为 `0.5`，即默认开启触发 `auto analyze`。注意该变量值不建议大于等于 [`pseudo-estimate-ratio`](/tidb-configuration-file.md#pseudo-estimate-ratio)（默认值为 `0.8`），否则优化器可能会使用 pseudo 统计信息。TiDB 从 v5.3.0 开始引入 [`tidb_enable_pseudo_for_outdated_stats`](/system-variables.md#tidb_enable_pseudo_for_outdated_stats-从-v530-版本开始引入) 变量，当设置为 `OFF` 时，即使统计信息过期也不会使用 pseudo 统计信息。 + +你可以用系统变量 [`tidb_enable_auto_analyze`](/system-variables.md#tidb_enable_auto_analyze-从-v610-版本开始引入) 关闭 `auto analyze`。 + +## 可以使用 Optimizer Hints 控制优化器行为吗？ + +在 TiDB 中，你可以用多种方法控制查询优化器的默认行为，包括使用 [Optimizer Hints](/optimizer-hints.md) 和 [SQL 执行计划管理 (SPM)](/sql-plan-management.md)。基本用法同 MySQL 中的一致，还包含若干 TiDB 特有的用法，例如：`select column_name from table_name use index（index_name）where where_condition;`。 + +## DDL 执行 + +本节列出了 DDL 语句执行的相关问题。DDL 执行原理的详细说明，参见 [TiDB 中 DDL 执行原理及最佳实践](/ddl-introduction.md)。 + +### 各类 DDL 操作的预估耗时是多长？ + +假设 DDL 操作没有被阻塞，各个 TiDB server 能够正常更新 Schema 版本，DDL Owner 节点正常运行。在此情况下，各类 DDL 操作的预估耗时如下： + +| DDL 操作类型 | 预估耗时 | +|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-----------------------| +| Reorg DDL：例如 `ADD INDEX`、`MODIFY COLUMN`（Reorg 类型的数据更改） | 取决于数据量、系统负载以及 DDL 参数的设置 | +| General DDL（除 Reorg DDL 外的 DDL 类型）：例如 `CREATE DATABASE`、`CREATE TABLE`、`DROP DATABASE`、`DROP TABLE`、`TRUNCATE TABLE`、`ALTER TABLE ADD`、`ALTER TABLE DROP`、`MODIFY COLUMN`（只更改元数据）、`DROP INDEX` | 1 秒左右 | + +> **注意：** +> +> 以上为各类操作的预估耗时，请以实际操作耗时为准。 + +## 执行 DDL 会慢的可能原因 + +- 在一个用户会话中，DDL 语句之前有非 auto-commit 的 DML 语句，并且该 DML 语句的提交操作比较慢，会导致 DDL 语句执行慢。即执行 DDL 语句前，会先提交之前没有提交的 DML 语句。 +- 多个 DDL 语句一起执行的时候，后面的几个 DDL 语句可能会比较慢，因为可能需要排队等待。排队场景包括： + - 同一类型 DDL 语句需要排队（例如 `CREATE TABLE` 和 `CREATE DATABASE` 都是 General DDL，两个操作同时执行时，需要排队）。自 TiDB v6.2.0 起，支持并行 DDL 语句，但为了避免 DDL 使用过多 TiDB 的计算资源，也有并发度限制，因此会有一定的排队情况。 + - 对同一张表上执行的 DDL 操作存在依赖关系，后面的 DDL 语句需要等待前面的 DDL 操作完成。 +- 在集群正常启动后，第一个 DDL 操作的执行时间可能会比较久，可能是因为 DDL 模块在进行 DDL Owner 的选举。 + +- 终止 TiDB 时，TiDB 不能与 PD 正常通信（包括停电的情况），或者用 `kill -9` 命令终止 TiDB 导致 TiDB 没有及时从 PD 清理注册数据。 +- 集群中某个 TiDB 与 PD 或者 TiKV 之间发生通信问题，即 TiDB 不能及时获取最新版本信息。 + +### 触发 Information schema is changed 错误的原因？ + +TiDB 在执行 SQL 语句时，会根据隔离级别确定一个对象的 `schema` 版本来处理该 SQL 语句，而且 TiDB 支持在线异步变更 DDL。那么，在执行 DML 的时候可能有 DDL 语句也在执行，而你需要确保每个 SQL 语句在同一个 `schema` 上执行。所以当执行 DML 时，如果遇到正在执行中的 DDL 操作，TiDB 可能会报 `Information schema is changed` 的错误。 + +从 v6.4.0 开始，TiDB 实现了[元数据锁机制](/metadata-lock.md)，可以让 DML 语句的执行和 DDL Schema 变更协同进行，可以避免大部分 `Information schema is changed` 错误的发生。 + +报错的可能原因如下： + +- 原因 1：正在执行的 DML 所涉及的表和集群中正在执行的 DDL 的表有相同的，那么这个 DML 语句就会报此错。可以通过命令 `admin show ddl job` 查看正在执行的 DDL 操作。 +- 原因 2：这个 DML 执行时间很久，而这段时间内执行了很多 DDL 语句，导致中间 `schema` 版本变更次数超过 1024 （此为默认值，可以通过 `tidb_max_delta_schema_count` 变量修改）。 +- 原因 3：接受 DML 请求的 TiDB 长时间不能加载到 `schema information`（TiDB 与 PD 或 TiKV 之间的网络连接故障等会导致此问题），而这段时间内执行了很多 DDL 语句，导致中间 `schema` 版本变更次数超过 100。 +- 原因 4：TiDB 重启后执行第一个 DDL 操作前，执行 DML 操作，并且在执行过程中遇到了第 1 个 DDL 操作（即在执行第 1 个 DDL 操作前，启动该 DML 对应的事务，且在该 DDL 变更第一个 `schema` 版本后，提交该 DML 对应的事务），那么这个 DML 会报此错。 + +以上原因中，只有原因 1 与表有关。原因 1 和原因 2 都不会导致业务问题，相应的 DML 会在失败后重试。对于原因 3，需要检查 TiDB 实例和 PD 及 TiKV 的网络情况。 + +> **注意：** +> +> + 目前 TiDB 未缓存所有的 `schema` 版本信息。 +> + 对于每个 DDL 操作，`schema` 版本变更的数量与对应 `schema state` 变更的次数一致。 +> + 不同的 DDL 操作版本变更次数不一样。例如，`create table` 操作会有 1 次 `schema` 版本变更；`add column` 操作有 4 次 `schema` 版本变更。 + +### 触发 Information schema is out of date 错误的原因？ + +在 v6.5.0 之前，当执行 DML 时，TiDB 超过一个 DDL lease 时间（默认 45s）没能加载到最新的 schema 就可能会报 `Information schema is out of date` 的错误。遇到此错的可能原因如下： + +- 执行此 DML 的 TiDB 被 kill 后准备退出，且此 DML 对应的事务执行时间超过一个 DDL lease，在事务提交时会报这个错误。 +- TiDB 在执行此 DML 时，有一段时间内连不上 PD 或者 TiKV，导致 TiDB 超过一个 DDL lease 时间没有 load schema，或者导致 TiDB 断开与 PD 之间带 keep alive 设置的连接。 + +### 高并发情况下执行 DDL 时报错的原因？ + +高并发场景下执行 DDL 语句（比如批量建表）时，极少部分的 DDL 语句可能会由于并发执行时 key 冲突而执行失败。 + +并发执行 DDL 语句时，建议将 DDL 语句数量保持在 20 以下，否则你需要在应用端重试失败的 DDL 语句。 + +### DDL 执行被阻塞的原因 + +在 TiDB v6.2.0 前，TiDB 按照 DDL 语句类型将 DDL 分配到两个先入先出的队列中，即 Reorg DDL 进入 Reorg 队列中，General DDL 进入 general 队列中。由于先入先出以及同一张表上的 DDL 语句需要串行执行，多个 DDL 语句在执行过程中可能会出现阻塞的问题。 + +例如对于以下 DDL 语句： + +- DDL 1：`CREATE INDEX idx on t(a int);` +- DDL 2：`ALTER TABLE t ADD COLUMN b int;` +- DDL 3：`CREATE TABLE t1(a int);` + +由于队列先入先出的限制，DDL 3 需要等待 DDL 2 执行。同时又因为同一张表上的 DDL 语句需要串行执行，DDL 2 需要等待 DDL 1 执行。因此，DDL 3 需要等待 DDL 1 先执行完，即使它们操作在不同的表上。 + +在 TiDB v6.2.0 及之后的版本中，TiDB DDL 模块采用了并发框架。在并发的框架下，不再有同一个队列先进先出的问题，而是从所有 DDL 任务中选出可以执行的 DDL 来执行。并且对 Reorg worker 的数量进行了扩充，大概为节点 `CPU/4`，这使得在并发框架中 TiDB 可以同时为多张表建索引。 + +无论是新集群还是从旧版本升级的集群，在 TiDB v6.2 及以上版本中，TiDB 都会自动使用并发框架，用户无需进行调整。 + +### 定位 DDL 执行卡住的问题 + +1. 先排除 DDL 语句通常执行慢的可能原因。 +2. 使用以下任一方法找出 DDL owner 节点： + + 通过 `curl http://{TiDBIP}:10080/info/all` 获取当前集群的 Owner + + 通过监控 **DDL** > **DDL META OPM** 查看某个时间段的 Owner + +- 如果 Owner 不存在，尝试手动触发 Owner 选举：`curl -X POST http://{TiDBIP}:10080/ddl/owner/resign`。 +- 如果 Owner 存在，导出 Goroutine 堆栈并检查可能卡住的地方。 + +## SQL 优化 + +### TiDB 执行计划解读 + +详细解读[理解 TiDB 执行计划](/explain-overview.md)。 + +### 统计信息收集 + +详细解读[统计信息](/statistics.md)。 + +### Count 如何加速？ + +Count 就是暴力扫表，提高并发度能显著提升扫表速度。如要调整并发度，可以使用 `tidb_distsql_scan_concurrency` 变量，但调整并发度需要同时考虑 CPU 和 I/O 资源。TiDB 每次执行查询时，都要访问 TiKV。在数据量小的情况下，MySQL 的数据都在内存里，而 TiDB 还需要进行一次网络访问。 + +加速建议： + +- 提升硬件配置，可以参考[部署建议](/hardware-and-software-requirements.md)。 +- 提升并发度，默认是 10，可以尝试提升到 50，但是一般提升幅度在 2-4 倍之间。 +- 测试大数据量的 count。 +- 调优 TiKV 配置，可以参考[性能调优](/tune-tikv-memory-performance.md)。 +- 参考[下推计算结果缓存](/coprocessor-cache.md)。 + +### 查看当前 DDL 的进度？ + +通过 `ADMIN SHOW DDL` 语句查看当前 job 进度。操作如下： + +```sql +ADMIN SHOW DDL; +``` + +```sql +*************************** 1. row *************************** + SCHEMA_VER: 140 + OWNER: 1a1c4174-0fcd-4ba0-add9-12d08c4077dc +RUNNING_JOBS: ID:121, Type:add index, State:running, SchemaState:write reorganization, SchemaID:1, TableID:118, RowCount:77312, ArgLen:0, start time: 2018-12-05 16:26:10.652 +0800 CST, Err:, ErrCount:0, SnapshotVersion:404749908941733890 + SELF_ID: 1a1c4174-0fcd-4ba0-add9-12d08c4077dc +``` + +从以上返回结果可知，当前正在处理的是 `ADD INDEX` 操作。且从 `RUNNING_JOBS` 列的 `RowCount` 字段可以知道当前 `ADD INDEX` 操作已经添加了 77312 行索引。 + +### 如何查看 DDL job？ + +可以使用 `ADMIN SHOW DDL` 语句查看正在运行的 DDL 作业。 + +- `ADMIN SHOW DDL JOBS`：用于查看当前 DDL 作业队列中的所有结果（包括正在运行以及等待运行的任务）以及已执行完成的 DDL 作业队列中的最近十条结果。 +- `ADMIN SHOW DDL JOBS QUERIES 'job_id' [, 'job_id'] ...`：用于显示 `job_id` 对应的 DDL 任务的原始 SQL 语句。此 `job_id` 只搜索正在执行中的任务以及 DDL 历史作业队列中的最近十条结果。 + +### TiDB 是否支持基于 COST 的优化 (CBO)？如果支持，实现到什么程度？ + +是的，TiDB 基于成本的优化器 (CBO) 对代价模型、统计信息进行持续优化。除此之外，TiDB 还支持 hash join、sort-merge join 等 join 算法。 + +### 如何确定某张表是否需要做 analyze ？ + +可以通过 `SHOW STATS_HEALTHY` 来查看 Healthy 字段，一般该字段值小于等于 60 的表需要做 analyze。 + +### SQL 的执行计划展开成了树，ID 的序号有什么规律吗？这棵树的执行顺序会是怎么样的？ + +ID 没什么规律，只要是唯一就行。不过在生成执行计划时，有一个计数器，生成一个计划 ID 后序号就加 1，执行的顺序和序号无关。整个执行计划是一颗树，执行时从根节点开始，不断地向上返回数据。要理解执行计划，请参考[理解 TiDB 执行计划](/explain-overview.md)。 + +### TiDB 执行计划中，task cop 在一个 root 下，这个是并行的吗？ + +目前 TiDB 的计算任务隶属于两种不同的 task：cop task 和 root task。cop task 是指被下推到 KV 端分布式执行的计算任务，root task 是指在 TiDB 端单点执行的计算任务。 + +一般来讲 root task 的输入数据是来自于 cop task 的，但是 root task 在处理数据的时候，TiKV 上的 cop task 也可以同时处理数据，等待 TiDB 的 root task 拉取。所以从这个过程来看，root task 和 cop task 是并行的，同时存在数据上下游关系。 + +在执行的过程中，某些时间段也可能是并行的，第一个 cop task 在处理 [100, 200] 的数据，第二个 cop task 在处理 [1, 100] 的数据。执行计划的理解，请参考[理解 TiDB 执行计划](/explain-overview.md)。 + +## 数据库优化 + +### TiDB 参数及调整 + +详情参考 [TiDB 配置参数](/command-line-flags-for-tidb-configuration.md)。 + +### 如何避免热点问题并实现负载均衡？TiDB 中是否有热分区或热范围问题？ + +要了解热点问题的场景，请参考[常见热点问题](/troubleshoot-hot-spot-issues.md#常见热点场景)。TiDB 的以下特性旨在帮助解决热点问题： + +- [`SHARD_ROW_ID_BITS`](/troubleshoot-hot-spot-issues.md#使用-shard_row_id_bits-处理热点表) 属性。设置该属性后，行 ID 会被打散并写入多个 Region，以缓解写入热点问题。 +- [`AUTO_RANDOM`](/troubleshoot-hot-spot-issues.md#使用-auto_random-处理自增主键热点表) 属性，用于解决自增主键带来的热点问题。 +- [Coprocessor Cache](/coprocessor-cache.md)，针对小表的读热点问题。 +- [Load Base Split](/configure-load-base-split.md)，针对因 Region 访问不均衡（例如小表全表扫）而导致的热点问题。 +- [缓存表](/cached-tables.md)，针对被频繁访问但更新较少的小热点表。 + +如果你遇到因热点引起的性能问题，可参考[处理热点问题](/troubleshoot-hot-spot-issues.md)。 + +### TiKV 性能参数调优 + +详情参考 [TiKV 性能参数调优](/tune-tikv-memory-performance.md)。 diff --git a/grafana-tikv-dashboard.md b/grafana-tikv-dashboard.md index a34c45fcde45..34fc86394d49 100644 --- a/grafana-tikv-dashboard.md +++ b/grafana-tikv-dashboard.md @@ -1,6 +1,7 @@ --- title: TiKV 监控指标详解 aliases: ['/docs-cn/dev/grafana-tikv-dashboard/','/docs-cn/dev/reference/key-monitoring-metrics/tikv-dashboard/'] +summary: TiKV 监控指标详解：TiUP 部署 TiDB 集群时，一键部署监控系统 (Prometheus & Grafana)，监控架构详见 TiDB 监控框架概述。Grafana Dashboard 分为 PD、TiDB、TiKV、Node_exporter、Overview、Performance_overview 等。对于日常运维，通过观察 TiKV-Details 面板上的指标，可以了解 TiKV 当前的状态。根据性能地图，可以检查集群的状态是否符合预期。TiKV-Details 默认的监控信息包括 Cluster、Errors、Server、gRPC、Thread CPU、PD、Raft IO、Raft process、Raft message、Raft propose、Raft admin、Local reader、Unified Read Pool、Storage、Flow Control、Scheduler 等。 --- # TiKV 监控指标详解 diff --git a/identify-slow-queries.md b/identify-slow-queries.md index 5be775d7c4e3..11f716ab37f8 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -1,6 +1,7 @@ --- title: 慢查询日志 aliases: ['/docs-cn/dev/identify-slow-queries/','/docs-cn/dev/how-to/maintain/identify-abnormal-queries/identify-slow-queries/','/docs-cn/sql/slow-query/','/docs-cn/dev/how-to/maintain/identify-slow-queries/'] +summary: TiDB 会将执行时间超过 300 毫秒的语句输出到慢查询日志中，用于帮助用户定位慢查询语句。可以通过修改系统变量来启用或禁用慢查询日志。日志示例包括执行时间、用户信息、执行计划等字段。用户可通过查询 SLOW_QUERY 表来查询慢查询日志中的内容。还可以使用 pt-query-digest 工具分析 TiDB 慢日志。ADMIN SHOW SLOW 命令可以显示最近的慢查询记录或最慢的查询记录。 --- # 慢查询日志 diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index f0b0ba172215..4c7ea7910353 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -1,173 +1,173 @@ ---- -title: 单区域多 AZ 部署 TiDB -summary: 本文档介绍单个区域多个可用区部署 TiDB 的方案。 -aliases: ['/docs-cn/dev/how-to/deploy/geographic-redundancy/overview/','/docs-cn/dev/geo-redundancy-deployment/'] ---- - -# 单区域多 AZ 部署 TiDB - - - -作为一栈式实时 HTAP 数据库，TiDB 兼顾了传统关系型数据库的优秀特性、NoSQL 数据库可扩展性以及跨可用区 (Availability Zone, AZ) 场景下的高可用。本文档旨在介绍同区域多 AZ 部署 TiDB 的方案。 - -本文中的区域指的是地理隔离的不同位置，AZ 指的是区域内部划分的相互独立的资源集合。本文描述的方案同样适用于一个城市内多个数据中心（同城多中心）的场景。 - -## 了解 Raft 协议 - -Raft 是一种分布式一致性算法，在 TiDB 集群的多种组件中，PD 和 TiKV 都通过 Raft 实现了数据的容灾。Raft 的灾难恢复能力通过如下机制实现： - -- Raft 成员的本质是日志复制和状态机。Raft 成员之间通过复制日志来实现数据同步；Raft 成员在不同条件下切换自己的成员状态，其目标是选出 leader 以提供对外服务。 -- Raft 是一个表决系统，它遵循多数派协议，在一个 Raft Group 中，某成员获得大多数投票，它的成员状态就会转变为 leader。也就是说，当一个 Raft Group 还保有大多数节点 (majority) 时，它就能够选出 leader 以提供对外服务。 - -遵循 Raft 可靠性的特点，放到现实场景中： - -- 想克服任意 1 台服务器 (host) 的故障，应至少提供 3 台服务器。 -- 想克服任意 1 个机柜 (rack) 的故障，应至少提供 3 个机柜。 -- 想克服任意 1 个可用区（AZ，也可以是同城的多个机房）的故障，应至少提供 3 个 AZ。 - -- 想应对任意 1 个区域的灾难场景，应至少规划 3 个区域用于部署集群。 - -可见，原生 Raft 协议对于偶数副本的支持并不是很友好，考虑跨区域网络延迟影响，同区域三 AZ 可能是最适合部署 Raft 的高可用及容灾方案。 - -## 同区域三 AZ 方案 - -同区域三 AZ 方案，即同区域有三个机房部署 TiDB 集群，AZ 间的数据在集群内部（通过 Raft 协议）进行同步。同区域三 AZ 可同时对外进行读写服务，任意中心发生故障不影响数据一致性。 - -### 简易架构图 - -集群 TiDB、TiKV 和 PD 组件分别部署在 3 个不同的 AZ，这是最常规且高可用性最高的方案。 - -![三 AZ 部署](/media/deploy-3dc.png) - -**优点：** - -- 所有数据的副本分布在三个 AZ，具备高可用和容灾能力 -- 任何一个 AZ 失效后，不会产生任何数据丢失 (RPO = 0) -- 任何一个 AZ 失效后，其他两个 AZ 会自动发起 leader election，并在一定时间内（通常 20s 以内）自动恢复服务 - -![三 AZ 部署容灾](/media/deploy-3dc-dr.png) - -**缺点：** - -性能受网络延迟影响。具体影响如下： - -- 对于写入的场景，所有写入的数据需要同步复制到至少两个 AZ，由于 TiDB 写入过程使用两阶段提交，故写入延迟至少需要两倍 AZ 间的延迟。 - -- 对于读请求来说，如果数据 leader 与发起读取的 TiDB 节点不在同一个 AZ，也会受网络延迟影响。 -- TiDB 中的每个事务都需要向 PD leader 获取 TSO，当 TiDB 与 PD leader 不在同一个 AZ 时，TiDB 上运行的事务也会因此受网络延迟影响，每个有写入的事务会获取两次 TSO。 - -### 架构优化图 - -如果不需要每个 AZ 同时对外提供服务，可以将业务流量全部派发到一个 AZ，并通过调度策略把 Region leader 和 PD leader 都迁移到同一个 AZ。这样，不管是从 PD 获取 TSO，还是读取 Region，都不会受 AZ 间网络的影响。当该 AZ 失效时，PD leader 和 Region leader 会自动在其它 AZ 选出，只需要把业务流量转移至其他存活的 AZ 即可。 - -![三 AZ 部署读性能优化](/media/deploy-3dc-optimize.png) - -**优点：** - -集群 TSO 获取能力以及读取性能有所提升。具体调度策略设置模板参照如下： - -```shell --- 其他 AZ 将 leader 驱逐至承载业务流量的 AZ - -config set label-property reject-leader LabelName labelValue - --- 迁移 PD leader 并设置优先级 -member leader transfer pdName1 -member leader_priority pdName1 5 -member leader_priority pdName2 4 -member leader_priority pdName3 3 -``` - -> **注意：** -> -> TiDB 5.2 及以上版本默认不支持 `label-property` 配置。若要设置副本策略，请使用 [Placement Rules](/configure-placement-rules.md)。 - -**缺点：** - -- 写入场景仍受 AZ 网络延迟影响，这是因为遵循 Raft 多数派协议，所有写入的数据需要同步复制到至少两个 AZ - -- TiDB Server 是 AZ 级别单点 -- 业务流量纯走单 AZ，性能受限于单 AZ 网络带宽压力 -- TSO 获取能力以及读取性能受限于业务流量 AZ 集群 PD、TiKV 组件是否正常，否则仍受跨 AZ 网络交互影响 - -### 样例部署图 - -#### 样例拓扑架构 - -假设某区域有三个 AZ，AZ1、AZ2 和 AZ3。每个 AZ 中有两套机架，每个机架有三台服务器，不考虑混合布署以及单台机器多实例部署，同区域三 AZ 架构集群（3 副本）部署参考如下： - -![同区域三 AZ 集群部署](/media/multi-data-centers-in-one-city-deployment-sample.png) - -#### TiKV Labels 简介 - -TiKV 是一个 Multi-Raft 系统，其数据按 Region（默认 96M）切分，每个 Region 的 3 个副本构成了一个 Raft Group。假设一个 3 副本 TiDB 集群，由于 Region 的副本数与 TiKV 实例数量无关，则一个 Region 的 3 个副本只会被调度到其中 3 个 TiKV 实例上，也就是说即使集群扩容 N 个 TiKV 实例，其本质仍是一个 3 副本集群。 - -由于 3 副本的 Raft Group 只能容忍 1 副本故障，当集群被扩容到 N 个 TiKV 实例时，这个集群依然只能容忍一个 TiKV 实例的故障。2 个 TiKV 实例的故障可能会导致某些 Region 丢失多个副本，整个集群的数据也不再完整，访问到这些 Region 上的数据的 SQL 请求将会失败。而 N 个 TiKV 实例中同时有两个发生故障的概率是远远高于 3 个 TiKV 中同时有两个发生故障的概率的，也就是说 Multi-Raft 系统集群扩容 TiKV 实例越多，其可用性是逐渐降低的。 - -正因为 Multi-Raft TiKV 系统局限性，Labels 标签应运而出，其主要用于描述 TiKV 的位置信息。Label 信息随着部署或滚动更新操作刷新到 TiKV 的启动配置文件中，启动后的 TiKV 会将自己最新的 Label 信息上报给 PD，PD 根据用户登记的 Label 名称（也就是 Label 元信息），结合 TiKV 的拓扑进行 Region 副本的最优调度，从而提高系统可用性。 - -#### TiKV Labels 样例规划 - -针对 TiKV Labels 标签，你需要根据已有的物理资源、容灾能力容忍度等方面进行设计与规划，进而提升系统的可用性和容灾能力。并根据已规划的拓扑架构，在集群初始化配置文件中进行配置（此处省略其他非重点项）： - -```ini -server_configs: - pd: - replication.location-labels: ["zone","az","rack","host"] - -tikv_servers: - - host: 10.63.10.30 - config: - server.labels: { zone: "z1", az: "az1", rack: "r1", host: "30" } - - host: 10.63.10.31 - config: - server.labels: { zone: "z1", az: "az1", rack: "r1", host: "31" } - - host: 10.63.10.32 - config: - server.labels: { zone: "z1", az: "az1", rack: "r2", host: "32" } - - host: 10.63.10.33 - config: - server.labels: { zone: "z1", az: "az1", rack: "r2", host: "33" } - - - host: 10.63.10.34 - config: - server.labels: { zone: "z2", az: "az2", rack: "r1", host: "34" } - - host: 10.63.10.35 - config: - server.labels: { zone: "z2", az: "az2", rack: "r1", host: "35" } - - host: 10.63.10.36 - config: - server.labels: { zone: "z2", az: "az2", rack: "r2", host: "36" } - - host: 10.63.10.37 - config: - server.labels: { zone: "z2", az: "az2", rack: "r2", host: "37" } - - - host: 10.63.10.38 - config: - server.labels: { zone: "z3", az: "az3", rack: "r1", host: "38" } - - host: 10.63.10.39 - config: - server.labels: { zone: "z3", az: "az3", rack: "r1", host: "39" } - - host: 10.63.10.40 - config: - server.labels: { zone: "z3", az: "az3", rack: "r2", host: "40" } - - host: 10.63.10.41 - config: - server.labels: { zone: "z3", az: "az3", rack: "r2", host: "41" } -``` - -本例中，zone 表示逻辑可用区层级，用于控制副本的隔离（当前集群 3 副本）。 - -不直接采用 az、rack 和 host 三层 Label 结构，是因为考虑到将来可能会扩容 AZ，假设新扩容的 AZ 编号是 AZ2、AZ3 和 AZ4，则只需在对应可用区下扩容 AZ，rack 也只需在对应 AZ 下扩容。 - -如果直接采用 AZ、rack 和 host 三层 Label 结构，那么扩容 AZ 操作可能需重新添加 Label，TiKV 数据整体需要 Rebalance。 - -### 高可用和容灾分析 - -采用区域多 AZ 方案，当任意一个 AZ 故障时，集群能自动恢复服务，不需要人工介入，并能保证数据一致性。注意，各种调度策略主要用于优化性能，当发生故障时，调度机制总是优先考虑可用性而不是性能。 +--- +title: 单区域多 AZ 部署 TiDB +summary: 本文档介绍单个区域多个可用区部署 TiDB 的方案。 +aliases: ['/docs-cn/dev/how-to/deploy/geographic-redundancy/overview/','/docs-cn/dev/geo-redundancy-deployment/'] +--- + +# 单区域多 AZ 部署 TiDB + + + +作为一栈式实时 HTAP 数据库，TiDB 兼顾了传统关系型数据库的优秀特性、NoSQL 数据库可扩展性以及跨可用区 (Availability Zone, AZ) 场景下的高可用。本文档旨在介绍同区域多 AZ 部署 TiDB 的方案。 + +本文中的区域指的是地理隔离的不同位置，AZ 指的是区域内部划分的相互独立的资源集合。本文描述的方案同样适用于一个城市内多个数据中心（同城多中心）的场景。 + +## 了解 Raft 协议 + +Raft 是一种分布式一致性算法，在 TiDB 集群的多种组件中，PD 和 TiKV 都通过 Raft 实现了数据的容灾。Raft 的灾难恢复能力通过如下机制实现： + +- Raft 成员的本质是日志复制和状态机。Raft 成员之间通过复制日志来实现数据同步；Raft 成员在不同条件下切换自己的成员状态，其目标是选出 leader 以提供对外服务。 +- Raft 是一个表决系统，它遵循多数派协议，在一个 Raft Group 中，某成员获得大多数投票，它的成员状态就会转变为 leader。也就是说，当一个 Raft Group 还保有大多数节点 (majority) 时，它就能够选出 leader 以提供对外服务。 + +遵循 Raft 可靠性的特点，放到现实场景中： + +- 想克服任意 1 台服务器 (host) 的故障，应至少提供 3 台服务器。 +- 想克服任意 1 个机柜 (rack) 的故障，应至少提供 3 个机柜。 +- 想克服任意 1 个可用区（AZ，也可以是同城的多个机房）的故障，应至少提供 3 个 AZ。 + +- 想应对任意 1 个区域的灾难场景，应至少规划 3 个区域用于部署集群。 + +可见，原生 Raft 协议对于偶数副本的支持并不是很友好，考虑跨区域网络延迟影响，同区域三 AZ 可能是最适合部署 Raft 的高可用及容灾方案。 + +## 同区域三 AZ 方案 + +同区域三 AZ 方案，即同区域有三个机房部署 TiDB 集群，AZ 间的数据在集群内部（通过 Raft 协议）进行同步。同区域三 AZ 可同时对外进行读写服务，任意中心发生故障不影响数据一致性。 + +### 简易架构图 + +集群 TiDB、TiKV 和 PD 组件分别部署在 3 个不同的 AZ，这是最常规且高可用性最高的方案。 + +![三 AZ 部署](/media/deploy-3dc.png) + +**优点：** + +- 所有数据的副本分布在三个 AZ，具备高可用和容灾能力 +- 任何一个 AZ 失效后，不会产生任何数据丢失 (RPO = 0) +- 任何一个 AZ 失效后，其他两个 AZ 会自动发起 leader election，并在一定时间内（通常 20s 以内）自动恢复服务 + +![三 AZ 部署容灾](/media/deploy-3dc-dr.png) + +**缺点：** + +性能受网络延迟影响。具体影响如下： + +- 对于写入的场景，所有写入的数据需要同步复制到至少两个 AZ，由于 TiDB 写入过程使用两阶段提交，故写入延迟至少需要两倍 AZ 间的延迟。 + +- 对于读请求来说，如果数据 leader 与发起读取的 TiDB 节点不在同一个 AZ，也会受网络延迟影响。 +- TiDB 中的每个事务都需要向 PD leader 获取 TSO，当 TiDB 与 PD leader 不在同一个 AZ 时，TiDB 上运行的事务也会因此受网络延迟影响，每个有写入的事务会获取两次 TSO。 + +### 架构优化图 + +如果不需要每个 AZ 同时对外提供服务，可以将业务流量全部派发到一个 AZ，并通过调度策略把 Region leader 和 PD leader 都迁移到同一个 AZ。这样，不管是从 PD 获取 TSO，还是读取 Region，都不会受 AZ 间网络的影响。当该 AZ 失效时，PD leader 和 Region leader 会自动在其它 AZ 选出，只需要把业务流量转移至其他存活的 AZ 即可。 + +![三 AZ 部署读性能优化](/media/deploy-3dc-optimize.png) + +**优点：** + +集群 TSO 获取能力以及读取性能有所提升。具体调度策略设置模板参照如下： + +```shell +-- 其他 AZ 将 leader 驱逐至承载业务流量的 AZ + +config set label-property reject-leader LabelName labelValue + +-- 迁移 PD leader 并设置优先级 +member leader transfer pdName1 +member leader_priority pdName1 5 +member leader_priority pdName2 4 +member leader_priority pdName3 3 +``` + +> **注意：** +> +> TiDB 5.2 及以上版本默认不支持 `label-property` 配置。若要设置副本策略，请使用 [Placement Rules](/configure-placement-rules.md)。 + +**缺点：** + +- 写入场景仍受 AZ 网络延迟影响，这是因为遵循 Raft 多数派协议，所有写入的数据需要同步复制到至少两个 AZ + +- TiDB Server 是 AZ 级别单点 +- 业务流量纯走单 AZ，性能受限于单 AZ 网络带宽压力 +- TSO 获取能力以及读取性能受限于业务流量 AZ 集群 PD、TiKV 组件是否正常，否则仍受跨 AZ 网络交互影响 + +### 样例部署图 + +#### 样例拓扑架构 + +假设某区域有三个 AZ，AZ1、AZ2 和 AZ3。每个 AZ 中有两套机架，每个机架有三台服务器，不考虑混合布署以及单台机器多实例部署，同区域三 AZ 架构集群（3 副本）部署参考如下： + +![同区域三 AZ 集群部署](/media/multi-data-centers-in-one-city-deployment-sample.png) + +#### TiKV Labels 简介 + +TiKV 是一个 Multi-Raft 系统，其数据按 Region（默认 96M）切分，每个 Region 的 3 个副本构成了一个 Raft Group。假设一个 3 副本 TiDB 集群，由于 Region 的副本数与 TiKV 实例数量无关，则一个 Region 的 3 个副本只会被调度到其中 3 个 TiKV 实例上，也就是说即使集群扩容 N 个 TiKV 实例，其本质仍是一个 3 副本集群。 + +由于 3 副本的 Raft Group 只能容忍 1 副本故障，当集群被扩容到 N 个 TiKV 实例时，这个集群依然只能容忍一个 TiKV 实例的故障。2 个 TiKV 实例的故障可能会导致某些 Region 丢失多个副本，整个集群的数据也不再完整，访问到这些 Region 上的数据的 SQL 请求将会失败。而 N 个 TiKV 实例中同时有两个发生故障的概率是远远高于 3 个 TiKV 中同时有两个发生故障的概率的，也就是说 Multi-Raft 系统集群扩容 TiKV 实例越多，其可用性是逐渐降低的。 + +正因为 Multi-Raft TiKV 系统局限性，Labels 标签应运而出，其主要用于描述 TiKV 的位置信息。Label 信息随着部署或滚动更新操作刷新到 TiKV 的启动配置文件中，启动后的 TiKV 会将自己最新的 Label 信息上报给 PD，PD 根据用户登记的 Label 名称（也就是 Label 元信息），结合 TiKV 的拓扑进行 Region 副本的最优调度，从而提高系统可用性。 + +#### TiKV Labels 样例规划 + +针对 TiKV Labels 标签，你需要根据已有的物理资源、容灾能力容忍度等方面进行设计与规划，进而提升系统的可用性和容灾能力。并根据已规划的拓扑架构，在集群初始化配置文件中进行配置（此处省略其他非重点项）： + +```ini +server_configs: + pd: + replication.location-labels: ["zone","az","rack","host"] + +tikv_servers: + - host: 10.63.10.30 + config: + server.labels: { zone: "z1", az: "az1", rack: "r1", host: "30" } + - host: 10.63.10.31 + config: + server.labels: { zone: "z1", az: "az1", rack: "r1", host: "31" } + - host: 10.63.10.32 + config: + server.labels: { zone: "z1", az: "az1", rack: "r2", host: "32" } + - host: 10.63.10.33 + config: + server.labels: { zone: "z1", az: "az1", rack: "r2", host: "33" } + + - host: 10.63.10.34 + config: + server.labels: { zone: "z2", az: "az2", rack: "r1", host: "34" } + - host: 10.63.10.35 + config: + server.labels: { zone: "z2", az: "az2", rack: "r1", host: "35" } + - host: 10.63.10.36 + config: + server.labels: { zone: "z2", az: "az2", rack: "r2", host: "36" } + - host: 10.63.10.37 + config: + server.labels: { zone: "z2", az: "az2", rack: "r2", host: "37" } + + - host: 10.63.10.38 + config: + server.labels: { zone: "z3", az: "az3", rack: "r1", host: "38" } + - host: 10.63.10.39 + config: + server.labels: { zone: "z3", az: "az3", rack: "r1", host: "39" } + - host: 10.63.10.40 + config: + server.labels: { zone: "z3", az: "az3", rack: "r2", host: "40" } + - host: 10.63.10.41 + config: + server.labels: { zone: "z3", az: "az3", rack: "r2", host: "41" } +``` + +本例中，zone 表示逻辑可用区层级，用于控制副本的隔离（当前集群 3 副本）。 + +不直接采用 az、rack 和 host 三层 Label 结构，是因为考虑到将来可能会扩容 AZ，假设新扩容的 AZ 编号是 AZ2、AZ3 和 AZ4，则只需在对应可用区下扩容 AZ，rack 也只需在对应 AZ 下扩容。 + +如果直接采用 AZ、rack 和 host 三层 Label 结构，那么扩容 AZ 操作可能需重新添加 Label，TiKV 数据整体需要 Rebalance。 + +### 高可用和容灾分析 + +采用区域多 AZ 方案，当任意一个 AZ 故障时，集群能自动恢复服务，不需要人工介入，并能保证数据一致性。注意，各种调度策略主要用于优化性能，当发生故障时，调度机制总是优先考虑可用性而不是性能。 diff --git a/optimizer-hints.md b/optimizer-hints.md index 559ee3fd51bd..f1598470b39b 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -1,5 +1,6 @@ --- title: Optimizer Hints +summary: 介绍 TiDB 中 Optimizer Hints 的语法和不同生效范围的 Hint 的使用方法。 aliases: ['/docs-cn/dev/optimizer-hints/','/docs-cn/dev/reference/performance/optimizer-hints/'] --- diff --git a/partitioned-table.md b/partitioned-table.md index b38ee1763a1f..ec4e94cdd906 100644 --- a/partitioned-table.md +++ b/partitioned-table.md @@ -1,5 +1,6 @@ --- title: 分区表 +summary: 了解如何使用 TiDB 的分区表。 aliases: ['/docs-cn/dev/partitioned-table/','/docs-cn/dev/reference/sql/partitioning/'] --- diff --git a/pd-control.md b/pd-control.md index 91ab6f0dd44c..6d35f84d6f3f 100644 --- a/pd-control.md +++ b/pd-control.md @@ -1,6 +1,7 @@ --- title: PD Control 使用说明 aliases: ['/docs-cn/dev/pd-control/','/docs-cn/dev/reference/tools/pd-control/'] +summary: PD Control 是 PD 的命令行工具，用于获取集群状态信息和调整集群。 --- # PD Control 使用说明 diff --git a/post-installation-check.md b/post-installation-check.md index 4271344c06d2..275a3da7b59f 100644 --- a/post-installation-check.md +++ b/post-installation-check.md @@ -1,214 +1,214 @@ ---- -title: 验证集群运行状态 -summary: 介绍如何验证集群运行状态。 -aliases: ['/docs-cn/dev/post-installation-check/'] ---- - -# 验证集群运行状态 - -在部署完一套 TiDB 集群后，需要检查集群是否正常运行。本文介绍如何通过 TiUP 命令、[TiDB Dashboard](/dashboard/dashboard-intro.md) 和 Grafana 检查集群状态，以及如何登录 TiDB 数据库执行简单的 SQL 操作。 - -## 通过 TiUP 检查集群状态 - -检查集群状态的命令是 `tiup cluster display `，例如： - -{{< copyable "shell-regular" >}} - -```shell -tiup cluster display tidb-test -``` - -预期结果输出：各节点 Status 状态信息为 `Up` 说明集群状态正常。 - -## 通过 TiDB Dashboard 和 Grafana 检查集群状态 - -本节介绍如何通过 [TiDB Dashboard](/dashboard/dashboard-intro.md) 和 Grafana 检查集群状态。 - -### 查看 TiDB Dashboard 检查 TiDB 集群状态 - -1. 通过 `{pd-ip}:{pd-port}/dashboard` 登录 TiDB Dashboard，登录用户和口令为 TiDB 数据库 `root` 用户和口令。如果你修改过数据库的 `root` 密码，则以修改后的密码为准，默认密码为空。 - - ![TiDB-Dashboard](/media/tiup/tidb-dashboard.png) - -2. 主页面显示 TiDB 集群中节点信息 - - ![TiDB-Dashboard-status](/media/tiup/tidb-dashboard-status.png) - -### 查看 Grafana 监控 Overview 页面检查 TiDB 集群状态 - -- 通过 `{Grafana-ip}:3000` 登录 Grafana 监控，默认用户名及密码为 `admin`/`admin`。 - -- 点击 **Overview** 监控页面检查 TiDB 端口和负载监控信息。 - - ![Grafana-overview](/media/tiup/grafana-overview.png) - -## 登录数据库执行简单 DML/DDL 操作和查询 SQL 语句 - -> **注意：** -> -> 登录数据库前，你需要安装 MySQL 客户端。 - -执行以下命令登录数据库： - -{{< copyable "shell-regular" >}} - -```shell -mysql -u root -h ${tidb_server_host_IP_address} -P 4000 -``` - -其中，`${tidb_server_host_IP_address}` 是在[初始化集群拓扑文件](/production-deployment-using-tiup.md#第-3-步初始化集群拓扑文件)时为 `tidb_servers` 配置的 IP 地址之一，例如 `10.0.1.7`。 - -输出下列信息表示登录成功： - -```sql -Welcome to the MySQL monitor. Commands end with ; or \g. -Your MySQL connection id is 3 -Server version: 8.0.11-TiDB-v8.0.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 8.0 compatible - -Copyright (c) 2000, 2023, Oracle and/or its affiliates. All rights reserved. - - -Oracle is a registered trademark of Oracle Corporation and/or its -affiliates. Other names may be trademarks of their respective -owners. - -Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. -``` - -### 数据库操作 - -+ 检查 TiDB 版本 - - {{< copyable "sql" >}} - - ```sql - select tidb_version()\G - ``` - - 预期结果输出： - - ```sql - *************************** 1. row *************************** - tidb_version(): Release Version: v5.0.0 - Edition: Community - Git Commit Hash: 689a6b6439ae7835947fcaccf329a3fc303986cb - Git Branch: HEAD - UTC Build Time: 2020-05-28 11:09:45 - GoVersion: go1.13.4 - Race Enabled: false - TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306 - Check Table Before Drop: false - 1 row in set (0.00 sec) - ``` - -+ 创建 PingCAP database - - {{< copyable "sql" >}} - - ```sql - create database pingcap; - ``` - - ```sql - Query OK, 0 rows affected (0.10 sec) - ``` - - {{< copyable "sql" >}} - - ```sql - use pingcap; - ``` - - 预期输出 - - ```sql - Database changed - ``` - -+ 创建 `tab_tidb` 表 - - {{< copyable "sql" >}} - - ```sql - CREATE TABLE `tab_tidb` ( - `id` int(11) NOT NULL AUTO_INCREMENT, - `name` varchar(20) NOT NULL DEFAULT '', - `age` int(11) NOT NULL DEFAULT 0, - `version` varchar(20) NOT NULL DEFAULT '', - PRIMARY KEY (`id`), - KEY `idx_age` (`age`)); - ``` - - 预期输出 - - ```sql - Query OK, 0 rows affected (0.11 sec) - ``` - -+ 插入数据 - - {{< copyable "sql" >}} - - ```sql - insert into `tab_tidb` values (1,'TiDB',5,'TiDB-v5.0.0'); - ``` - - 预期输出 - - ```sql - Query OK, 1 row affected (0.03 sec) - ``` - -+ 查看 `tab_tidb` 结果 - - {{< copyable "sql" >}} - - ```sql - select * from tab_tidb; - ``` - - 预期输出 - - ```sql - +----+------+-----+-------------+ - | id | name | age | version | - +----+------+-----+-------------+ - | 1 | TiDB | 5 | TiDB-v5.0.0 | - +----+------+-----+-------------+ - 1 row in set (0.00 sec) - ``` - -+ 查看 TiKV store 状态、`store_id`、存储情况以及启动时间 - - {{< copyable "sql" >}} - - ```sql - select STORE_ID,ADDRESS,STORE_STATE,STORE_STATE_NAME,CAPACITY,AVAILABLE,UPTIME from INFORMATION_SCHEMA.TIKV_STORE_STATUS; - ``` - - 预期输出 - - ```sql - +----------+--------------------+-------------+------------------+----------+-----------+--------------------+ - | STORE_ID | ADDRESS | STORE_STATE | STORE_STATE_NAME | CAPACITY | AVAILABLE | UPTIME | - +----------+--------------------+-------------+------------------+----------+-----------+--------------------+ - | 1 | 10.0.1.1:20160 | 0 | Up | 49.98GiB | 46.3GiB | 5h21m52.474864026s | - | 4 | 10.0.1.2:20160 | 0 | Up | 49.98GiB | 46.32GiB | 5h21m52.522669177s | - | 5 | 10.0.1.3:20160 | 0 | Up | 49.98GiB | 45.44GiB | 5h21m52.713660541s | - +----------+--------------------+-------------+------------------+----------+-----------+--------------------+ - 3 rows in set (0.00 sec) - ``` - -+ 退出 - - {{< copyable "sql" >}} - - ```sql - exit - ``` - - 预期输出 - - ```sql - Bye - ``` +--- +title: 验证集群运行状态 +summary: 介绍如何验证集群运行状态。 +aliases: ['/docs-cn/dev/post-installation-check/'] +--- + +# 验证集群运行状态 + +在部署完一套 TiDB 集群后，需要检查集群是否正常运行。本文介绍如何通过 TiUP 命令、[TiDB Dashboard](/dashboard/dashboard-intro.md) 和 Grafana 检查集群状态，以及如何登录 TiDB 数据库执行简单的 SQL 操作。 + +## 通过 TiUP 检查集群状态 + +检查集群状态的命令是 `tiup cluster display `，例如： + +{{< copyable "shell-regular" >}} + +```shell +tiup cluster display tidb-test +``` + +预期结果输出：各节点 Status 状态信息为 `Up` 说明集群状态正常。 + +## 通过 TiDB Dashboard 和 Grafana 检查集群状态 + +本节介绍如何通过 [TiDB Dashboard](/dashboard/dashboard-intro.md) 和 Grafana 检查集群状态。 + +### 查看 TiDB Dashboard 检查 TiDB 集群状态 + +1. 通过 `{pd-ip}:{pd-port}/dashboard` 登录 TiDB Dashboard，登录用户和口令为 TiDB 数据库 `root` 用户和口令。如果你修改过数据库的 `root` 密码，则以修改后的密码为准，默认密码为空。 + + ![TiDB-Dashboard](/media/tiup/tidb-dashboard.png) + +2. 主页面显示 TiDB 集群中节点信息 + + ![TiDB-Dashboard-status](/media/tiup/tidb-dashboard-status.png) + +### 查看 Grafana 监控 Overview 页面检查 TiDB 集群状态 + +- 通过 `{Grafana-ip}:3000` 登录 Grafana 监控，默认用户名及密码为 `admin`/`admin`。 + +- 点击 **Overview** 监控页面检查 TiDB 端口和负载监控信息。 + + ![Grafana-overview](/media/tiup/grafana-overview.png) + +## 登录数据库执行简单 DML/DDL 操作和查询 SQL 语句 + +> **注意：** +> +> 登录数据库前，你需要安装 MySQL 客户端。 + +执行以下命令登录数据库： + +{{< copyable "shell-regular" >}} + +```shell +mysql -u root -h ${tidb_server_host_IP_address} -P 4000 +``` + +其中，`${tidb_server_host_IP_address}` 是在[初始化集群拓扑文件](/production-deployment-using-tiup.md#第-3-步初始化集群拓扑文件)时为 `tidb_servers` 配置的 IP 地址之一，例如 `10.0.1.7`。 + +输出下列信息表示登录成功： + +```sql +Welcome to the MySQL monitor. Commands end with ; or \g. +Your MySQL connection id is 3 +Server version: 8.0.11-TiDB-v8.0.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 8.0 compatible + +Copyright (c) 2000, 2023, Oracle and/or its affiliates. All rights reserved. + + +Oracle is a registered trademark of Oracle Corporation and/or its +affiliates. Other names may be trademarks of their respective +owners. + +Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. +``` + +### 数据库操作 + ++ 检查 TiDB 版本 + + {{< copyable "sql" >}} + + ```sql + select tidb_version()\G + ``` + + 预期结果输出： + + ```sql + *************************** 1. row *************************** + tidb_version(): Release Version: v5.0.0 + Edition: Community + Git Commit Hash: 689a6b6439ae7835947fcaccf329a3fc303986cb + Git Branch: HEAD + UTC Build Time: 2020-05-28 11:09:45 + GoVersion: go1.13.4 + Race Enabled: false + TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306 + Check Table Before Drop: false + 1 row in set (0.00 sec) + ``` + ++ 创建 PingCAP database + + {{< copyable "sql" >}} + + ```sql + create database pingcap; + ``` + + ```sql + Query OK, 0 rows affected (0.10 sec) + ``` + + {{< copyable "sql" >}} + + ```sql + use pingcap; + ``` + + 预期输出 + + ```sql + Database changed + ``` + ++ 创建 `tab_tidb` 表 + + {{< copyable "sql" >}} + + ```sql + CREATE TABLE `tab_tidb` ( + `id` int(11) NOT NULL AUTO_INCREMENT, + `name` varchar(20) NOT NULL DEFAULT '', + `age` int(11) NOT NULL DEFAULT 0, + `version` varchar(20) NOT NULL DEFAULT '', + PRIMARY KEY (`id`), + KEY `idx_age` (`age`)); + ``` + + 预期输出 + + ```sql + Query OK, 0 rows affected (0.11 sec) + ``` + ++ 插入数据 + + {{< copyable "sql" >}} + + ```sql + insert into `tab_tidb` values (1,'TiDB',5,'TiDB-v5.0.0'); + ``` + + 预期输出 + + ```sql + Query OK, 1 row affected (0.03 sec) + ``` + ++ 查看 `tab_tidb` 结果 + + {{< copyable "sql" >}} + + ```sql + select * from tab_tidb; + ``` + + 预期输出 + + ```sql + +----+------+-----+-------------+ + | id | name | age | version | + +----+------+-----+-------------+ + | 1 | TiDB | 5 | TiDB-v5.0.0 | + +----+------+-----+-------------+ + 1 row in set (0.00 sec) + ``` + ++ 查看 TiKV store 状态、`store_id`、存储情况以及启动时间 + + {{< copyable "sql" >}} + + ```sql + select STORE_ID,ADDRESS,STORE_STATE,STORE_STATE_NAME,CAPACITY,AVAILABLE,UPTIME from INFORMATION_SCHEMA.TIKV_STORE_STATUS; + ``` + + 预期输出 + + ```sql + +----------+--------------------+-------------+------------------+----------+-----------+--------------------+ + | STORE_ID | ADDRESS | STORE_STATE | STORE_STATE_NAME | CAPACITY | AVAILABLE | UPTIME | + +----------+--------------------+-------------+------------------+----------+-----------+--------------------+ + | 1 | 10.0.1.1:20160 | 0 | Up | 49.98GiB | 46.3GiB | 5h21m52.474864026s | + | 4 | 10.0.1.2:20160 | 0 | Up | 49.98GiB | 46.32GiB | 5h21m52.522669177s | + | 5 | 10.0.1.3:20160 | 0 | Up | 49.98GiB | 45.44GiB | 5h21m52.713660541s | + +----------+--------------------+-------------+------------------+----------+-----------+--------------------+ + 3 rows in set (0.00 sec) + ``` + ++ 退出 + + {{< copyable "sql" >}} + + ```sql + exit + ``` + + 预期输出 + + ```sql + Bye + ``` diff --git a/releases/release-1.0-ga.md b/releases/release-1.0-ga.md index 8e4b02836f53..4f3f7dd545bf 100644 --- a/releases/release-1.0-ga.md +++ b/releases/release-1.0-ga.md @@ -1,6 +1,7 @@ --- title: TiDB 1.0 release notes aliases: ['/docs-cn/dev/releases/release-1.0-ga/','/docs-cn/dev/releases/ga/'] +summary: TiDB 1.0 版本发布，对 MySQL 兼容性、SQL 优化器、系统稳定性、性能做了大量工作。TiDB 优化了 SQL 查询优化器、内部数据格式、MySQL 兼容性，并支持 `NO_SQL_CACHE` 语法。PD 支持基于读流量的热点调度和设置 Store 权重。TiKV 支持更多下推函数和手动触发数据 Compact。TiSpark Beta 版本支持可配置框架和 ThriftSever/JDBC 和 Spark SQL 脚本入口。感谢参与项目的企业和团队，以及提供出色开源软件/服务的组织/个人。 --- # TiDB 1.0 Release Notes diff --git a/releases/release-1.1-alpha.md b/releases/release-1.1-alpha.md index 321283c409e5..d772e89fda77 100644 --- a/releases/release-1.1-alpha.md +++ b/releases/release-1.1-alpha.md @@ -1,6 +1,7 @@ --- title: TiDB 1.1 Alpha Release Notes aliases: ['/docs-cn/dev/releases/release-1.1-alpha/','/docs-cn/dev/releases/11alpha/'] +summary: TiDB 1.1 Alpha 版本发布，对 MySQL 兼容性、SQL 优化器、系统稳定性、性能做了大量工作。包括 SQL parser 兼容更多语法，SQL 查询优化器优化统计信息、代价估算，使用 `Count-Min Sketch` 更精确地估算点查的代价，SQL 执行器重构执行器算子，优化 `INSERT IGNORE` 语句性能，下推更多类型和函数，支持更多 `SQL_MODE`，优化 `Load Data` 性能，支持对物理算子内存使用进行统计。PD 增加更多 API，支持 TLS，调度适应不同的 Region size，修复调度 bug。TiKV 支持 Raft learner，优化 Raft Snapshot，支持 TLS，优化 RocksDB 配置，优化 Coprocessor 性能，增加 Failpoint 和稳定性测试 case，解决 PD 和 TiKV 重连问题，增强数据恢复工具功能，Region 支持按 table 分裂，支持 `Delete Range` 功能，支持设置 snapshot 导致的 I/O 上限，完善流控机制。 --- # TiDB 1.1 Alpha Release Notes diff --git a/releases/release-1.1-beta.md b/releases/release-1.1-beta.md index 7692c82a16b6..36ddb5170a1b 100644 --- a/releases/release-1.1-beta.md +++ b/releases/release-1.1-beta.md @@ -1,6 +1,7 @@ --- title: TiDB 1.1 Beta Release Notes aliases: ['/docs-cn/dev/releases/release-1.1-beta/','/docs-cn/dev/releases/11beta/'] +summary: TiDB 1.1 Beta 版本在 MySQL 兼容性和系统稳定性方面有多项改进。TiDB 新增监控项和优化日志，兼容更多 MySQL 语法，支持显示建表时间，加快查询速度，控制 Join 产生的中间结果集大小，修复多项问题，优化 SQL 引擎查询性能。PD 新增调试接口和 metrics，提高 TiKV 宕机时数据恢复优先级和恢复速度，优化 Region heartbeat 性能，修复热点调度问题。TiKV 消除潜在的 GC 问题，支持批量 resolve lock 和并行 GC，使用 RocksDB compaction listener 更新 Region Size，设置 Raft snapshot max size，支持更多修复操作，优化有序流式聚合操作，完善 metrics，修复 bug。 --- # TiDB 1.1 Beta Release Notes diff --git a/releases/release-2.0-ga.md b/releases/release-2.0-ga.md index 6a25bf44f1e9..2a92756161f5 100644 --- a/releases/release-2.0-ga.md +++ b/releases/release-2.0-ga.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0 release notes aliases: ['/docs-cn/dev/releases/release-2.0-ga/','/docs-cn/dev/releases/2.0ga/'] +summary: TiDB 2.0 GA 版本发布，对 MySQL 兼容性、系统稳定性、优化器和执行器做了很多改进。包括 SQL 优化器、SQL 执行引擎、Server、兼容性、DDL、PD、TiKV 和 TiSpark 的功能、性能和稳定性优化。 --- # TiDB 2.0 Release Notes diff --git a/releases/release-2.0-rc.1.md b/releases/release-2.0-rc.1.md index 8f497c28d877..1311ddb1a367 100644 --- a/releases/release-2.0-rc.1.md +++ b/releases/release-2.0-rc.1.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0 RC1 Release Notes aliases: ['/docs-cn/dev/releases/release-2.0-rc.1/','/docs-cn/dev/releases/2rc1/'] +summary: TiDB 2.0 RC1 版本发布，改进了 MySQL 兼容性、系统稳定性和优化器。TiDB 支持限制单条 SQL 语句内存使用，下推流式聚合算子到 TiKV，配置文件合法性检测，HTTP API 获取参数信息。Parser 兼容更多 MySQL 语法，提升对 Navicat 的兼容性。优化器提升，提取多个 OR 条件的公共表达式，选取更优执行计划。PD 优化检查 Region 状态的代码逻辑，异常情况下日志信息输出，修复监控中 TiKV 节点磁盘空间不足统计。TiKV 修复 PD leader 切换 gRPC call 问题，增加获取 metrics 的 gRPC API，启动时检查是否使用 SSD，使用 ReadPool 优化读性能。 --- # TiDB 2.0 RC1 Release Notes diff --git a/releases/release-2.0-rc.3.md b/releases/release-2.0-rc.3.md index 6dc46c8024a6..50d94f384f46 100644 --- a/releases/release-2.0-rc.3.md +++ b/releases/release-2.0-rc.3.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0 RC3 Release Notes aliases: ['/docs-cn/dev/releases/release-2.0-rc.3/','/docs-cn/dev/releases/2rc3/'] +summary: TiDB 2.0 RC3 版本发布，改进了 MySQL 兼容性、系统稳定性和优化器。TiDB 修复了 MAX/MIN 结果错误、Sort Merge Join 排序问题、uint 和 int 比较错误等。PD 支持 Region Merge 和忽略有大量 pending peer 的节点。TiKV 支持 Region Merge、Raft snapshot 通知 PD 加速调度、增加 Raw DeleteRange API 等。 --- # TiDB 2.0 RC3 Release Notes diff --git a/releases/release-2.0-rc.4.md b/releases/release-2.0-rc.4.md index e366a2ec0b66..0b0920795148 100644 --- a/releases/release-2.0-rc.4.md +++ b/releases/release-2.0-rc.4.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0 RC4 Release Notes aliases: ['/docs-cn/dev/releases/release-2.0-rc.4/','/docs-cn/dev/releases/2rc4/'] +summary: TiDB 2.0 RC4 版本发布，改进了 MySQL 兼容性、系统稳定性和优化器。TiDB 支持了一些新的语法和修复了一些问题。PD 支持手动 split Region 和优化了 metrics 及代码结构。TiKV 限制了接收 snapshot 时的内存使用，支持导数据模式和改善了在被隔离的情况下的输出问题。 --- # TiDB 2.0 RC4 Release Notes diff --git a/releases/release-2.0-rc.5.md b/releases/release-2.0-rc.5.md index 2ad39757e1d9..0116b6e4c5e2 100644 --- a/releases/release-2.0-rc.5.md +++ b/releases/release-2.0-rc.5.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0 RC5 Release Notes aliases: ['/docs-cn/dev/releases/release-2.0-rc.5/','/docs-cn/dev/releases/2rc5/'] +summary: TiDB 2.0 RC5 版本发布，对 MySQL 兼容性、系统稳定性和优化器做了很多改进。TiDB 修复了多个问题，并优化了性能。PD 添加了 Raft Learner 支持，优化了 Balance Region Scheduler，并修复了多个问题。TiKV 支持了更多功能，并解决了多个问题。 --- # TiDB 2.0 RC5 Release Notes diff --git a/releases/release-2.0.1.md b/releases/release-2.0.1.md index e0fd7934f0eb..311fae43d28c 100644 --- a/releases/release-2.0.1.md +++ b/releases/release-2.0.1.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0.1 release notes aliases: ['/docs-cn/dev/releases/release-2.0.1/','/docs-cn/dev/releases/201/'] +summary: TiDB 2.0.1 版本对 MySQL 兼容性和系统稳定性做出了改进。TiDB 新增了实时更新 `Add Index` 进度到 DDL 任务信息中的功能，添加了 Session 变量 `tidb_auto_analyze_ratio` 控制统计信息自动更新阈值的功能。修复了事务提交失败时可能未清理所有残留状态的问题，以及其他 Bug 和兼容性问题。PD 新增了 `Scatter Range` 调度和 learner 相关的 metrics，修复了多个问题。TiKV 修复了多个问题，优化了慢查询的日志，减少了 `thread_yield` 的调用次数。 --- # TiDB 2.0.1 Release Notes diff --git a/releases/release-2.0.10.md b/releases/release-2.0.10.md index 824311caf3d2..9324720667aa 100644 --- a/releases/release-2.0.10.md +++ b/releases/release-2.0.10.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0.10 Release Notes aliases: ['/docs-cn/dev/releases/release-2.0.10/','/docs-cn/dev/releases/2.0.10/'] +summary: TiDB 2.0.10 版本发布，修复了系统兼容性和稳定性问题。包括取消 DDL 任务可能导致的问题，ORDER BY 和 UNION 语句无法引用带表名的列的问题，UNCOMPRESS 函数错误输入长度的问题等。PD 修复了 RaftCluster 退出时可能的死锁问题，TiKV 修复了迁移 Leader 到新节点时造成请求延时问题和多余的 Region 心跳问题。 --- # TiDB 2.0.10 Release Notes diff --git a/releases/release-2.0.11.md b/releases/release-2.0.11.md index 471a9b7ca46d..838d48b050f9 100644 --- a/releases/release-2.0.11.md +++ b/releases/release-2.0.11.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0.11 Release Notes aliases: ['/docs-cn/dev/releases/release-2.0.11/','/docs-cn/dev/releases/2.0.11/'] +summary: TiDB 2.0.11 版本发布，对系统兼容性和稳定性做出改进。修复了多个问题，包括 PD 异常处理问题、Rename 行为问题、ADMIN CHECK TABLE 误报问题、前缀索引错误问题和添加列导致 UPDATE 语句 panic 问题。TiKV 修复了两个 Region merge 相关问题。 --- # TiDB 2.0.11 Release Notes diff --git a/releases/release-2.0.2.md b/releases/release-2.0.2.md index 1bfbd00984ae..d22d67f1613b 100644 --- a/releases/release-2.0.2.md +++ b/releases/release-2.0.2.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0.2 release notes aliases: ['/docs-cn/dev/releases/release-2.0.2/','/docs-cn/dev/releases/202/'] +summary: TiDB 2.0.2 版本发布，改进了系统稳定性。TiDB 修复了 Decimal 除法内置函数下推的问题，支持 `Delete` 语句中使用 `USE INDEX` 的语法，禁止在带有 `Auto-Increment` 的列中使用 `shard_row_id_bits` 特性，并增加了写入 Binlog 的超时机制。PD 使 balance leader scheduler 过滤失连节点，更改 transfer leader operator 的超时时间为 10 秒，修复 label scheduler 在集群 Regions 不健康状态下不调度的问题，修复 evict leader scheduler 调度不当的问题。TiKV 修复了 Raft 日志没有打出来的问题，支持配置更多 gRPC 相关参数，支持配置选举超时的取值范围，修复过期 learner 没有删掉的问题，修复 snapshot 中间文件被误删的问题。 --- # TiDB 2.0.2 Release Notes diff --git a/releases/release-2.0.3.md b/releases/release-2.0.3.md index a6e6127d7214..7e58d08f8686 100644 --- a/releases/release-2.0.3.md +++ b/releases/release-2.0.3.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0.3 release notes aliases: ['/docs-cn/dev/releases/release-2.0.3/','/docs-cn/dev/releases/203/'] +summary: TiDB 2.0.3 版本在 2.0.2 版的基础上做出了改进，包括系统兼容性和稳定性的改进。TiDB 支持在线更改日志级别和 `COM_CHANGE_USER` 命令，优化查询条件代价估算和修复多个问题。PD 修复了特定条件下的问题，TiKV 修复了错误上报和除数为 0 的问题。 --- # TiDB 2.0.3 Release Notes diff --git a/releases/release-2.0.4.md b/releases/release-2.0.4.md index b192b4bec474..c3e8335e9225 100644 --- a/releases/release-2.0.4.md +++ b/releases/release-2.0.4.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0.4 release notes aliases: ['/docs-cn/dev/releases/release-2.0.4/','/docs-cn/dev/releases/204/'] +summary: TiDB 2.0.4 版本发布，改进了系统兼容性和稳定性。TiDB 支持了新的语法和变量设置，优化了监控项和查询代价估计精度。PD 改进了调度参数行为，TiKV 新增了调试接口和命令，优化了问题和修复了崩溃。 --- # TiDB 2.0.4 Release Notes diff --git a/releases/release-2.0.5.md b/releases/release-2.0.5.md index 6d2d20e97968..5eee7f659d81 100644 --- a/releases/release-2.0.5.md +++ b/releases/release-2.0.5.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0.5 release notes aliases: ['/docs-cn/dev/releases/release-2.0.5/','/docs-cn/dev/releases/205/'] +summary: TiDB 2.0.5 版本发布，改进了系统兼容性和稳定性。新增系统变量 `tidb_disable_txn_auto_retry`，调整计算 `Selection` 代价的方式，优化查询条件匹配唯一索引或主键，修复多个 bug。PD 修复副本迁移导致 TiKV 磁盘空间耗尽和 `AdjacentRegionScheduler` 导致的崩溃问题。TiKV 修复 decimal 运算中的溢出和 merge 过程中的脏读问题。 --- # TiDB 2.0.5 Release Notes diff --git a/releases/release-2.0.6.md b/releases/release-2.0.6.md index 042cf60239c1..587f99b014ce 100644 --- a/releases/release-2.0.6.md +++ b/releases/release-2.0.6.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0.6 release notes aliases: ['/docs-cn/dev/releases/release-2.0.6/','/docs-cn/dev/releases/206/'] +summary: TiDB 2.0.6 版本在系统兼容性和稳定性方面有所改进。包括日志长度精简、记录 ADD INDEX 执行过程中的慢操作、减少更新统计信息操作中的事务冲突等。此外，修复了多个 bug，包括 DROP USER 语句和 MySQL 行为不兼容、tidb_batch_insert 打开后 INSERT/LOAD DATA 语句在某些场景下 OOM 的问题等。TiKV 方面扩大了默认 scheduler slots 值以减少假冲突现象，修复了字符串转 Decimal 时出现的 crash。 --- # TiDB 2.0.6 Release Notes diff --git a/releases/release-2.0.7.md b/releases/release-2.0.7.md index 9958692e499d..aa7dab7e91df 100644 --- a/releases/release-2.0.7.md +++ b/releases/release-2.0.7.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0.7 release notes aliases: ['/docs-cn/dev/releases/release-2.0.7/','/docs-cn/dev/releases/207/'] +summary: TiDB 2.0.7 版本在系统兼容性和稳定性方面有改进。TiDB 新增了在 `information_schema` 中添加 `PROCESSLIST` 表的功能。还对语句执行细节进行了改进，并在 `SLOW QUERY` 日志中输出更多信息。修复了多个 bug，包括 `PRIMARY KEY` 为整数的表无法使用 `USE INDEX(PRIMARY)` 的问题，以及 `Merge Join` 和 `Index Join` 在 inner row 为 `NULL` 时输出多余结果的问题。TiKV 方面，空集群默认打开 `dynamic-level-bytes` 参数减少空间放大，并在 Region merge 之后更新 Region 的 `approximate size` 和 keys。 --- # TiDB 2.0.7 Release Notes diff --git a/releases/release-2.0.8.md b/releases/release-2.0.8.md index 28090a3d7be4..b7c094459ef4 100644 --- a/releases/release-2.0.8.md +++ b/releases/release-2.0.8.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0.8 release notes aliases: ['/docs-cn/dev/releases/release-2.0.8/','/docs-cn/dev/releases/208/'] +summary: TiDB 2.0.8 版本在 2.0.7 版的基础上做出了改进，包括功能改进和 Bug 修复。TiKV 也修复了节点宕机时内存持续上升的问题。 --- # TiDB 2.0.8 Release Notes diff --git a/releases/release-2.0.9.md b/releases/release-2.0.9.md index a1e007fcd6ec..913123f2ec50 100644 --- a/releases/release-2.0.9.md +++ b/releases/release-2.0.9.md @@ -1,6 +1,7 @@ --- title: TiDB 2.0.9 Release Notes aliases: ['/docs-cn/dev/releases/release-2.0.9/','/docs-cn/dev/releases/209/'] +summary: TiDB 2.0.9 版本发布，改进了系统兼容性和稳定性。修复了多个问题，包括统计信息、DDL JOB、Commit 操作、Limit 值、字符集支持、内建函数、主键选择率估算、Session 变量、Union 语句、统计信息清除、事务运行时间、表创建语句、取消 DDL 任务、全局环境变量等。PD 修复了 etcd 启动失败和 pd-ctl 读取 Region key 的问题。TiKV 增加了 kv_scan 接口扫描上界的限制，废弃了 max-tasks-xxx 配置，并修复了 RocksDB CompactFiles 的问题。 --- # TiDB 2.0.9 Release Notes diff --git a/releases/release-2.1-beta.md b/releases/release-2.1-beta.md index 9e1c54d076f2..b335d15ce2f3 100644 --- a/releases/release-2.1-beta.md +++ b/releases/release-2.1-beta.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1 Beta Release Notes aliases: ['/docs-cn/dev/releases/release-2.1-beta/','/docs-cn/dev/releases/21beta/'] +summary: TiDB 2.1 Beta 版本对系统稳定性、优化器、统计信息以及执行引擎做了很多改进。SQL 优化器优化了 Index Join 选择范围和关联子查询，下推 Filter 和扩大索引选择范围。SQL 执行引擎实现了并行 Hash Aggregate 和 Project 算子，提高了执行性能。Server 添加了 HTTP API 控制功能和支持 Server side cursor。兼容性方面支持更多 MySQL 语法和 SHOW PRIVILEGES 语句。PD 优化了 Balance Scheduler 和热点调度器，TiKV 升级了 Rust 版本和优化了性能。 --- # TiDB 2.1 Beta Release Notes diff --git a/releases/release-2.1-ga.md b/releases/release-2.1-ga.md index 3ae920a142fe..adb711ef4835 100644 --- a/releases/release-2.1-ga.md +++ b/releases/release-2.1-ga.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1 GA Release Notes aliases: ['/docs-cn/dev/releases/release-2.1-ga/','/docs-cn/dev/releases/2.1ga/'] +summary: TiDB 2.1 GA 版本发布，对系统稳定性、性能、兼容性、易用性做了大量改进。包括 SQL 优化器、SQL 执行引擎、统计信息、表达式、Server、DDL、兼容性等方面的优化。PD (Placement Driver) 进行了可用性优化、调度器优化、API 及运维工具优化、监控和性能优化。TiKV 进行了 Coprocessor、Transaction、Raftstore、存储引擎和 tikv-ctl 方面的优化。同时支持全量数据快速导入工具 TiDB Lightning 和新版本 TiDB Binlog。升级兼容性说明包括存储引擎更新不支持回退至 2.0.x 或更旧版本，以及升级前需要确认集群中是否存在正在运行中的 DDL 操作。 --- # TiDB 2.1 GA Release Notes diff --git a/releases/release-2.1-rc.1.md b/releases/release-2.1-rc.1.md index 52fd5a6e8d28..9c2a422e9155 100644 --- a/releases/release-2.1-rc.1.md +++ b/releases/release-2.1-rc.1.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1 RC1 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1-rc.1/','/docs-cn/dev/releases/21rc1/'] +summary: TiDB 2.1 RC1 版本于 2018 年 8 月 24 日发布。该版本对系统稳定性、优化器、统计信息以及执行引擎做了很多改进。包括 SQL 优化器、SQL 执行引擎、统计信息、Server、兼容性、DML、DDL 等方面的改进。PD 方面新增了版本控制机制，支持集群滚动兼容升级等功能。TiKV 方面新增了支持 batch split 等新特性，以及对性能和功能进行了优化和改进。 --- # TiDB 2.1 RC1 Release Notes diff --git a/releases/release-2.1-rc.2.md b/releases/release-2.1-rc.2.md index bc0844937903..d24bcea25259 100644 --- a/releases/release-2.1-rc.2.md +++ b/releases/release-2.1-rc.2.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1 RC2 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1-rc.2/','/docs-cn/dev/releases/21rc2/'] +summary: TiDB 2.1 RC2 版本对系统稳定性、优化器、统计信息和执行引擎做了很多改进。具体包括 SQL 优化器、SQL 执行引擎、统计信息、Server、兼容性、表达式、DML、DDL、TiKV 和 PD 的新特性、功能改进和 Bug 修复。 --- # TiDB 2.1 RC2 Release Notes diff --git a/releases/release-2.1-rc.3.md b/releases/release-2.1-rc.3.md index 8753c77e19b7..b90b8d035d1a 100644 --- a/releases/release-2.1-rc.3.md +++ b/releases/release-2.1-rc.3.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1 RC3 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1-rc.3/','/docs-cn/dev/releases/21rc3/'] +summary: TiDB 2.1 RC3 版本对系统稳定性、兼容性、优化器和执行引擎做了很多改进。包括修复了多个 SQL 优化器和执行引擎的问题，增强了部分执行器的性能，修复了配置文件内存配额选项不生效的问题，支持使用 `admin show slow` 语句来获取 SLOW QUERY LOG，修复了一些兼容性问题，增加了一些内建函数的支持，修复了一些 DML 和 DDL 的问题。PD 新增了获取按大小逆序排序的 Region 列表 API，Region API 返回更详细的信息，修复了 PD 切换 leader 后可能导致 crash 的问题。TiKV 进行了性能优化，并新增了一些函数的支持，同时修复了一些 Bug。 --- # TiDB 2.1 RC3 Release Notes diff --git a/releases/release-2.1-rc.4.md b/releases/release-2.1-rc.4.md index fa41a034e25f..ac3b563326b9 100644 --- a/releases/release-2.1-rc.4.md +++ b/releases/release-2.1-rc.4.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1 RC4 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1-rc.4/','/docs-cn/dev/releases/21rc4/'] +summary: TiDB 2.1 RC4 版本对系统稳定性、优化器、统计信息和执行引擎做了很多改进。修复了多个 SQL 优化器和执行引擎的问题，重构了 Latch，提升了并发事务的执行性能。PD 修复了多个 TiKV 下线后的问题。TiKV 优化了 apply snapshot 导致的 RocksDB Write stall 的问题，并增加了 raftstore tick 相关 metrics。 --- # TiDB 2.1 RC4 Release Notes diff --git a/releases/release-2.1-rc.5.md b/releases/release-2.1-rc.5.md index 63068a6fe556..f37867aefb13 100644 --- a/releases/release-2.1-rc.5.md +++ b/releases/release-2.1-rc.5.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1 RC5 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1-rc.5/','/docs-cn/dev/releases/21rc5/'] +summary: TiDB 2.1 RC5 版本发布，对系统稳定性、优化器、统计信息和执行引擎做了很多改进。包括修复了多个问题，提升了性能，增加了环境变量设置功能。PD 修复了多个问题，TiKV 优化了报错信息和接口限制。TiDB 支持 TiDB Binlog cluster，不兼容旧版本。 --- diff --git a/releases/release-2.1.1.md b/releases/release-2.1.1.md index 2e7257e927e1..088a093e06b3 100644 --- a/releases/release-2.1.1.md +++ b/releases/release-2.1.1.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.1 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.1/','/docs-cn/dev/releases/2.1.1/'] +summary: TiDB 2.1.1 版本发布，对系统稳定性、优化器、统计信息和执行引擎做了改进。修复了多个问题，包括时间四舍五入错误、uncompress 函数未检查数据长度、PD 故障获取错误 TSO、不规范语句导致启动失败等。DDL 改变了表的默认字符集和排序规则，增加了控制添加索引速度的变量。PD 修复了配置项无法设置为 0 的问题，避免了 transfer leader 至新创建的 Peer 产生的延迟增加问题。TiKV 也避免了相同的问题。 Lightning 优化了对导入表的 analyze 机制，提升了导入速度。 TiDB Binlog 修复了 pb files 输出 bug。 --- # TiDB 2.1.1 Release Notes diff --git a/releases/release-2.1.10.md b/releases/release-2.1.10.md index 7344d3e6e2a5..f1f4d1a77e2d 100644 --- a/releases/release-2.1.10.md +++ b/releases/release-2.1.10.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.10 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.10/','/docs-cn/dev/releases/2.1.10/'] +summary: TiDB 2.1.10 发布，修复了多个 bug 和兼容性问题，增强了安全性。PD 修复了 Leader 优先级不生效的问题。TiKV 修复了多个问题，包括 transfer leader 中可能发生的脏读问题。TiDB Lightning 新增了发送数据到 importer 失败时进行重试的功能。TiDB Binlog 优化了 Pump storage 组件 log。TiDB Ansible 更新了配置文件，新增了 tidb_lightning_ctl 脚本。 --- # TiDB 2.1.10 Release Notes diff --git a/releases/release-2.1.11.md b/releases/release-2.1.11.md index 8e95c189dcbf..9233c9e883b0 100644 --- a/releases/release-2.1.11.md +++ b/releases/release-2.1.11.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.11 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.11/','/docs-cn/dev/releases/2.1.11/'] +summary: TiDB 2.1.11 发布，修复多表 join 删除错误 schema 问题，更新统计信息合并反馈信息，修复函数返回错误字段类型问题，修复时间计算错误问题，修复与 MySQL 8.0 不兼容问题，支持 SHOW OPEN TABLES 语句，修复 goroutine 泄露问题，修复设置 tidb_snapshot 变量时间格式解析出错问题。PD 修复热点 Region 调度问题，新增热点调度优先级配置项。TiKV 修复 leader, learner 读到空 index 问题，处理锁命令放在高优先级线程池中。TiDB Binlog 新增 GC 删数据限速功能。TiDB Ansible 新增 Drainer 参数。 --- # TiDB 2.1.11 Release Notes diff --git a/releases/release-2.1.12.md b/releases/release-2.1.12.md index e12defe21845..ce33087a3197 100644 --- a/releases/release-2.1.12.md +++ b/releases/release-2.1.12.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.12 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.12/','/docs-cn/dev/releases/2.1.12/'] +summary: TiDB 2.1.12 发布，修复了多个 bug，包括类型不匹配导致进程 panic、字符集改变导致类型变化、事务中的 GRANT 误报错误等问题。同时提升了与 MySQL 的兼容性，修复了 TiDB 跟 TiKV 在 gRPC 最大封包设置不一致导致的超大封包报错问题。PD 修复了极端情况下 etcd Leader 选举阻塞的问题，TiKV 修复了 Leader 迁移过程中 Region 不可用的问题和异常掉电导致丢数据的问题。 --- # TiDB 2.1.12 Release Notes diff --git a/releases/release-2.1.13.md b/releases/release-2.1.13.md index 8ccf851f8f0c..166151259072 100644 --- a/releases/release-2.1.13.md +++ b/releases/release-2.1.13.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.13 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.13/','/docs-cn/dev/releases/2.1.13/'] +summary: TiDB 2.1.13 发布，新增了列属性包含 `AUTO_INCREMENT` 时利用 `SHARD_ROW_ID_BITS` 打散行 ID 功能，优化无效 DDL 元信息存活时间，修复了在大并发场景下 OOM 的问题，新增了 `update-stats` 配置项，新增了 3 个 TiDB 特有语法，修复了某些情况下 `KILL` 语句导致的 panic 问题，增强了 `ADD_DATE` 在某些情况下跟 MySQL 的兼容性，修复了 index join 中内表过滤条件在某些情况下的选择率估计错误的问题。TiKV 修复了因迭代器未检查状态导致系统生成残缺 snapshot 的问题，新增了检查 `block-size` 配置的有效性功能。TiDB Binlog 修复了 Pump 因写入失败时未检查返回值导致偏移量错误问题，Drainer 新增了 `advertise-addr` 配置，支持容器环境中使用桥接模式。 --- # TiDB 2.1.13 Release Notes diff --git a/releases/release-2.1.14.md b/releases/release-2.1.14.md index ac8ccbbf7c8f..bbb0e702763d 100644 --- a/releases/release-2.1.14.md +++ b/releases/release-2.1.14.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.14 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.14/','/docs-cn/dev/releases/2.1.14/'] +summary: TiDB 2.1.14 发布说明：修复查询结果不正确的问题，支持自动调整 Auto ID 分配的步长，新增全局系统变量 `max_execution_time`，修复内存配额超出时返回结果不正确的问题，禁用 `TRACE` 语句，新增系统表控制函数下推，优化 Raftstore 消息处理，调整无效配置项日志级别，新增 Binlog 配置项，修复 Binlog 更新失败问题，新增 Ansible 命令预检查功能。 --- # TiDB 2.1.14 Release Notes diff --git a/releases/release-2.1.15.md b/releases/release-2.1.15.md index 1c0cd7955e05..983395b85cd4 100644 --- a/releases/release-2.1.15.md +++ b/releases/release-2.1.15.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.15 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.15/','/docs-cn/dev/releases/2.1.15/'] +summary: TiDB 2.1.15 发布，修复了多个函数处理微秒、空值比较、插入参数、索引建立等问题，并新增了多个 SQL 语句和监控项。TiKV 统一日志格式，提高了调度准确度。PD 也统一了日志格式。TiDB Binlog 优化了 Pump GC 策略。TiDB Lightning 修复了导入错误问题。TiDB Ansible 新增监控项用于监测 SQL 语句解析耗时和执行计划编译耗时。 --- # TiDB 2.1.15 Release Notes diff --git a/releases/release-2.1.16.md b/releases/release-2.1.16.md index 0b0600a24ff9..be087781fe49 100644 --- a/releases/release-2.1.16.md +++ b/releases/release-2.1.16.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.16 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.16/','/docs-cn/dev/releases/2.1.16/'] +summary: TiDB 2.1.16 发布，修复了 SQL 优化器和执行引擎的多个问题。TiKV 支持逆向 raw_scan 和 raw_batch_scan 接口。TiDB Binlog 和 TiDB Lightning 做了一些功能增强和 bug 修复。TiDB Ansible 也有多个 bug 修复和功能优化。 --- # TiDB 2.1.16 Release Notes diff --git a/releases/release-2.1.17.md b/releases/release-2.1.17.md index b92cfc94592a..634f49486b81 100644 --- a/releases/release-2.1.17.md +++ b/releases/release-2.1.17.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.17 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.17/','/docs-cn/dev/releases/2.1.17/'] +summary: TiDB 2.1.17 发布，新增了 `SHOW TABLE REGIONS` 语法的 `WHERE` 条件子句，以及 TiKV、PD 的 `config-check` 功能。PD 优化调度流程，TiKV 优化启动流程。TiDB 慢日志中的 `start ts` 和 `Index_ids` 字段有改动。SQL 优化器和执行引擎修复了多个问题。DDL 改进了 `SPLIT TABLE` 语法的行为。TiKV 解决了一些问题并新增了 `config-check` 选项。PD 新增了 `config-check` 选项和 `remove-tombstone` 命令。Reparo 新增了配置项，用于控制恢复速率。TiDB Ansible 更新了 Spark 版本和修复了连接等待问题。 --- # TiDB 2.1.17 Release Notes diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md index 11cbc92fe626..61b9cfc7cdbe 100644 --- a/releases/release-2.1.18.md +++ b/releases/release-2.1.18.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.18 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.18/','/docs-cn/dev/releases/2.1.18/'] +summary: TiDB 2.1.18 发布，修复了多项 SQL 优化器和执行引擎的问题，改进了 Server、DDL 和 Monitor 功能，同时 TiDB Ansible 也有多项更新。 --- # TiDB 2.1.18 Release Notes diff --git a/releases/release-2.1.19.md b/releases/release-2.1.19.md index b77bef07c182..193770c3b18a 100644 --- a/releases/release-2.1.19.md +++ b/releases/release-2.1.19.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.19 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.19/','/docs-cn/dev/releases/2.1.19/'] +summary: TiDB 2.1.19 发布，包含了对 SQL 优化器、SQL 执行引擎、Server、DDL、TiKV、PD 和 TiDB Ansible 的多项修复和优化。修复了多个查询和更新语句中可能出现的错误，提升了系统稳定性和性能。 --- # TiDB 2.1.19 Release Notes diff --git a/releases/release-2.1.2.md b/releases/release-2.1.2.md index da82c0b18c41..a6a95a64c5f7 100644 --- a/releases/release-2.1.2.md +++ b/releases/release-2.1.2.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.2 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.2/','/docs-cn/dev/releases/2.1.2/'] +summary: TiDB 2.1.2 版本发布，改进了系统兼容性和稳定性。修复了多个问题，包括索引 panic、优化器执行计划、字符集检查和时间类型字段错误。PD 修复了 Region Merge 相关问题，TiKV 支持日为时间单位的配置格式，并解决了配置兼容性问题，修复了 Approximate Size Split 和两个 Region merge 相关问题。TiDB Lightning 支持最小 TiDB 集群版本为 2.1.0，修复了解析 JSON 类型数据文件内容出错和使用 checkpoint 重启后的错误。TiDB Binlog 消除了往 Kafka 写数据的瓶颈点，支持写 Kafka 版本的 TiDB Binlog。 --- # TiDB 2.1.2 Release Notes diff --git a/releases/release-2.1.3.md b/releases/release-2.1.3.md index dea1ee681316..f083286b109a 100644 --- a/releases/release-2.1.3.md +++ b/releases/release-2.1.3.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.3 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.3/','/docs-cn/dev/releases/2.1.3/'] +summary: TiDB 2.1.3 版本发布，对系统稳定性、优化器、统计信息和执行引擎做了很多改进。修复了多个问题，包括 Prepared Plan Cache panic、Range 计算错误、统计信息溢出、Generated Column 在 Update 中 Panic 等。还支持了一些新特性，如对 `_tidb_rowid` 构造查询的 Range、`CASE` 子句返回 JSON 类型等。PD 修复了 Leader 选举相关的 Watch 问题，TiKV 支持了使用 HTTP 方式获取监控信息，并修复了一些问题。TiDB Binlog 也修复了一些启动或重启时的问题。 --- # TiDB 2.1.3 Release Notes diff --git a/releases/release-2.1.4.md b/releases/release-2.1.4.md index 5510aac60dd1..126c405f04f9 100644 --- a/releases/release-2.1.4.md +++ b/releases/release-2.1.4.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.4 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.4/','/docs-cn/dev/releases/2.1.4/'] +summary: TiDB 2.1.4 版本发布，对系统稳定性、优化器、统计信息和执行引擎做了很多改进。修复了多个函数处理结果不正确的问题，优化了服务器日志和 DDL 操作。TiKV 修复了关闭时可能发生重复写的问题和事件监听器处理异常的问题。工具方面优化了内存使用，减少了对 dump 文件的解析，提高了导入稳定性。数据同步对比统计支持使用 TiDB 统计信息来划分 chunk。 --- # TiDB 2.1.4 Release Notes diff --git a/releases/release-2.1.5.md b/releases/release-2.1.5.md index ee0fd610fafc..e677afa41c8f 100644 --- a/releases/release-2.1.5.md +++ b/releases/release-2.1.5.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.5 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.5/','/docs-cn/dev/releases/2.1.5/'] +summary: TiDB 2.1.5 版本对系统稳定性、优化器、统计信息和执行引擎做了很多改进。包括优化器 / 执行器、Server、DDL、PD、TiKV 和 Tools 的改进和修复。 --- # TiDB 2.1.5 Release Notes diff --git a/releases/release-2.1.6.md b/releases/release-2.1.6.md index 2b61521a7ae9..d5b1dc7f3524 100644 --- a/releases/release-2.1.6.md +++ b/releases/release-2.1.6.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.6 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.6/','/docs-cn/dev/releases/2.1.6/'] +summary: TiDB 2.1.6 版本发布，对系统稳定性、优化器、统计信息和执行引擎做了改进。修复了多个问题，包括索引扫描选择问题、聚合函数兼容性问题、变量设置导致的 Panic 问题等。TiKV 修复了解析 protobuf 失败导致的错误。Lightning 修复了多个导入相关的问题，并支持 CSV 格式。 --- # TiDB 2.1.6 Release Notes diff --git a/releases/release-2.1.7.md b/releases/release-2.1.7.md index a0fc2e7310a6..a4b36b969006 100644 --- a/releases/release-2.1.7.md +++ b/releases/release-2.1.7.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.7 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.7/','/docs-cn/dev/releases/2.1.7/'] +summary: TiDB 2.1.7 发布，修复了 DDL 取消导致升级程序启动时间变长的问题，提升了内置函数的兼容性，新增了系统表管理 Table 与 Index 之间的关系，支持在 DO 语句中使用子查询，修复了对 JSON 数据的聚合函数在计算过程中 Panic 的问题。PD 修改副本数为 1 时 balance-region 无法迁移 leader 的问题。Tools 支持 binlog 同步 generated column。TiDB Ansible 将 Prometheus 监控数据默认保留时间改成 30d。 --- # TiDB 2.1.7 Release Notes diff --git a/releases/release-2.1.8.md b/releases/release-2.1.8.md index 4e7b0fca2463..8a59db755f54 100644 --- a/releases/release-2.1.8.md +++ b/releases/release-2.1.8.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.8 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.8/','/docs-cn/dev/releases/2.1.8/'] +summary: TiDB 2.1.8 发布，修复了多个函数和语句的兼容性问题，优化了日志格式规范和统计信息估算准确性。PD 和 TiKV 也有多项修复和优化。工具方面，Lightning 和 Binlog Pump 等新增了多项配置和性能优化。TiDB Ansible 修改了操作系统版本限制和滚动升级版本限制。 --- # TiDB 2.1.8 Release Notes diff --git a/releases/release-2.1.9.md b/releases/release-2.1.9.md index 1f957fb9fadb..be1d13210fa1 100644 --- a/releases/release-2.1.9.md +++ b/releases/release-2.1.9.md @@ -1,6 +1,7 @@ --- title: TiDB 2.1.9 Release Notes aliases: ['/docs-cn/dev/releases/release-2.1.9/','/docs-cn/dev/releases/2.1.9/'] +summary: TiDB 2.1.9 发布，修复了多个函数和权限检查问题，支持指定 collation 为 utf8mb4_0900_ai_ci，改进了慢日志输出和 PD 服务支持。 TiKV 修复了在 transfer leader 时的问题。 TiDB Binlog 和 TiDB Lightning 也有多个修复和改进。 TiDB Ansible 更新了文档链接和移除了一个参数。 --- # TiDB 2.1.9 Release Notes diff --git a/releases/release-3.0-beta.md b/releases/release-3.0-beta.md index 54540f832a92..a0d5a0f377eb 100644 --- a/releases/release-3.0-beta.md +++ b/releases/release-3.0-beta.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0 Beta Release Notes aliases: ['/docs-cn/dev/releases/release-3.0-beta/','/docs-cn/dev/releases/3.0beta/'] +summary: TiDB 3.0 Beta 版本发布，新增支持 View、窗口函数、Range 分区、Hash 分区等特性。SQL 优化器做了很多改进，包括重新支持聚合消除、优化 `NOT EXISTS` 子查询、支持 Index Join 等。SQL 执行引擎优化了 Merge Join 算子、日志打印等功能。权限管理增加了对 `ANALYZE`、`USE`、`SET GLOBAL`、`SHOW PROCESSLIST` 语句的权限检查。Server 支持了 `Trace` 功能、插件框架、`unix_socket` 和 TCP 连接等功能。兼容性方面支持了 `ALLOW_INVALID_DATES` SQL mode、load data 对 CSV 文件的容错能力等。DDL 支持了快速恢复误删除的表、动态调整 ADD INDEX 的并发数等功能。Tools 方面 TiDB Lightning 大幅优化了 SQL 转 KV 的处理速度。PD 和 TiKV 也做了很多功能增加和优化。 --- # TiDB 3.0 Beta Release Notes diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index 3c5383985d69..feb464318e43 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0 GA Release Notes aliases: ['/docs-cn/dev/releases/release-3.0-ga/','/docs-cn/dev/releases/3.0-ga/'] +summary: TiDB 3.0 GA 版本于 2019 年 6 月 28 日发布，对应的 TiDB Ansible 版本为 3.0.0。V3.0.0 版本相比 V2.1 在稳定性、易用性、性能和新功能方面有重要改进。新增功能包括窗口函数、视图、分区表、插件系统、悲观锁、SQL Plan Management 等。SQL 优化器和执行引擎也有多项优化，包括对 `NOT EXISTS` 子查询、`Outer Join`、`IN` 子查询、Index Join 等的性能提升。PD 新增了从单个节点重建集群的功能，将 Region 元信息从 etcd 移至 go-leveldb 存储引擎。TiKV 新增了分布式 GC、并行 Resolve Lock、多线程 Raftstore 和 Apply 等功能，以及对 Engine、Server、RaftStore 和 Coprocessor 的优化。Tools 方面 TiDB Lightning 新增了多项功能，TiDB Binlog 新增了多项功能，sync-diff-inspector 也新增了多项功能。TiDB Ansible 升级了监控组件版本，新增了多项监控面板和功能。 --- # TiDB 3.0 GA Release Notes diff --git a/releases/release-3.0.0-beta.1.md b/releases/release-3.0.0-beta.1.md index e6686008a063..aadaca78c541 100644 --- a/releases/release-3.0.0-beta.1.md +++ b/releases/release-3.0.0-beta.1.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.0 Beta.1 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.0-beta.1/','/docs-cn/dev/releases/3.0.0-beta.1/'] +summary: TiDB 3.0.0 Beta.1 发布，对系统稳定性、易用性、功能、优化器、统计信息和执行引擎做了很多改进。包括 SQL 优化器、SQL 执行引擎、权限管理、Server、DDL、PD、TiKV 和 Tools 的更新。 --- # TiDB 3.0.0 Beta.1 Release Notes diff --git a/releases/release-3.0.0-rc.1.md b/releases/release-3.0.0-rc.1.md index 9edee24de09d..ba3753b0a15d 100644 --- a/releases/release-3.0.0-rc.1.md +++ b/releases/release-3.0.0-rc.1.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.0-rc.1 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.0-rc.1/','/docs-cn/dev/releases/3.0.0-rc.1/'] +summary: TiDB 3.0.0-rc.1 发布，对系统稳定性、易用性、功能、优化器、统计信息和执行引擎做了很多改进。包括 SQL 优化器、执行引擎、Server、DDL、PD、TiKV、Tools 和 TiDB Ansible 的更新和修复。 --- # TiDB 3.0.0-rc.1 Release Notes diff --git a/releases/release-3.0.0-rc.2.md b/releases/release-3.0.0-rc.2.md index 21d184765c18..62afccad0785 100644 --- a/releases/release-3.0.0-rc.2.md +++ b/releases/release-3.0.0-rc.2.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.0-rc.2 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.0-rc.2/','/docs-cn/dev/releases/3.0.0-rc.2/'] +summary: TiDB 3.0.0-rc.2 发布，对系统稳定性、易用性、功能、优化器、统计信息和执行引擎做了很多改进。包括 SQL 优化器、执行引擎、Server、DDL 和 PD 的更新。TiKV 的更新包括 Engine、Server、Raftstore 和 Coprocessor 的改进。工具方面，TiDB Binlog 增加下游同步延迟监控项，TiDB Lightning 支持数据库合并和新增 KV 写入失败重试机制。 --- # TiDB 3.0.0-rc.2 Release Notes diff --git a/releases/release-3.0.0-rc.3.md b/releases/release-3.0.0-rc.3.md index 9d7f04716c5d..1ea8e40a56c6 100644 --- a/releases/release-3.0.0-rc.3.md +++ b/releases/release-3.0.0-rc.3.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.0-rc.3 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.0-rc.3/','/docs-cn/dev/releases/3.0.0-rc.3/'] +summary: TiDB 3.0.0-rc.3 发布，对系统稳定性、易用性、功能、优化器、统计信息和执行引擎做了很多改进。包括 SQL 优化器、执行引擎、Server、DDL、PD、TiKV、Transaction、tikv-ctl、Misc 等方面的修复和新增功能。TiDB Ansible 新增预测集群最大 QPS 的监控项。 --- # TiDB 3.0.0-rc.3 Release Notes diff --git a/releases/release-3.0.1.md b/releases/release-3.0.1.md index 74a138b9ff03..b1ff85d97f19 100644 --- a/releases/release-3.0.1.md +++ b/releases/release-3.0.1.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.1 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.1/','/docs-cn/dev/releases/3.0.1/'] +summary: TiDB 3.0.1 发布，新增多项功能和修复了多个问题。TiKV 新增了对 Blob 文件大小的统计和死锁检测性能的提升。PD 优化了热点 Region 调度策略和 Region Merge 处理逻辑。TiDB Binlog 优化了 Pump GC 策略。TiDB Lightning 修正了导入错误的问题。TiDB Ansible 新增了预检查功能和更新了监控信息。 --- # TiDB 3.0.1 Release Notes diff --git a/releases/release-3.0.10.md b/releases/release-3.0.10.md index a5a0b1261f0b..43a87d17ae23 100644 --- a/releases/release-3.0.10.md +++ b/releases/release-3.0.10.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.10 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.10/','/docs-cn/dev/releases/3.0.10/'] +summary: TiDB 3.0.10 发布，修复了多个 bug 和性能问题。TiKV 修复了 Region merge 失败导致系统 Panic 的问题。PD 自动更新 Region 缓存信息，解决缓存失效问题。TiDB Binlog 支持 relay log。TiDB Lightning 优化配置项和修复 web 界面无法打开的问题。TiDB Ansible 修复获取不到 PD Leader 导致命令执行失败的问题，并新增多个监控项。 --- # TiDB 3.0.10 Release Notes diff --git a/releases/release-3.0.11.md b/releases/release-3.0.11.md index b0dfa6646b69..2aa22746349d 100644 --- a/releases/release-3.0.11.md +++ b/releases/release-3.0.11.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.11 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.11/','/docs-cn/dev/releases/3.0.11/'] +summary: TiDB 3.0.11 发布，包含兼容性变化、新功能和 Bug 修复。新增配置项 `max-index-length` 控制索引最大长度，显示分区表的分区元信息，以及 TiDB 集群之间数据双向复制功能。Bug 修复包括查询结果不正确、Goroutine 泄露等问题。TiKV 也进行了日志输出优化和问题修复。TiDB Ansible 修复了失效文档链接和未定义变量问题。 --- # TiDB 3.0.11 Release Notes diff --git a/releases/release-3.0.12.md b/releases/release-3.0.12.md index a0ff71e1162a..63426168c141 100644 --- a/releases/release-3.0.12.md +++ b/releases/release-3.0.12.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.12 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.12/','/docs-cn/dev/releases/3.0.12/'] +summary: TiDB 3.0.12 发布日期为 2020 年 3 月 16 日。该版本存在一些已知问题，建议使用最新版本。兼容性变化包括修复慢日志中记录 prewrite binlog 时间计时不准确的问题。新功能包括动态加载已被替换的证书文件，添加配置项，限流功能，以及在 binlog 写入失败时 TiDB 退出。Bug 修复包括保证原子性，悲观锁加锁问题修复，建索引长度超过限制时的报错信息显示，FROM_UNIXTIME 函数小数点位数不正确的问题修复，以及其他问题的修复。 --- # TiDB 3.0.12 Release Notes diff --git a/releases/release-3.0.13.md b/releases/release-3.0.13.md index 984081bd06db..b133c2661314 100644 --- a/releases/release-3.0.13.md +++ b/releases/release-3.0.13.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.13 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.13/','/docs-cn/dev/releases/3.0.13/'] +summary: TiDB 3.0.13 发布日期为 2020 年 04 月 22 日。此版本修复了 TiDB 和 TiKV 中的一些 bug。其中 TiDB 修复了由于未检查 `MemBuffer`，事务内执行 `INSERT ... ON DUPLICATE KEY UPDATE` 语句插入多行重复数据可能出错的问题。TiKV 修复了重复多次执行 `Region Merge` 导致系统被阻塞的问题，阻塞期间服务不可用。 --- # TiDB 3.0.13 Release Notes diff --git a/releases/release-3.0.14.md b/releases/release-3.0.14.md index 7b7b358e5323..326a2dc48665 100644 --- a/releases/release-3.0.14.md +++ b/releases/release-3.0.14.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.14 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.14/','/docs-cn/dev/releases/3.0.14/'] +summary: TiDB 3.0.14 发布日期为 2020 年 5 月 9 日。该版本兼容性变化包括 `performance_schema` 和 `metrics_schema` 由读写改为只读。重点修复的 Bug 包括 join 条件在 handle 列上存在多个等值条件时，index join 查询结果错误等问题。新功能包括 `admin show ddl jobs` 查询结果中添加库名和表名列等功能。Bug 修复包括 `WEEKEND` 函数在 SQL mode 为 `ALLOW_INVALID_DATES` 时结果与 MySQL 不兼容等问题。TiKV 也有相关 Bug 修复，如节点隔离恢复之后无法被正确删掉等问题。 --- # TiDB 3.0.14 Release Notes diff --git a/releases/release-3.0.15.md b/releases/release-3.0.15.md index 0044fcf8fa7c..8b3041ef8bd3 100644 --- a/releases/release-3.0.15.md +++ b/releases/release-3.0.15.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.15 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.15/'] +summary: TiDB 3.0.15 发布，新增禁止分区表查询使用 plan cache 功能、支持 admin recover index、admin check index 语句、优化统计信息 CMSketch 的内存分配机制等功能。PD 新增按照 Leader 个数调度的策略。修复了多处 Bug，包括 Hash 聚合函数中的深拷贝方式、点查整数溢出处理逻辑、CHAR() 函数查询条件处理逻辑等问题。TiKV 修复了长时间运行后碎片整理不再有效、系统意外重启后删除 snapshot 文件导致系统 panic、消息包过大导致 gRPC 连接断开的问题。 --- # TiDB 3.0.15 Release Notes diff --git a/releases/release-3.0.16.md b/releases/release-3.0.16.md index 7b9161fa5be5..01d31a789131 100644 --- a/releases/release-3.0.16.md +++ b/releases/release-3.0.16.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.16 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.16/'] +summary: TiDB 3.0.16 发布，优化了 hash partition pruning 和 Region 设置，修复了多个 Bug，包括锁住的 primary key 造成的结果不一致问题和 JSON 数据中 int 和 float 类型比较的问题。TiKV 也进行了稳定性优化和 Bug 修复。PD 修复了查询 Region 报 404 错误的问题。 --- # TiDB 3.0.16 Release Notes diff --git a/releases/release-3.0.17.md b/releases/release-3.0.17.md index 47a967fc3efa..1d853ffb393f 100644 --- a/releases/release-3.0.17.md +++ b/releases/release-3.0.17.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.17 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.17/'] +summary: TiDB 3.0.17 发布，修复了多个 bug，包括查询返回错误和函数处理问题。优化了配置项和 HTTP API 访问速度。TiKV 修复了数据读取和调度问题，新增了配置支持。TiDB Lightning 解决了参数不生效的问题，并新增了更简单易用的过滤规则。 --- # TiDB 3.0.17 Release Notes diff --git a/releases/release-3.0.18.md b/releases/release-3.0.18.md index 77241919d8d9..5309b82a734d 100644 --- a/releases/release-3.0.18.md +++ b/releases/release-3.0.18.md @@ -1,5 +1,6 @@ --- title: TiDB 3.0.18 Release Notes +summary: TiDB 3.0.18 发布，提升了 TiDB Binlog 工具的细粒度 Pump GC 时间支持。修复了 TiDB 中 Hash 函数对 Decimal 类型的错误处理问题，以及对 Set 和 Enum 类型的错误处理问题。还修复了 Duplicate Key 检测在悲观事务下失效的问题，以及其他执行结果错误的问题。TiKV 将 GC 的失败日志级别改为 Warning。TiDB Lightning 修复了多个命令行参数和使用 TiDB backend 时的问题。 --- # TiDB 3.0.18 Release Notes diff --git a/releases/release-3.0.19.md b/releases/release-3.0.19.md index 68a800731288..5fcc441bdfe0 100644 --- a/releases/release-3.0.19.md +++ b/releases/release-3.0.19.md @@ -1,5 +1,6 @@ --- title: TiDB 3.0.19 Release Notes +summary: TiDB 3.0.19 发布，兼容性变化包括更改 PD 的导入路径和版权信息。提升改进方面，缓解故障恢复对 QPS 的影响，支持调整 `union` 运算符的并发数。Bug 修复包括解决 `slow-log` 文件不存在导致查询出错的问题，添加权限检查命令，修复类型转换问题等。TiKV 修复了 status server 解析响应出错导致 panic 的问题。TiDB Lightning 修复了严格模式下 CSV 中遇到不合法 UTF 字符集没有及时退出进程的问题。 --- # TiDB 3.0.19 Release Notes diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index b189717587bf..dd79795381be 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.2 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.2/','/docs-cn/dev/releases/3.0.2/'] +summary: TiDB 3.0.2 发布日期为 2019 年 8 月 7 日。该版本修复了多个 SQL 优化器和执行引擎的问题，包括修复了查询结果列名称不正确、LIKE 表达式被隐式转换为 0、SHOW 语句中使用子查询等问题。此外，还修复了 TiKV panic、悲观事务下 Insert 行为不正确等问题。PD 也修复了 Scatter Region 调度器不能工作等 bug。TiDB Ansible 也有多个修复和更新，包括修复了 Disk Performance 监控单位错误、新增了 TiDB Summary Dashboard 等。 --- # TiDB 3.0.2 Release Notes diff --git a/releases/release-3.0.20.md b/releases/release-3.0.20.md index 748e05c0e6ae..f2a460c119e5 100644 --- a/releases/release-3.0.20.md +++ b/releases/release-3.0.20.md @@ -1,5 +1,6 @@ --- title: TiDB 3.0.20 Release Notes +summary: TiDB 3.0.20 发布，兼容性更改包括废弃 `enable-streaming` 配置项。改进提升包括优化 `LOAD DATA` 语句执行报错信息。Bug 修复包括缓存悲观事务提交状态问题、查询统计信息不准确问题等。TiKV 修复事务删除 key 报错问题，PD 修复启动时打印过量日志问题。 --- # TiDB 3.0.20 Release Notes diff --git a/releases/release-3.0.3.md b/releases/release-3.0.3.md index 157f31ad3544..d191a0ef390d 100644 --- a/releases/release-3.0.3.md +++ b/releases/release-3.0.3.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.3 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.3/','/docs-cn/dev/releases/3.0.3/'] +summary: TiDB 3.0.3 发布，包含了多项 SQL 优化器和执行引擎的修复，以及 Server、DDL、Monitor、TiKV、PD、Tools 和 TiDB Ansible 的更新和修复。 --- # TiDB 3.0.3 Release Notes diff --git a/releases/release-3.0.4.md b/releases/release-3.0.4.md index 947d04c46d57..b38464d890c5 100644 --- a/releases/release-3.0.4.md +++ b/releases/release-3.0.4.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.4 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.4/','/docs-cn/dev/releases/3.0.4/'] +summary: TiDB 3.0.4 发布日期为 2019 年 10 月 8 日。此版本新增了系统表 `performance_schema.events_statements_summary_by_digest` 用于排查 SQL 性能问题。同时，TiDB 的 `SHOW TABLE REGIONS` 语法新增了 `WHERE` 条件子句。此外，Reparo 新增了 `worker-count` 和 `txn-batch` 配置项，用于控制恢复速率。还修复了一些问题，如特殊语法 `PRE_SPLIT_REGIONS` 没有使用注释的方式向下游同步的问题。 --- # TiDB 3.0.4 Release Notes diff --git a/releases/release-3.0.5.md b/releases/release-3.0.5.md index 8094ec40f526..b65cb11bc53b 100644 --- a/releases/release-3.0.5.md +++ b/releases/release-3.0.5.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.5 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.5/','/docs-cn/dev/releases/3.0.5/'] +summary: TiDB 3.0.5 发布，包含 SQL 优化器和执行引擎的多项修复和改进，支持事务 TTL 修改接口函数，以及对 Region Cache TTL 的配置修改。TiKV 新特性包括悲观事务 Cleanup 接口支持和 Raftstore 性能优化。PD 提高了 Region 占用空间的精度和 label 监控可读性。TiDB Binlog 和 TiDB Lightning 也有多项修复和功能增强。TiDB Ansible 更新了监控表达式和配置文件内容。 --- # TiDB 3.0.5 Release Notes diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md index 27fcbb4958ed..87be32aafe50 100644 --- a/releases/release-3.0.6.md +++ b/releases/release-3.0.6.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.6 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.6/','/docs-cn/dev/releases/3.0.6/'] +summary: TiDB 3.0.6 发布，包含多项 SQL 优化器和执行引擎的修复和优化，以及 Server、DDL、TiKV、PD 和 Tools 的更新和修复。TiKV 修复了悲观锁支持和 GC worker 写入量限制等问题。PD 添加了新维度和降低日志级别。Tools 中 TiDB Binlog 和 TiDB Lightning 也有多项修复和新增配置。 --- # TiDB 3.0.6 Release Notes diff --git a/releases/release-3.0.7.md b/releases/release-3.0.7.md index fc8e4d30d8e3..551fe98c0aec 100644 --- a/releases/release-3.0.7.md +++ b/releases/release-3.0.7.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.7 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.7/','/docs-cn/dev/releases/3.0.7/'] +summary: TiDB 3.0.7 发布，修复了多个问题，包括本地时间落后导致锁的 TTL 过大、解析日期时时区不正确、整型数据转换精度丢失等问题。TiKV 也修复了死锁检测和内存泄漏问题。 --- # TiDB 3.0.7 Release Notes diff --git a/releases/release-3.0.8.md b/releases/release-3.0.8.md index 3751b672f0c5..f73b37325afc 100644 --- a/releases/release-3.0.8.md +++ b/releases/release-3.0.8.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.8 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.8/','/docs-cn/dev/releases/3.0.8/'] +summary: TiDB 3.0.8 发布，修复了 SQL 优化器、SQL 执行引擎、DDL、Server、Transaction、Monitor 等方面的多个问题。TiKV 也进行了多项修复和优化。PD 新增了一些功能，并升级了 etcd 版本。TiDB Ansible 进行了配置项回滚和优化，TiSpark 版本升级到 2.1.8。 --- # TiDB 3.0.8 Release Notes diff --git a/releases/release-3.0.9.md b/releases/release-3.0.9.md index ce651d003668..fe0733394f8d 100644 --- a/releases/release-3.0.9.md +++ b/releases/release-3.0.9.md @@ -1,6 +1,7 @@ --- title: TiDB 3.0.9 Release Notes aliases: ['/docs-cn/dev/releases/release-3.0.9/','/docs-cn/dev/releases/3.0.9/'] +summary: TiDB 3.0.9 发布日期为 2020 年 1 月 14 日。该版本修复了一些已知问题，并提升了性能。包括 Executor 修复了聚合函数作用于枚举和集合列时结果不正确的问题，Server 支持了系统变量 `auto_increment_increment` 和 `auto_increment_offset`，新增了监控项等。TiKV 提升了 Raft 成员变更的速度，新增了监控项用于监控 `waiter` 的生命周期等。PD 新增了一些功能和修复了一些问题。Tools 方面也有一些新增和优化。TiDB Ansible 优化了 Lightning 部署。 --- # TiDB 3.0.9 Release Notes diff --git a/releases/release-3.1.0-beta.1.md b/releases/release-3.1.0-beta.1.md index 2118c58405a6..b180bba8e3c9 100644 --- a/releases/release-3.1.0-beta.1.md +++ b/releases/release-3.1.0-beta.1.md @@ -1,6 +1,7 @@ --- title: TiDB 3.1 Beta.1 Release Notes aliases: ['/docs-cn/dev/releases/release-3.1.0-beta.1/','/docs-cn/dev/releases/3.1.0-beta.1/'] +summary: TiDB 3.1 Beta.1 发布日期为 2020 年 1 月 10 日。TiDB 版本为 3.1.0-beta.1，TiDB Ansible 版本也为 3.1.0-beta.1。TiKV 新增了备份功能和 SST 文件恢复修复。Tools 中 BR 组件修复了备份进度信息不准确的问题，并新增了自动调度 PD schedulers 功能。TiDB Ansible 新增了初始化阶段自动关闭操作系统 THP 的功能和 BR 组件的 Grafana 监控。 --- # TiDB 3.1 Beta.1 Release Notes diff --git a/releases/release-3.1.0-beta.2.md b/releases/release-3.1.0-beta.2.md index 3a61ada9d37e..206f01d5997b 100644 --- a/releases/release-3.1.0-beta.2.md +++ b/releases/release-3.1.0-beta.2.md @@ -1,6 +1,7 @@ --- title: TiDB 3.1 Beta.2 Release Notes aliases: ['/docs-cn/dev/releases/release-3.1.0-beta.2/','/docs-cn/dev/releases/3.1.0-beta.2/'] +summary: TiDB 3.1 Beta.2 发布日期为 2020 年 3 月 9 日。该版本存在已知问题，建议使用最新版本。兼容性变化包括 TiDB Lightning 配置项优化和新增命令行参数。新功能包括支持在列属性上添加 `AutoRandom` 关键字，新增通过 DDL 语句为表创建、删除列存储副本的功能等。Bug 修复包括修复静默 Region 读数据处理不当导致无法处理读请求的问题等。 --- # TiDB 3.1 Beta.2 Release Notes diff --git a/releases/release-3.1.0-beta.md b/releases/release-3.1.0-beta.md index 228ebd33406a..4f67a45d6483 100644 --- a/releases/release-3.1.0-beta.md +++ b/releases/release-3.1.0-beta.md @@ -1,6 +1,7 @@ --- title: TiDB 3.1 Beta Release Notes aliases: ['/docs-cn/dev/releases/release-3.1.0-beta/','/docs-cn/dev/releases/3.1.0-beta/'] +summary: TiDB 3.1 Beta 发布说明：发版日期为 2019 年 12 月 20 日，TiDB 版本为 3.1.0-beta，TiDB Ansible 版本为 3.1.0-beta。TiDB 新增 SQL 优化器和丰富的 SQL hint 功能。另外，TiDB 还支持 Follower Read 功能。TiKV 新增支持分布式备份恢复功能和 Follower Read 功能。PD 也新增支持分布式备份恢复功能。 --- # TiDB 3.1 Beta Release Notes diff --git a/releases/release-3.1.0-ga.md b/releases/release-3.1.0-ga.md index 5f346832df28..b3164f865cd3 100644 --- a/releases/release-3.1.0-ga.md +++ b/releases/release-3.1.0-ga.md @@ -1,6 +1,7 @@ --- title: TiDB 3.1 GA Release Notes aliases: ['/docs-cn/dev/releases/release-3.1.0-ga/','/docs-cn/dev/releases/3.1.0-ga/'] +summary: TiDB 3.1 GA 发布说明：兼容性变化包括支持报告状态配置项和 BR 不支持旧版 TiKV 集群恢复。新功能包括展示 coprocessor 任务信息和减少日志冗余信息。PD 优化热点 Region 调度，TiFlash 添加读写负载信息和支持函数下推。TiDB Ansible 新增 TiFlash 监控和优化配置参数。Bug 修复包括修复 merge join 和计算选择率问题。TiKV 修复 replica read 和 restore 问题，TiFlash 修复同步 schema 和数据丢失问题。TiDB Binlog 修复因 TiFlash 相关 DDL job 导致同步中断问题，BR 修复 checksum 和增量备份失败问题。 --- # TiDB 3.1 GA Release Notes diff --git a/releases/release-3.1.0-rc.md b/releases/release-3.1.0-rc.md index 50d0e84c263a..5531c4fd5b6f 100644 --- a/releases/release-3.1.0-rc.md +++ b/releases/release-3.1.0-rc.md @@ -1,6 +1,7 @@ --- title: TiDB 3.1 RC Release Notes aliases: ['/docs-cn/dev/releases/release-3.1.0-rc/','/docs-cn/dev/releases/3.1.0-rc/'] +summary: TiDB 3.1 RC 发布日期为 2020 年 4 月 2 日。该版本存在已知问题，建议使用最新版本 3.1.x。新功能包括性能提升、数据恢复、TLS 证书动态更新等。Bug 修复包括信息 schema 错误、DDL 卡住、冲突检测失效等。PD 修复了数据竞争、规则未遵守等问题。工具方面优化了性能、修复了数据错误和无法恢复的问题。 --- # TiDB 3.1 RC Release Notes diff --git a/releases/release-3.1.1.md b/releases/release-3.1.1.md index fe604f6c418c..c066532f86ab 100644 --- a/releases/release-3.1.1.md +++ b/releases/release-3.1.1.md @@ -1,6 +1,7 @@ --- title: TiDB 3.1.1 Release Notes aliases: ['/docs-cn/dev/releases/release-3.1.1/','/docs-cn/dev/releases/3.1.1/'] +summary: TiDB 3.1.1 发布，新增了 auto_rand_base 表选项和 Feature ID 注释。TiFlash 优化了读写负载相关图表和 chunk encode decimal 数据的流程。修复了隔离读设置不生效、hash 分区表上的分区选择语法报错、update sql 中包含 view 仍然报错等问题。TiFlash 修复了非 normal 状态时读取数据错误、表名映射方式支持 recover table/flashback table、数据存储路径问题、读模型优化和特殊字符导致无法启动的问题。BR 修复了恢复带有 auto_random 属性的表后插入数据触发 duplicate entry 错误的问题。 --- # TiDB 3.1.1 Release Notes diff --git a/releases/release-3.1.2.md b/releases/release-3.1.2.md index 4ffce0fafac4..ca58d2ac448b 100644 --- a/releases/release-3.1.2.md +++ b/releases/release-3.1.2.md @@ -1,6 +1,7 @@ --- title: TiDB 3.1.2 Release Notes aliases: ['/docs-cn/dev/releases/release-3.1.2/'] +summary: TiDB 3.1.2 发布日期为 2020 年 6 月 4 日。此版本修复了 TiKV 和 Tools 中的一些错误，包括 S3 和 GCS 备份恢复时的错误处理问题，备份过程中的 DefaultNotFound 错误，以及 BR 在备份恢复到 S3 和 GCS 存储时的稳定性提升等问题。同时还修复了 BR 在恢复数据时出现的一些错误，并增加了备份恢复 S3 时的 AWS KMS 服务端加密支持。 --- # TiDB 3.1.2 Release Notes diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md index a6fdaffe9b21..eb7ee315d393 100644 --- a/releases/release-4.0-ga.md +++ b/releases/release-4.0-ga.md @@ -1,6 +1,7 @@ --- title: TiDB 4.0 GA Release Notes aliases: ['/docs-cn/dev/releases/release-4.0-ga/'] +summary: TiDB 4.0 GA 发布日期为 2020 年 5 月 28 日。该版本包含兼容性变化、重点修复的 Bug、新功能、Bug 修复等内容。其中 TiDB 新增了多项配置项和语法支持，TiFlash 修复了多项功能不一致的问题，TiKV 修复了多个备份和系统 panic 相关的问题，PD 修复了删除调度器和 presplit 功能无法正常使用的问题，Tools 中 BR 修复了从云存储恢复数据失败的问题，TiCDC 修复了多个系统 panic 和资源泄露的问题。 --- # TiDB 4.0 GA Release Notes diff --git a/releases/release-4.0.0-beta.1.md b/releases/release-4.0.0-beta.1.md index 0fd7831325b9..d742f9b9caa6 100644 --- a/releases/release-4.0.0-beta.1.md +++ b/releases/release-4.0.0-beta.1.md @@ -1,6 +1,7 @@ --- title: TiDB 4.0.0 Beta.1 Release Notes aliases: ['/docs-cn/dev/releases/release-4.0.0-beta.1/','/docs-cn/dev/releases/4.0.0-beta.1/'] +summary: TiDB 4.0.0 Beta.1 发布，包含兼容性变化、新功能和 Bug 修复。兼容性变化包括配置项类型修改和默认值调整。新增慢日志系统表支持查询任意时间段的日志，SQL 性能诊断功能和 Sequence 功能。Bug 修复包括视图创建、时区修改和函数表达式问题。TiKV 和 PD 也有新增功能和 Bug 修复。TiDB Ansible 新增部署多个 Grafana/Prometheus/Alertmanager 的功能和 TiFlash 监控 Dashboard。 --- # TiDB 4.0.0 Beta.1 Release Notes diff --git a/releases/release-4.0.0-beta.2.md b/releases/release-4.0.0-beta.2.md index 9703ac055ef8..ca6b3273d1a5 100644 --- a/releases/release-4.0.0-beta.2.md +++ b/releases/release-4.0.0-beta.2.md @@ -1,6 +1,7 @@ --- title: TiDB 4.0.0 Beta.2 Release Notes aliases: ['/docs-cn/dev/releases/release-4.0.0-beta.2/','/docs-cn/dev/releases/4.0.0-beta.2/'] +summary: TiDB 4.0.0 Beta.2 发布日期为 2020 年 3 月 18 日。该版本修复了 TiDB Binlog 在配置 `disable-dispatch`、`disable-causality` 时系统直接报错并退出的问题。新增了 TiKV 和 PD 支持将动态修改配置的结果持久化存储到硬盘的功能。另外，TiDB Binlog 新增了 TiDB 集群之间数据双向复制功能，TiDB Lightning 新增了配置 TLS 功能，新增了 TiCDC 工具，提供了进程级别的高可用能力。此外，BR 开启了增量备份、支持将备份文件存储在 AWS S3 等实验性功能。TiDB Ansible 新增了将节点信息注册到 etcd 的功能，新增支持在 ARM 平台上部署 TiDB 服务的功能。修复了 TiKV、PD 和 Tools 中的多个 bug。 --- # TiDB 4.0.0 Beta.2 Release Notes diff --git a/releases/release-4.0.0-beta.md b/releases/release-4.0.0-beta.md index 10dc8d8404a4..51cadc068459 100644 --- a/releases/release-4.0.0-beta.md +++ b/releases/release-4.0.0-beta.md @@ -1,6 +1,7 @@ --- title: TiDB 4.0 Beta Release Notes aliases: ['/docs-cn/dev/releases/release-4.0.0-beta/','/docs-cn/dev/releases/4.0.0-beta/'] +summary: TiDB 4.0 Beta 发布说明：TiDB 版本 4.0.0-beta 和 TiDB Ansible 版本 4.0.0-beta 已发布。更新内容包括性能优化、新功能支持、bug 修复等。详细信息请查阅官方发布说明。 --- # TiDB 4.0 Beta Release Notes diff --git a/releases/release-4.0.0-rc.1.md b/releases/release-4.0.0-rc.1.md index 7f306fee3330..c919b10381fb 100644 --- a/releases/release-4.0.0-rc.1.md +++ b/releases/release-4.0.0-rc.1.md @@ -1,6 +1,7 @@ --- title: TiDB 4.0 RC.1 Release Notes aliases: ['/docs-cn/dev/releases/release-4.0.0-rc.1/','/docs-cn/dev/releases/4.0.0-rc.1/'] +summary: TiDB 4.0 RC.1 发布说明：TiDB 4.0.0-rc.1 版本兼容性变化包括 TiKV 默认关闭 hibernate region，TiDB Binlog 增加对 Sequence DDL 的支持。重点修复了多个 Bug，包括 TiDB 事务内执行 INSERT ... ON DUPLICATE KEY UPDATE 语句插入多行重复数据可能出错的问题等。新增功能包括 TiDB 支持发送 batch coprocessor 请求给 TiFlash 等。Bug 修复包括 TiDB 系统表由于 unsigned 列定义导致无法正确显示负数的问题等。 --- # TiDB 4.0 RC.1 Release Notes diff --git a/releases/release-4.0.0-rc.2.md b/releases/release-4.0.0-rc.2.md index b2c4b4bb5532..4dab53eb3f61 100644 --- a/releases/release-4.0.0-rc.2.md +++ b/releases/release-4.0.0-rc.2.md @@ -1,6 +1,7 @@ --- title: TiDB 4.0 RC.2 Release Notes aliases: ['/docs-cn/dev/releases/release-4.0.0-rc.2/'] +summary: TiDB 4.0 RC.2 发布说明：兼容性变化包括事务容量上限统一为 10GB，查询 CLUSTER_LOG 表需指定时间范围，CREATE TABLE 创建分区表时指定未支持的选项将创建非分区普通表。重点修复了多个 Bug。新增了备份和恢复语句，支持预检查单个 Region 提交数据量。TiKV 新增了加密存储适配和配置 gRPC 消息大小上限。PD 修复了 pd-ctl 命令错误和缺失监控的问题。TiFlash 优化了系统负载和新增了容量配置参数。Tools 方面修复了多个问题和优化了功能。 --- # TiDB 4.0 RC.2 Release Notes diff --git a/releases/release-4.0.0-rc.md b/releases/release-4.0.0-rc.md index 80d6b33f26e7..7cf33252de6b 100644 --- a/releases/release-4.0.0-rc.md +++ b/releases/release-4.0.0-rc.md @@ -1,6 +1,7 @@ --- title: TiDB 4.0 RC Release Notes aliases: ['/docs-cn/dev/releases/release-4.0.0-rc/','/docs-cn/dev/releases/4.0.0-rc/'] +summary: TiDB 4.0 RC 发布日期为 2020 年 4 月 8 日，版本为 4.0.0-rc，TiUP 版本为 0.0.3。该版本存在已知问题，建议使用最新版本 4.0.x。兼容性变化包括 TiDB、TiKV 和 Tools 的更新。重点修复了 TiDB 的 Bug，并新增了一些功能。TiKV 修复了启用 Follower Read 功能导致系统 Panic 的问题。Tools 中 TiDB Lightning 修复了字符转换错误导致数据错误的问题，TiCDC 新增了一些功能。 --- # TiDB 4.0 RC Release Notes diff --git a/releases/release-4.0.1.md b/releases/release-4.0.1.md index c9896d435585..e42682cd1a90 100644 --- a/releases/release-4.0.1.md +++ b/releases/release-4.0.1.md @@ -1,6 +1,7 @@ --- title: TiDB 4.0.1 Release Notes aliases: ['/docs-cn/dev/releases/release-4.0.1/'] +summary: TiDB 4.0.1 发布日期为 2020 年 6 月 12 日。新功能包括 TiKV 添加 `--advertise-status-addr` 启动参数，PD 支持内部代理和客户端自定义超时设置，TiFlash 支持新的排序规则框架和函数下推，以及 BR 增加集群版本检查。Bug 修复方面，TiKV 修复了多个问题，PD 修复了错误配置和 panic 问题，TiFlash 修复了默认值解析和时区计算错误的问题。 --- # TiDB 4.0.1 Release Notes diff --git a/releases/release-4.0.10.md b/releases/release-4.0.10.md index f8d2a60bac04..23877c1a7e6f 100644 --- a/releases/release-4.0.10.md +++ b/releases/release-4.0.10.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.10 Release Notes +summary: TiDB 4.0.10 发布日期为 2021 年 1 月 15 日。新功能包括 PD 添加了配置项 `enable-redact-log` 和 TiFlash 添加了配置项 `security.redact_info_log`。改进提升方面，TiDB 添加了 `txn-entry-size-limit` 配置项，PD 优化了 `store-state-filter` 监控，Tools 中 TiCDC 默认开启了 old value 特性。Bug 修复方面，TiDB 修复了多个并发导致的问题，TiKV 修复了 peer 和 ready 之间的错误映射，PD 修复了 ID 分配不是单调递增的问题，TiFlash 修复了多个启动和函数调用的问题，Tools 中 TiCDC 修复了多个协议和内存问题，Dumpling 修改了默认设置的行为。 Backup & Restore (BR) 修复了多个备份和恢复问题，TiDB Binlog 修复了启用 `AMEND TRANSACTION` 特性时的问题，TiDB Lightning 修复了多个备份和使用问题。 --- # TiDB 4.0.10 Release Notes diff --git a/releases/release-4.0.11.md b/releases/release-4.0.11.md index 5d53b415fd0a..8f660d32bedf 100644 --- a/releases/release-4.0.11.md +++ b/releases/release-4.0.11.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.11 Release Notes +summary: TiDB 4.0.11 发布，新增支持 `uft8_unicode_ci` 和 `utf8mb4_unicode_ci` 排序规则。TiKV 支持 `utf8mb4_unicode_ci` 和 `cast_year_as_time` 排序规则。TiFlash 增加排队处理 Coprocessor 任务的线程池。改进包括重排由 `outer join` 简化的 `inner join` 顺序，Grafana 面板支持多集群，Bug 修复包括修复异常的 `unicode_ci` 常数传递等。PD 修复成员健康的监控显示不正确的问题。TiFlash 修复 Decimal 类型的 `min`/`max` 计算结果错误等。Tools 修复 TiCDC 服务在同时发生 `ErrTaskStatusNotExists` 和 `capture` 会话关闭的情况下的非预期的退出等。 --- # TiDB 4.0.11 Release Notes diff --git a/releases/release-4.0.12.md b/releases/release-4.0.12.md index 42d53052aa3b..4224365ea134 100644 --- a/releases/release-4.0.12.md +++ b/releases/release-4.0.12.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.12 Release Notes +summary: TiDB 4.0.12 发布，新增 TiFlash 工具用于检测状态。优化了 EXPLAIN 语句输出信息，在 metrics 监控中记录了 PREPARE 执行失败的问题。TiKV 修复了多个问题，包括处理 JSON 向字符串转换时空格缺失的问题。PD 修复了 store 缺失 label 的隔离级别错误问题。TiFlash 修复了多个查询结果错误的问题。TiCDC 修复了多个数据丢失和资源释放问题。BR 修复了多个备份和恢复问题。TiDB Lightning 修复了多个数据错误和文件损坏问题。 --- # TiDB 4.0.12 Release Notes diff --git a/releases/release-4.0.13.md b/releases/release-4.0.13.md index 55d3ed533e45..8ba12ebfaba3 100644 --- a/releases/release-4.0.13.md +++ b/releases/release-4.0.13.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.13 Release Notes +summary: TiDB 4.0.13 发布，新增 `AUTO_INCREMENT` 变更为 `AUTO_RANDOM` 功能，引入 `infoschema.client_errors_summary` 表。提升内存中统计信息缓存，减少 CPU 使用率。TiKV 提高 `store used size` 计算准确性，返回更多的 Region 以降低 Region miss。PD 优化 TSO 处理时间统计指标，更新 Dashboard 版本。TiFlash 自动清除过期历史数据。BR 支持备份恢复系统库，检查集群版本和备份数据版本。TiCDC 增加流程控制，清理陈旧临时文件，增加 HTTP 接口调用。修复多个 Bug。 --- # TiDB 4.0.13 Release Notes diff --git a/releases/release-4.0.14.md b/releases/release-4.0.14.md index 2cfcef6e2245..9d0d060aa2b1 100644 --- a/releases/release-4.0.14.md +++ b/releases/release-4.0.14.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.14 Release Notes +summary: TiDB 4.0.14 发布，包含兼容性更改、功能增强、改进提升和 Bug 修复。兼容性更改包括默认值修改和配置项更新。功能增强包括监控项添加和新功能支持。改进提升包括算子优化和系统变量支持。Bug 修复包括查询结果错误和函数参数错误修复。PD、TiDB Dashboard、TiFlash 和 Tools 也有相关更新和修复。 --- # TiDB 4.0.14 Release Notes diff --git a/releases/release-4.0.15.md b/releases/release-4.0.15.md index 8398ca32db40..501ffc17c178 100644 --- a/releases/release-4.0.15.md +++ b/releases/release-4.0.15.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.15 Release Notes +summary: TiDB 4.0.15 发布，修复了执行 `SHOW VARIABLES` 速度慢的问题，以及多个 Bug 和兼容性变化。TiKV 支持动态修改 TiCDC 配置。TiDB 基于直方图的 row count 来触发 auto-analyze。TiKV 分离处理读写的 ready 状态以减少读延迟。PD 提升了同步 Region 信息的性能。BR 支持并发执行分裂和打散 Region 的操作。Dumpling 提升了 `SHOW TABLE STATUS` 的过滤效率。TiCDC 支持导入数据到带有表达式索引或带有基于虚拟生成列的索引的表中。修复了多个 Bug 和问题。 --- # TiDB 4.0.15 Release Notes diff --git a/releases/release-4.0.16.md b/releases/release-4.0.16.md index 4639d263dd2c..b267524be573 100644 --- a/releases/release-4.0.16.md +++ b/releases/release-4.0.16.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.16 Release Notes +summary: TiDB 4.0.16 发布，包含兼容性更改、提升改进和 Bug 修复。TiKV 改进了对非法 UTF-8 字符串的处理，Tools 中 TiCDC 改变了 Kafka Sink 默认值。TiDB 升级了 Grafana，TiKV 使用 zstd 算法压缩 SST 文件。Bug 修复包括统计信息模块的查询崩溃、`ENUM` 类型控制函数返回结果不正确等问题。TiKV 修复了多个问题，包括 Decimal 除法计算结果为负、监控项中 gRPC 平均延迟时间不准确等问题。PD 修复了节点缩容后可能导致 Panic 的问题。TiFlash 修复了无法启动的问题。Tools 中 TiDB Binlog 修复了 Drainer 传输事务超过 1 GB 时退出的问题，TiCDC 修复了多个问题。 --- # TiDB 4.0.16 Release Notes diff --git a/releases/release-4.0.2.md b/releases/release-4.0.2.md index 43991591908c..a1051fbf6cd5 100644 --- a/releases/release-4.0.2.md +++ b/releases/release-4.0.2.md @@ -1,6 +1,7 @@ --- title: TiDB 4.0.2 Release Notes aliases: ['/docs-cn/dev/releases/release-4.0.2/'] +summary: TiDB 4.0.2 发布，兼容性改进和新功能增加。TiDB 默认收集使用情况信息，并分享给 PingCAP 用于改善产品。新增功能包括支持 INSERT 语句中使用 MEMORY_QUOTA() hint，基于 TLS 证书 SAN 属性的登录认证，以及其他函数和表的新增配置项。Bug 修复包括执行计划不正确、运行时错误、内存统计过大等问题。PD、TiKV、TiFlash 和 TiCDC 也有相关改进和修复。Tools 中 Backup & Restore (BR) 提升了多表场景下的恢复数据性能。 --- # TiDB 4.0.2 Release Notes diff --git a/releases/release-4.0.3.md b/releases/release-4.0.3.md index c2834f0dbad3..84c6cf281e24 100644 --- a/releases/release-4.0.3.md +++ b/releases/release-4.0.3.md @@ -1,6 +1,7 @@ --- title: TiDB 4.0.3 Release Notes aliases: ['/docs-cn/dev/releases/release-4.0.3/'] +summary: TiDB 4.0.3 发布了新版本，包括 TiDB Dashboard、TiFlash、Tools 和改进提升等多个方面的更新和修复。新增功能包括 TiDB Dashboard 显示详细信息、TiFlash 支持文件加密、Tools 支持多种算法压缩备份文件等。改进提升方面包括增加全局变量控制日志记录、加速执行速度、默认打开执行信息收集等。此外，还修复了多个 Bug，包括 gRPC transportReader 异常、数据不完整、无法正确设置 safepoint 等问题。 --- # TiDB 4.0.3 Release Notes diff --git a/releases/release-4.0.4.md b/releases/release-4.0.4.md index 64d615256b19..fb41e81d6020 100644 --- a/releases/release-4.0.4.md +++ b/releases/release-4.0.4.md @@ -1,6 +1,7 @@ --- title: TiDB 4.0.4 Release Notes aliases: ['/docs-cn/dev/releases/release-4.0.4/'] +summary: TiDB 4.0.4 发布日期为 2020 年 7 月 31 日。此版本修复了多个 bug，包括查询 `information_schema.columns` 卡死的问题、`PointGet` 和 `BatchPointGet` 在遇到 `in(null)` 条件时出错的问题、`BatchPointGet` 算子结果不正确的问题以及 `HashJoin` 算子在遇到 `set`、`enum` 类型时查询结果不正确的问题。 --- # TiDB 4.0.4 Release Notes diff --git a/releases/release-4.0.5.md b/releases/release-4.0.5.md index 9ab4b4e03821..3ac749e5baa7 100644 --- a/releases/release-4.0.5.md +++ b/releases/release-4.0.5.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.5 Release Notes +summary: TiDB 4.0.5 发布，兼容性变化包括修改参数和添加状态检查。新增功能包括为错误定义错误码和支持统一的 log 格式。优化提升包括减少 GC 锁扫描次数和降低统计信息对性能的影响。Bug 修复包括函数错误处理和查询结果错误等。PD 修复了 TSO 不可用和 Region 调度问题。TiFlash 修复了进程启动和升级问题。Tools 修复了恢复缓慢和同步任务问题。 --- # TiDB 4.0.5 Release Notes diff --git a/releases/release-4.0.6.md b/releases/release-4.0.6.md index a2f9f659540e..bf9d685af229 100644 --- a/releases/release-4.0.6.md +++ b/releases/release-4.0.6.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.6 Release Notes +summary: TiDB 4.0.6 发布日期为 2020 年 9 月 15 日。新功能包括 TiFlash 中支持在广播 Join 中使用外连接，TiDB Dashboard 添加了多个页面和功能。TiCDC 从 v4.0.6 起成为正式功能，支持输出 `maxwell` 格式的数据。优化提升方面，TiDB 提升了分区表的写性能，支持调整 Union 执行算子的并发度等。Bug 修复方面，TiDB 修复了多个查询结果不正确的问题。TiKV 修复了统计信息估算错误的问题等。PD 修复了 store limit 的单位问题等。TiFlash 修复了多个启动失败和异常问题。Tools 方面也有多个问题得到解决。 --- # TiDB 4.0.6 Release Notes diff --git a/releases/release-4.0.7.md b/releases/release-4.0.7.md index edfb3fa2812e..fc23c29cfeae 100644 --- a/releases/release-4.0.7.md +++ b/releases/release-4.0.7.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.7 Release Notes +summary: TiDB 4.0.7 发布，新增 PD 客户端函数 `GetAllMembers` 和 TiDB Dashboard 统计指标关系图支持。TiDB 优化了 `join` 算子执行信息和协处理器缓存命中率信息，支持将 `ROUND` 函数下推至 TiFlash，并修复了多个 bug。TiKV 支持日志输出为 JSON 格式，修复了 TLS 握手失败导致 Status API 不可用的问题。PD 修复了多个问题，TiFlash 修正了 right outer join 结果错误。Backup & Restore (BR) 修复了恢复数据后导致 TiDB 配置变更的错误，Dumpling 修复了 metadata 解析失败的问题。 --- # TiDB 4.0.7 Release Notes diff --git a/releases/release-4.0.8.md b/releases/release-4.0.8.md index 6dd50fcde2e2..09344582cf58 100644 --- a/releases/release-4.0.8.md +++ b/releases/release-4.0.8.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.8 Release Notes +summary: TiDB 4.0.8 发布，新增聚合函数 `APPROX_PERCENTILE` 和 `CAST` 函数下推支持。优化了索引组合计算表达式选择率的贪心算法，记录更多的 RPC 信息，提升慢查询性能。修复了多个 BUG，如分区表可能遇到非预期 Panic、外连接时 Index Merge Join 结果不正确等。 PD 修复了 TiDB Dashboard 引起 PD panic 的错误。TiFlash 修复了多个问题，如日志信息中时间戳错误、重启后可能提示数据文件损坏等。Backup & Restore (BR) 修复了 Restore 期间可能发生的 `send on closed channel` panic 问题。 --- # TiDB 4.0.8 Release Notes diff --git a/releases/release-4.0.9.md b/releases/release-4.0.9.md index 8131120ebf72..c7fd623824ec 100644 --- a/releases/release-4.0.9.md +++ b/releases/release-4.0.9.md @@ -1,5 +1,6 @@ --- title: TiDB 4.0.9 Release Notes +summary: TiDB 4.0.9 发布日期为 2020 年 12 月 21 日。该版本包含兼容性更改、新功能、优化提升、Bug 修复等内容。兼容性更改包括废弃配置文件中的某些配置项。新功能包括 TiFlash 支持存储引擎的新数据分布在多个硬盘上等。优化提升方面包括避免生成 (index) merge join 以得到更好的执行计划等。Bug 修复方面包括修复了前缀索引和 `OR` 条件一起使用时结果不正确的问题等。 --- # TiDB 4.0.9 Release Notes diff --git a/releases/release-5.0.0-rc.md b/releases/release-5.0.0-rc.md index 18d3411f24d9..6a94e9c34c81 100644 --- a/releases/release-5.0.0-rc.md +++ b/releases/release-5.0.0-rc.md @@ -1,5 +1,6 @@ --- title: TiDB 5.0 RC Release Notes +summary: TiDB 5.0.0-rc 版本是 5.0 版本的前序版本。在 5.0 版本中，我们专注于帮助企业基于 TiDB 数据库快速构建应用程序，提升数据库性能、降低写入数据延迟、稳定性、可用性、容灾、SQL 语句效率等问题。新增聚簇索引、异步提交事务、Raft Joint Consensus 算法、不可见索引、`EXCEPT`/`INTERSECT` 操作符、悲观事务执行成功概率、字符集和排序规则优化、错误信息和日志信息脱敏、优化器选择索引稳定性、调度功能优化、备份与恢复、数据导入导出、`EXPLAIN` 功能优化、TiUP 增强功能等特性。 --- # TiDB 5.0 RC Release Notes diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md index ebc729eb709c..1ffe15094791 100644 --- a/releases/release-5.0.0.md +++ b/releases/release-5.0.0.md @@ -1,5 +1,6 @@ --- title: What's New in TiDB 5.0 +summary: TiDB 5.0 版本新增了许多功能和优化，包括 MPP 架构、聚簇索引、异步提交事务、Raft Joint Consensus 算法等。此外，还优化了系统变量、配置文件参数、性能、稳定性和数据迁移功能。TiUP 工具也进行了多项优化，包括部署操作逻辑、升级稳定性、升级时长和运维功能。遥测方面新增了集群使用指标的收集。 --- # What's New in TiDB 5.0 diff --git a/releases/release-5.0.1.md b/releases/release-5.0.1.md index 1ad6374e9fc9..56900923e1be 100644 --- a/releases/release-5.0.1.md +++ b/releases/release-5.0.1.md @@ -1,5 +1,6 @@ --- title: TiDB 5.0.1 Release Notes +summary: TiDB 5.0.1 发布日期为 2021 年 4 月 24 日。此版本包含兼容性更改、改进提升、Bug 修复等内容。兼容性更改包括 TiDB 配置文件的默认值改变。改进提升方面，TiDB 支持 `VITESS_HASH()` 函数，TiKV 使用 `zstd` 压缩 Region Snapshot，PD 调整 Region 分数公式等。Bug 修复方面，TiDB 修复了多个查询结果可能错误的问题，TiKV 修复了多个导致问题的 Bug。Tools 方面也有多个 Bug 修复。 --- # TiDB 5.0.1 Release Notes diff --git a/releases/release-5.0.2.md b/releases/release-5.0.2.md index fe67bb161b66..cd7068c4ca2d 100644 --- a/releases/release-5.0.2.md +++ b/releases/release-5.0.2.md @@ -1,5 +1,6 @@ --- title: TiDB 5.0.2 Release Notes +summary: TiDB 5.0.2 发布日期为 2021 年 6 月 10 日。此版本包含兼容性更改、新功能、提升改进和 Bug 修复。兼容性更改包括 TiCDC 工具中的参数废弃和 TiKV 默认开启 Hibernate Region 特性。新功能包括 BR 支持 S3 兼容的存储和 TiFlash 优化锁操作。提升改进方面，TiDB 避免后台作业频繁读取表造成高 CPU 使用率，TiKV 添加背压功能和减少扫描的内存使用量。Bug 修复方面，修复了多个问题，包括索引导致的 panic、事务中的语句不正确使用、排序规则写入错误值等。 --- # TiDB 5.0.2 Release Notes diff --git a/releases/release-5.0.3.md b/releases/release-5.0.3.md index aac27e96c526..7b8787bddfe2 100644 --- a/releases/release-5.0.3.md +++ b/releases/release-5.0.3.md @@ -1,5 +1,6 @@ --- title: TiDB 5.0.3 Release Notes +summary: TiDB 5.0.3 发布日期为 2021 年 7 月 2 日。此版本包含兼容性更改、功能增强、提升改进和 Bug 修复。兼容性更改包括 `tidb_multi_statement_mode` 变量默认值变更和兼容 MySQL 5.7 的 noop 变量配置。功能增强方面，TiCDC 增加了 HTTP API 获取 changefeed 信息和节点健康信息。TiDB 提升了多个内置函数的支持和优化了聚合算子的代价常数。Bug 修复方面，修复了多个查询和函数使用时可能出现的问题。PD 升级了 TiDB Dashboard。TiFlash 支持了多个新功能和修复了多个问题。TiCDC、BR 和 TiDB Lightning 也进行了多项修复和优化。 --- # TiDB 5.0.3 Release Notes diff --git a/releases/release-5.0.4.md b/releases/release-5.0.4.md index f0ef264dd6d1..a534b4e710b1 100644 --- a/releases/release-5.0.4.md +++ b/releases/release-5.0.4.md @@ -1,5 +1,6 @@ --- title: TiDB 5.0.4 Release Notes +summary: TiDB 5.0.4 发布日期为 2021 年 9 月 27 日。此版本包含兼容性更改、功能增强、提升改进、Bug 修复等内容。兼容性更改包括修复了 `SHOW VARIABLES` 速度慢的问题，系统变量 `tidb_stmt_summary_max_stmt_count` 默认值修改为 `3000` 等。功能增强包括支持将系统变量 `tidb_enforce_mpp` 的值设为 `1` 以忽略优化器代价估算，强制使用 MPP 模式。提升改进包括基于直方图的 row count 来触发 auto-analyze、支持 MPP 查询的重试等。Bug 修复包括修复了查询分区表且分区键带有 `IS NULL` 条件时 TiDB 可能 panic 的问题等。 --- # TiDB 5.0.4 Release Notes diff --git a/releases/release-5.0.5.md b/releases/release-5.0.5.md index d7a886b9e10f..4dd7de282836 100644 --- a/releases/release-5.0.5.md +++ b/releases/release-5.0.5.md @@ -1,5 +1,6 @@ --- title: TiDB 5.0.5 Release Note +summary: TiDB 5.0.5 发布日期为 2021 年 12 月 3 日，修复了 TiKV 中的 `GcKeys` 任务被多个键调用时无法正常进行的问题。这可能导致 Compaction Filter GC 不删除 MVCC deletion 信息。详细信息请查看 issue #11217。 --- # TiDB 5.0.5 Release Note diff --git a/releases/release-5.0.6.md b/releases/release-5.0.6.md index 9da0042d1342..8227a2272d52 100644 --- a/releases/release-5.0.6.md +++ b/releases/release-5.0.6.md @@ -1,5 +1,6 @@ --- title: TiDB 5.0.6 Release Notes +summary: TiDB 5.0.6 发布日期为 2021 年 12 月 31 日。此版本包含兼容性更改、提升改进和 Bug 修复。兼容性更改包括 TiCDC 工具的错误输出改为标准错误，以及 Kafka sink 模块的默认值设置。提升改进方面，TiDB 改进了 coprocessor 遇到锁时的调试日志显示，TiKV 提高了插入 SST 文件的速度，PD 优化了调度器退出的速度。Bug 修复方面，TiDB 修复了多个问题，包括乐观事务冲突、MPP 查询相关日志、DML 和 DDL 语句并发执行等。TiKV 修复了多个节点停机导致的问题，PD 修复了节点缩容后可能导致 Panic 的问题。TiFlash 修复了多个数据不一致的问题。TiCDC 修复了多个同步任务推进停滞的问题。Backup & Restore (BR) 修复了平均速度不准确的问题。Dumpling 修复了导出速度过慢的问题。 --- # TiDB 5.0.6 Release Notes diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md index 7983eaf36bc0..eed5bd498211 100644 --- a/releases/release-5.1.0.md +++ b/releases/release-5.1.0.md @@ -1,5 +1,6 @@ --- title: TiDB 5.1 Release Notes +summary: TiDB 5.1 版本新增了许多关键特性，包括对 MySQL 8 中的公共表表达式和动态权限的支持，以及对数据表列类型的在线变更。此外，还引入了新的统计信息类型和锁视图功能，以提升查询稳定性和性能。同时，TiDB 5.1 修复了许多 Bug，包括投影消除、列包含 NULL 值时查询结果错误等问题。这些改进和修复将提升 TiDB 的性能和稳定性。 --- # TiDB 5.1 Release Notes diff --git a/releases/release-5.1.1.md b/releases/release-5.1.1.md index e9313e5df86d..587712bc63e6 100644 --- a/releases/release-5.1.1.md +++ b/releases/release-5.1.1.md @@ -1,5 +1,6 @@ --- title: TiDB 5.1.1 Release Notes +summary: TiDB 5.1.1 发布，兼容性更改包括默认值修改和权限变更。功能增强方面新增 OIDC SSO 支持和 DAG 请求中的 `HAVING()` 函数。改进提升包括 Stale Read 成为正式功能、加快数据插入速度、稳定结果模式支持等。Bug 修复方面修复了多个问题，包括数据丢失、panic、数据不一致等。 Tools 方面也有多个修复，包括 TiCDC、Backup & Restore、TiDB Lightning。 --- # TiDB 5.1.1 Release Notes diff --git a/releases/release-5.1.2.md b/releases/release-5.1.2.md index a1d834eaf4f2..4d57a2d03bad 100644 --- a/releases/release-5.1.2.md +++ b/releases/release-5.1.2.md @@ -1,5 +1,6 @@ --- title: TiDB 5.1.2 Release Notes +summary: TiDB 5.1.2 发布，包含兼容性更改、改进提升、Bug 修复等内容。兼容性更改包括修复多个 Bug，改进提升包括根据直方图行数触发 auto-analyze、支持动态更改 TiCDC 配置项等。Bug 修复涉及 hash 列为 ENUM 类型时 index hash join 的结果可能出错、TiKV 从 v3.x 升级至较高版本后出现 Panic 等问题。Tools 方面的改进包括 BR 修复备份数据和恢复数据时显示的平均速度数值不准确的问题、Dumpling 修复特定 MySQL 版本下导致 dump 阶段卡死的问题等。 --- # TiDB 5.1.2 Release Notes diff --git a/releases/release-5.1.3.md b/releases/release-5.1.3.md index d8aeb5194c28..13688abdaca6 100644 --- a/releases/release-5.1.3.md +++ b/releases/release-5.1.3.md @@ -1,5 +1,6 @@ --- title: TiDB 5.1.3 Release Note +summary: TiDB 5.1.3 发布日期为 2021 年 12 月 3 日，修复了 TiKV 中的 `GcKeys` 任务被多个键调用时无法正常进行的问题。这可能导致 Compaction Filter GC 不删除 MVCC deletion 信息。 --- # TiDB 5.1.3 Release Note diff --git a/releases/release-5.1.4.md b/releases/release-5.1.4.md index a12d51950f0b..b3d3404ba191 100644 --- a/releases/release-5.1.4.md +++ b/releases/release-5.1.4.md @@ -1,5 +1,6 @@ --- title: TiDB 5.1.4 Release Notes +summary: TiDB 5.1.4 发布日期为 2022 年 2 月 22 日。此版本包含兼容性更改、提升改进和 Bug 修复。兼容性更改包括系统变量 `tidb_analyze_version` 默认值修改为 `1`，以及 TiKV 在开启 `storage.enable-ttl` 后拒绝 TiDB 请求。提升改进方面，TiDB 支持在 Range 类型分区表中对 `IN` 表达式进行分区裁剪，TiKV 升级了 proc filesystem 版本。Bug 修复方面，修复了多个 TiDB 和 TiKV 的问题，包括内存泄露、配置项不生效、panic 等。Tools 方面也有多个修复和改进，包括 TiCDC、Backup & Restore、TiDB Binlog 和 TiDB Lightning。 --- # TiDB 5.1.4 Release Notes diff --git a/releases/release-5.1.5.md b/releases/release-5.1.5.md index 4e7fb81ce816..8de8c28b849f 100644 --- a/releases/release-5.1.5.md +++ b/releases/release-5.1.5.md @@ -1,5 +1,6 @@ --- title: TiDB 5.1.5 Release Notes +summary: TiDB 5.1.5 发布日期为 2022 年 12 月 28 日。此版本包含 PD 默认关闭编译 swagger server 的兼容性变更以及 TiDB、TiKV、PD、TiFlash 和 Tools 中的多项 Bug 修复。修复内容涵盖了窗口函数执行、动态模式、函数传入值计算、left join 删除数据、SQL 语句计算、连接错误、索引错误、HTTP 服务异常、并发列类型变更、空闲链接、SESSION 变量、Region 合并、KV client 连接、TiDB Binlog 错误、TiKV 运行、Raftstore 线程、Region merge、Follower Read、Async Commit、网络问题、Unified Read Pool CPU 表达式、TLS、并行聚合、查询错误、日期格式、MPP query、数据回收、逻辑运算符、备份系统表、增量扫描、Sorter 组件监控数据和 ddl schema 缓存优化。 --- # TiDB 5.1.5 Release Notes diff --git a/releases/release-5.2.0.md b/releases/release-5.2.0.md index bb8ee9cd20f7..74f39d140086 100644 --- a/releases/release-5.2.0.md +++ b/releases/release-5.2.0.md @@ -1,5 +1,6 @@ --- title: TiDB 5.2 Release Notes +summary: TiDB 5.2 版本于 2021 年 8 月 27 日发布。该版本新增了许多功能和改进，包括支持基于部分函数创建表达式索引、提升优化器的估算准确度、锁视图成为 GA 特性等。此外，还修复了多个 bug，提升了稳定性和性能。 --- # TiDB 5.2 Release Notes diff --git a/releases/release-5.2.1.md b/releases/release-5.2.1.md index 0c3d4388dfe2..c3b5b516a078 100644 --- a/releases/release-5.2.1.md +++ b/releases/release-5.2.1.md @@ -1,5 +1,6 @@ --- title: TiDB 5.2.1 Release Notes +summary: TiDB 5.2.1 发布日期为 2021 年 9 月 9 日。此版本修复了 TiDB 在分区中下推聚合算子时的执行计划和执行报错问题。同时，TiKV 修复了 Region 迁移时出现的死锁导致 TiKV 不可用的问题。用户可通过关闭调度并重启出问题的 TiKV 来临时应对。 --- # TiDB 5.2.1 Release Notes diff --git a/releases/release-5.2.2.md b/releases/release-5.2.2.md index 31947cd73e7a..f43b5d0ced83 100644 --- a/releases/release-5.2.2.md +++ b/releases/release-5.2.2.md @@ -1,5 +1,6 @@ --- title: TiDB 5.2.2 Release Notes +summary: TiDB 5.2.2 发布日期为 2021 年 10 月 29 日。此版本包含了对 TiDB、TiKV、PD 和 Tools 的多项提升改进和 bug 修复。其中 TiDB 修复了多项问题，如 `plan cache` 无法感知 `unsigned` 标志变化、分区功能出现 `out of range` 时 `partition pruning` 出错等。TiKV 修复了因 Congest 错误而导致的 CDC 频繁增加 scan 重试的问题等。PD 修复了因超过副本配置数量而导致错误删除带有数据且处于 pending 状态的副本的问题等。TiFlash 修复了在部分平台上由于缺失 `nsl` 库而无法启动的问题。Tools 中的 TiCDC 也进行了多项修复，如当上游 TiDB 实例意外退出时，TiCDC 同步任务推进可能停滞的问题等。 --- # TiDB 5.2.2 Release Notes diff --git a/releases/release-5.2.3.md b/releases/release-5.2.3.md index 25505dff11b8..1834055e11fb 100644 --- a/releases/release-5.2.3.md +++ b/releases/release-5.2.3.md @@ -1,5 +1,6 @@ --- title: TiDB 5.2.3 Release Note +summary: TiDB 5.2.3 发布日期为 2021 年 12 月 3 日，修复了 TiKV 中的 `GcKeys` 任务被多个键调用时无法正常进行的问题。这可能导致 Compaction Filter GC 不删除 MVCC deletion 信息。 --- # TiDB 5.2.3 Release Note diff --git a/releases/release-5.2.4.md b/releases/release-5.2.4.md index 0ce36284a9d6..e6744676bf40 100644 --- a/releases/release-5.2.4.md +++ b/releases/release-5.2.4.md @@ -1,6 +1,7 @@ --- title: TiDB 5.2.4 Release Notes category: Releases +summary: TiDB 5.2.4 发布日期为 2022 年 4 月 26 日。此版本包含兼容性更改、提升改进和 Bug 修复。兼容性更改包括 TiDB、TiKV 和 Tools 的调整。提升改进主要针对 TiKV 和 Tools 进行了优化。Bug 修复方面涉及 TiDB、TiKV、PD、TiFlash 和 Tools 的修复。 --- # TiDB 5.2.4 Release Notes diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md index ac590d22a451..28df364296c6 100644 --- a/releases/release-5.3.0.md +++ b/releases/release-5.3.0.md @@ -1,5 +1,6 @@ --- title: TiDB 5.3 Release Notes +summary: TiDB 5.3.0 版本发布了许多重要的功能和改进，包括临时表、表属性设置、TiDB Dashboard 安全性提升、PD 时间戳处理流程优化、DM 同步性能提升、TiDB Lightning 分布式并行导入等。此外，还修复了许多 bug，提升了稳定性和性能。 --- # TiDB 5.3 Release Notes diff --git a/releases/release-5.3.1.md b/releases/release-5.3.1.md index ef2b24fcd78d..c43b92c866a5 100644 --- a/releases/release-5.3.1.md +++ b/releases/release-5.3.1.md @@ -1,5 +1,6 @@ --- title: TiDB 5.3.1 Release Notes +summary: TiDB 5.3.1 发布日期为 2022 年 3 月 3 日。此版本包含兼容性更改、提升改进和 Bug 修复。兼容性更改包括 TiDB Lightning 工具的默认值调整。提升改进包括 TiDB、TiKV 和 PD 的优化。Bug 修复包括 TiDB、TiKV、PD、TiFlash、Backup & Restore (BR)、TiCDC、TiDB Data Migration (DM) 和 TiDB Lightning 工具的问题修复。 --- # TiDB 5.3.1 Release Notes diff --git a/releases/release-5.3.2.md b/releases/release-5.3.2.md index 443ed32fb0d6..203b4a2aae86 100644 --- a/releases/release-5.3.2.md +++ b/releases/release-5.3.2.md @@ -1,5 +1,6 @@ --- title: TiDB 5.3.2 Release Notes +summary: TiDB 5.3.2 发布日期为 2022 年 6 月 29 日。该版本存在 bug，建议升级至 v5.3.3。兼容性变更包括修复了 auto ID 超出范围时的问题。TiKV 提升了 Raft 客户端的效率，并修复了多个 bug。TiDB 修复了多个 bug，包括 Amazon S3 数据计算错误和网络连接问题。PD 也修复了多个 bug。TiFlash 修复了存储目录配置错误和数据不一致的问题。BR 和 TiCDC 也有多个 bug 修复。DM 和 TiDB Lightning 也有 bug 修复。 --- # TiDB 5.3.2 Release Notes diff --git a/releases/release-5.3.3.md b/releases/release-5.3.3.md index 82f12061a62f..fa1fa07cd697 100644 --- a/releases/release-5.3.3.md +++ b/releases/release-5.3.3.md @@ -1,5 +1,6 @@ --- title: TiDB 5.3.3 Release Note +summary: TiDB 5.3.3 发布日期为 2022 年 9 月 14 日。此版本修复了 TiKV 存在的 bug，该 bug 导致在执行 SQL 语句时出现持续报错的问题。影响版本为 v5.3.2 和 v5.4.2，已在 v5.3.3 上修复。如果使用 v5.3.2 的 TiDB 集群，可以升级至 v5.3.3。除升级外，还可以重启无法向 PD 发送 Region 心跳的 TiKV 节点，直至不再有待发送的 Region 心跳为止。 --- # TiDB 5.3.3 Release Note diff --git a/releases/release-5.3.4.md b/releases/release-5.3.4.md index 5ff2bf80acc0..ea286a2d3172 100644 --- a/releases/release-5.3.4.md +++ b/releases/release-5.3.4.md @@ -1,5 +1,6 @@ --- title: TiDB 5.3.4 Release Notes +summary: TiDB 5.3.4 发布，提升了 TiKV 的自动 TLS 证书重新加载功能。修复了 TiDB、PD 和 TiFlash 的多个 bug，包括 Region 合并、权限清理、连接失败等问题。同时修复了工具 Dumpling 和 TiCDC 的导出数据和同步任务状态不正确的问题。 --- # TiDB 5.3.4 Release Notes diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md index 228c9365864f..5bb81e14c2a5 100644 --- a/releases/release-5.4.0.md +++ b/releases/release-5.4.0.md @@ -1,5 +1,6 @@ --- title: TiDB 5.4 Release Notes +summary: TiDB 5.4.0 版本发布日期为 2022 年 2 月 15 日。此版本新增了许多功能和改进，包括支持 GBK 字符集、索引合并、有界限过期数据读取、统计信息采集配置持久化等。同时还修复了许多 bug，提升了稳定性和性能。 --- # TiDB 5.4 Release Notes diff --git a/releases/release-5.4.1.md b/releases/release-5.4.1.md index 03f4b4abfce8..999533ae77c4 100644 --- a/releases/release-5.4.1.md +++ b/releases/release-5.4.1.md @@ -1,5 +1,6 @@ --- title: TiDB 5.4.1 Release Notes +summary: TiDB 5.4.1 发布日期为 2022 年 5 月 13 日。该版本未引入产品设计上的兼容性变化，但 Bug 修复可能带来兼容性变更。提升改进包括对 TiDB、TiKV、PD、TiFlash 和 Tools 的多个方面的改进。Bug 修复方面包括对 TiDB、TiKV、PD、TiFlash 和 Tools 的多个问题的修复。 --- # TiDB 5.4.1 Release Notes diff --git a/releases/release-5.4.2.md b/releases/release-5.4.2.md index b1320ff121f3..c4a16d8426ee 100644 --- a/releases/release-5.4.2.md +++ b/releases/release-5.4.2.md @@ -1,5 +1,6 @@ --- title: TiDB 5.4.2 Release Notes +summary: TiDB 5.4.2 发布日期为 2022 年 7 月 8 日。该版本存在 bug，建议升级至 v5.4.3。此版本提升了 TiDB、TiKV、PD 和 Tools 的稳定性和可用性，并修复了多个 bug。 --- # TiDB 5.4.2 Release Notes diff --git a/releases/release-5.4.3.md b/releases/release-5.4.3.md index 0bd197e1f88d..579e91a1c2a7 100644 --- a/releases/release-5.4.3.md +++ b/releases/release-5.4.3.md @@ -1,5 +1,6 @@ --- title: TiDB 5.4.3 Release Notes +summary: TiDB 5.4.3 发布，提升了 TiKV 和 Tools 的功能，修复了多个 Bug。包括 TiKV 支持更小的 RocksDB write stall 参数，TiDB 修复了多个查询和执行时可能出现的问题。PD 也修复了一些请求和权限问题。TiFlash 修复了一些函数和并行聚合的错误。Tools 中的 TiDB Lightning 修复了一些数据导入和连接问题，DM 修复了一些数据同步和连接问题，BR 修复了备份恢复和 Region 不均衡的问题，Dumpling 修复了 IPv6 的支持问题。 --- # TiDB 5.4.3 Release Notes diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index 66a9057ed80d..58a2a0e6c64d 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -1,5 +1,6 @@ --- title: TiDB 6.0.0 Release Notes +summary: 了解 TiDB 6.0.0 版本的新功能、兼容性变更、改进提升，以及错误修复。 --- # TiDB 6.0.0 Release Notes diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index 46b8c1edca78..f42a16d925af 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -1,5 +1,6 @@ --- title: TiDB 6.1.1 Release Notes +summary: TiDB 6.1.1 发布日期为 2022 年 9 月 1 日。该版本兼容性变更包括大小写敏感语句不再敏感，以及默认关闭持续性能分析特性。其他变更包括新增内容和不同操作系统和 CPU 架构的支持。提升改进方面，引入了新的优化器提示和支持通过 gzip 压缩 metrics 响应减少 HTTP body 大小。Bug 修复方面，修复了多个 TiDB、TiKV、PD 和 TiFlash 的问题。 Tools 方面，TiDB Lightning 修复了多个问题，TiDB Data Migration (DM) 修复了多个问题，TiCDC 修复了多个问题，Backup & Restore (BR) 修复了多个问题，Dumpling 修复了一个问题，TiDB Binlog 修复了一个问题。 --- # TiDB 6.1.1 Release Notes diff --git a/releases/release-6.1.2.md b/releases/release-6.1.2.md index 5e91db89ca2f..49e0a0c4d284 100644 --- a/releases/release-6.1.2.md +++ b/releases/release-6.1.2.md @@ -1,5 +1,6 @@ --- title: TiDB 6.1.2 Release Notes +summary: TiDB 6.1.2 发布，包括 TiDB、TiKV、Tools 和 Bug 修复。提升改进包括允许在一张表上同时设置数据放置规则和 TiFlash 副本。Bug 修复包括修复数据库级别的权限清理不正确的问题。 --- # TiDB 6.1.2 Release Notes diff --git a/releases/release-6.1.3.md b/releases/release-6.1.3.md index bd24ec2eaad9..d37b70dcf200 100644 --- a/releases/release-6.1.3.md +++ b/releases/release-6.1.3.md @@ -1,5 +1,6 @@ --- title: TiDB 6.1.3 Release Notes +summary: TiDB 6.1.3 发布日期为 2022 年 12 月 5 日。此版本兼容性变更包括 TiCDC 的默认值修改和事务拆分功能的优化。提升改进方面，PD 优化了锁的粒度，TiCDC 默认关闭 safeMode 并开启大事务拆分功能。此外，为了提升 TiDB 稳定性，Go 编译器版本从 go1.18 升级到了 go1.19。Bug 修复方面，修复了多个 TiDB、PD、TiKV、TiFlash 和 Tools 的问题。 --- # TiDB 6.1.3 Release Notes diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md index 65cbd21393ff..0e540cd1a476 100644 --- a/releases/release-6.2.0.md +++ b/releases/release-6.2.0.md @@ -1,5 +1,6 @@ --- title: TiDB 6.2.0 Release Notes +summary: 了解 TiDB 6.2.0 版本的新功能、兼容性变更、改进提升，以及错误修复。 --- # TiDB 6.2.0 Release Notes diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 2c29a2914f5c..298a254ae69e 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -1,5 +1,6 @@ --- title: TiDB 6.3.0 Release Notes +summary: 了解 TiDB 6.3.0 版本的新功能、兼容性变更、改进提升，以及错误修复。 --- # TiDB 6.3.0 Release Notes diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index 24e7f6d3bffc..c0e44cfec4bb 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -1,5 +1,6 @@ --- title: TiDB 6.4.0 Release Notes +summary: 了解 TiDB 6.4.0 版本的新功能、兼容性变更、改进提升，以及错误修复。 --- # TiDB 6.4.0 Release Notes diff --git a/releases/release-notes.md b/releases/release-notes.md index 86bbeb15e454..103410d48d5b 100644 --- a/releases/release-notes.md +++ b/releases/release-notes.md @@ -1,6 +1,7 @@ --- title: TiDB 版本发布历史 aliases: ['/docs-cn/dev/releases/release-notes/','/docs-cn/dev/releases/rn/'] +summary: 介绍 TiDB 版本发布历史。 --- # TiDB 版本发布历史 diff --git a/releases/release-pre-ga.md b/releases/release-pre-ga.md index 188c2bdf7a94..1aaeba4b8db6 100644 --- a/releases/release-pre-ga.md +++ b/releases/release-pre-ga.md @@ -1,6 +1,7 @@ --- title: TiDB Pre-GA Release Notes aliases: ['/docs-cn/dev/releases/release-pre-ga/','/docs-cn/dev/releases/prega/'] +summary: TiDB Pre-GA 版本发布，对 MySQL 兼容性、SQL 优化器、系统稳定性、性能做了大量工作。TiDB 改进了 SQL 查询优化器、大量 MySQL 兼容性相关功能、支持 Natural Join、JSON 类型支持、裁剪无用数据、支持在 SQL 语句中设置优先级、完成表达式重构。PD 支持手动切换 PD 集群 Leader。TiKV 改进了 Raft Log 使用独立的 RocksDB 实例、使用 DeleteRange 加快删除副本速度、Coprocessor 支持更多运算符下推、提升性能和稳定性。TiSpark Beta Release 支持谓词下推、支持聚合下推、支持范围裁剪。 --- # TiDB Pre-GA Release Notes diff --git a/releases/release-rc.1.md b/releases/release-rc.1.md index fc900bd59e32..d2143f49e55d 100644 --- a/releases/release-rc.1.md +++ b/releases/release-rc.1.md @@ -1,6 +1,7 @@ --- title: TiDB RC1 Release Notes aliases: ['/docs-cn/dev/releases/release-rc.1/','/docs-cn/dev/releases/rc1/'] +summary: TiDB RC1 于 2016 年 12 月 23 日发布，TiKV 提升了写入速度和稳定性，支持百 TB 级别数据，集群规模支持 200 个节点。PD 优化了调度策略框架，添加了 label 支持，提供了 PD Controler。TiDB 新增了 SQL 查询优化器和更多 MySQL 内建函数，重构了 time 相关类型的实现，提升了和 MySQL 的兼容性。工具方面，Loader 兼容 Percona 的 Mydumper 数据格式，提供了多线程导入、出错重试、断点续传等功能，并且针对 TiDB 有优化。完成了一键部署工具。 --- # TiDB RC1 Release Notes diff --git a/releases/release-rc.2.md b/releases/release-rc.2.md index b7c7a38f7360..131bf1fcd6c7 100644 --- a/releases/release-rc.2.md +++ b/releases/release-rc.2.md @@ -1,6 +1,7 @@ --- title: TiDB RC2 Release Notes aliases: ['/docs-cn/dev/releases/release-rc.2/','/docs-cn/dev/releases/rc2/'] +summary: TiDB RC2 版本发布，提升了 MySQL 兼容性、SQL 优化器、系统稳定性和性能。对于 OLTP 场景，读取性能提升 60%，写入性能提升 30%。新增权限管理功能，支持基本权限管理和大量 MySQL 内建函数。完善监控，修复 Bug 和内存泄漏问题。PD 支持 Label 对副本进行 Location 调度，基于 region 数量的快速调度，pd-ctl 支持更多功能。TiKV 支持 Async Apply 提升整体写入性能，优化单行读事务性能，支持更多下推功能，加入更多统计，修复 Bug。 --- # TiDB RC2 Release Notes diff --git a/releases/release-rc.3.md b/releases/release-rc.3.md index 665d1b447ea0..45a1b54d0607 100644 --- a/releases/release-rc.3.md +++ b/releases/release-rc.3.md @@ -1,6 +1,7 @@ --- title: TiDB RC3 Release Notes aliases: ['/docs-cn/dev/releases/release-rc.3/','/docs-cn/dev/releases/rc3/'] +summary: TiDB RC3 版本发布，对 MySQL 兼容性、SQL 优化器、系统稳定性、性能做了大量工作。重点优化了负载均衡调度策略和流程，完善权限管理功能，DDL 速度显著提升。开源了 TiDB Ansible 项目，可以一键部署 / 升级 / 启停 TiDB 集群。PD 支持 Label 对副本进行 Location 调度，基于 region 数量的快速调度，pd-ctl 支持更多功能。TiKV 支持 Async Apply 提升整体写入性能，优化单行读事务性能，修复 Bug。 --- # TiDB RC3 Release Notes diff --git a/releases/release-rc.4.md b/releases/release-rc.4.md index 1c6ee1181121..85641721a787 100644 --- a/releases/release-rc.4.md +++ b/releases/release-rc.4.md @@ -1,6 +1,7 @@ --- title: TiDB RC4 Release Notes aliases: ['/docs-cn/dev/releases/release-rc.4/','/docs-cn/dev/releases/rc4/'] +summary: TiDB RC4 版本对 MySQL 兼容性、SQL 优化器、系统稳定性、性能做了大量工作。重点优化了写入速度，计算任务调度支持优先级，避免分析型大事务影响在线事务。SQL 优化器全新改版，查询代价估算更准确，且能自动选择 Join 物理算子。功能方面进一步 MySQL 兼容性。同时开源了 TiSpark 项目，可以通过 Spark 读取和分析 TiKV 中的数据。PD 支持通过 PD 设置 TiKV location labels，调度优化，优化数据加载，加快 failover 速度。 TiKV 支持查询优先级设置，支持 RC 隔离级别，完善 Jepsen，支持 Document Store，提升性能，提升稳定性。TiSpark Beta Release 支持谓词下推，支持聚合下推，支持范围裁剪。 --- # TiDB RC4 Release Notes diff --git a/resources/doc-templates/template-troubleshooting.md b/resources/doc-templates/template-troubleshooting.md index ad0f674687ef..4dc7dbaf4015 100644 --- a/resources/doc-templates/template-troubleshooting.md +++ b/resources/doc-templates/template-troubleshooting.md @@ -1,62 +1,62 @@ ---- -title: 故障现象（与文档一级标题保持一致） -summary: 介绍 xxx 故障的排查思路、可能的原因和解决方法。 ---- - -# 故障现象（与文首 metadata 中的 title 名称保持一致） - -模版说明： - -- 本文档为故障处理类模板，包含故障诊断和解决方案信息。你可直接复制使用，并删除模板中不需要的说明。该类文档示例：[读写延迟增加](/troubleshoot-cpu-issues.md)。 -- 请在 TOC.md 中合适的位置加目录（思考用户最有可能在哪里找文档）。 -- 文内标题级别不可跳级，尽量避免使用五级标题。 - -本文档介绍 xxx 故障的排查思路、可能的原因和解决方法。 - -## 常见原因 - -将导致该故障最常见的原因放到这个小节中，帮助用户优先排查这些大概率的原因。 - -### 常见原因 1 说明 - -这里简单描述常见原因 1 的背景信息和给系统带来的影响。 - -**现象诊断：** - -这里给出故障诊断信息，如何判断目前的故障是否是由于原因 1 引起的。 - -**解决方案：** - -这里列出由于原因 1 引起的故障对应的解决方案。请根据该方案内容是有无先后顺序，判断使用无序列表或者步骤呈现信息。 - -如果方案内容是一系列的步骤，请使用步骤。例如： - -1. 步骤 1 的内容 -2. 步骤 2 的内容 -3. 步骤 3 的内容 - -解决方案给出后，需要请用户再次检查是否按照上述方案执行后，之前的故障现象会消除。如果仍未解决故障，应该如何处理。 - -### 常见原因 2 说明 - -这里简单描述常见原因 2 的背景信息和给系统带来的影响。 - -**现象诊断：** - -这里给出故障诊断信息，如何判断目前的故障是否是由于原因 2 引起的。 - -**解决方案：** - -这里列出由于原因 2 引起的故障对应的解决方案。请根据该方案内容是有无先后顺序，判断使用无序列表或者步骤呈现信息。 - -如果方案内容是一系列的步骤，请使用步骤。例如： - -1. 步骤 1 的内容 -2. 步骤 2 的内容 -3. 步骤 3 的内容 - -解决方案给出后，需要请用户再次检查是否按照上述方案执行后，之前的故障现象会消除。如果仍未解决故障，应该如何处理。 - -## 其他原因 - -将导致该故障不是特别常见的原因放到这个小节中。 +--- +title: 故障现象（与文档一级标题保持一致） +summary: 介绍 xxx 故障的排查思路、可能的原因和解决方法。 +--- + +# 故障现象（与文首 metadata 中的 title 名称保持一致） + +模版说明： + +- 本文档为故障处理类模板，包含故障诊断和解决方案信息。你可直接复制使用，并删除模板中不需要的说明。该类文档示例：[读写延迟增加](/troubleshoot-cpu-issues.md)。 +- 请在 TOC.md 中合适的位置加目录（思考用户最有可能在哪里找文档）。 +- 文内标题级别不可跳级，尽量避免使用五级标题。 + +本文档介绍 xxx 故障的排查思路、可能的原因和解决方法。 + +## 常见原因 + +将导致该故障最常见的原因放到这个小节中，帮助用户优先排查这些大概率的原因。 + +### 常见原因 1 说明 + +这里简单描述常见原因 1 的背景信息和给系统带来的影响。 + +**现象诊断：** + +这里给出故障诊断信息，如何判断目前的故障是否是由于原因 1 引起的。 + +**解决方案：** + +这里列出由于原因 1 引起的故障对应的解决方案。请根据该方案内容是有无先后顺序，判断使用无序列表或者步骤呈现信息。 + +如果方案内容是一系列的步骤，请使用步骤。例如： + +1. 步骤 1 的内容 +2. 步骤 2 的内容 +3. 步骤 3 的内容 + +解决方案给出后，需要请用户再次检查是否按照上述方案执行后，之前的故障现象会消除。如果仍未解决故障，应该如何处理。 + +### 常见原因 2 说明 + +这里简单描述常见原因 2 的背景信息和给系统带来的影响。 + +**现象诊断：** + +这里给出故障诊断信息，如何判断目前的故障是否是由于原因 2 引起的。 + +**解决方案：** + +这里列出由于原因 2 引起的故障对应的解决方案。请根据该方案内容是有无先后顺序，判断使用无序列表或者步骤呈现信息。 + +如果方案内容是一系列的步骤，请使用步骤。例如： + +1. 步骤 1 的内容 +2. 步骤 2 的内容 +3. 步骤 3 的内容 + +解决方案给出后，需要请用户再次检查是否按照上述方案执行后，之前的故障现象会消除。如果仍未解决故障，应该如何处理。 + +## 其他原因 + +将导致该故障不是特别常见的原因放到这个小节中。 diff --git a/security-compatibility-with-mysql.md b/security-compatibility-with-mysql.md index 44e94d925e0b..05f4387c2530 100644 --- a/security-compatibility-with-mysql.md +++ b/security-compatibility-with-mysql.md @@ -1,6 +1,7 @@ --- title: 与 MySQL 安全特性差异 aliases: ['/docs-cn/dev/security-compatibility-with-mysql/','/docs-cn/dev/reference/security/compatibility/'] +summary: TiDB 支持与 MySQL 5.7 类似的安全特性，同时也支持 MySQL 8.0 的部分安全特性。然而，在实现上存在一些差异，包括不支持列级别权限设置和部分权限属性。此外，TiDB 的密码过期策略和密码复杂度策略与 MySQL 存在一些差异。另外，TiDB 支持多种身份验证方式，包括 TLS 证书和 JWT。 --- # 与 MySQL 安全特性差异 diff --git a/sql-plan-management.md b/sql-plan-management.md index 926b51129934..b62b92dca197 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -1,5 +1,6 @@ --- title: 执行计划管理 (SPM) +summary: 介绍 TiDB 的执行计划管理 (SQL Plan Management) 功能。 aliases: ['/docs-cn/dev/sql-plan-management/','/docs-cn/dev/reference/performance/execution-plan-bind/','/docs-cn/dev/execution-plan-binding/'] --- diff --git a/sql-statements/sql-statement-show-create-database.md b/sql-statements/sql-statement-show-create-database.md index ae86d446672c..85a6c3a23453 100644 --- a/sql-statements/sql-statement-show-create-database.md +++ b/sql-statements/sql-statement-show-create-database.md @@ -1,70 +1,70 @@ ---- -title: SHOW CREATE DATABASE -summary: TiDB 数据库中 SHOW CREATE DATABASE 的使用概况。 ---- - -# SHOW CREATE DATABASE - -`SHOW CREATE DATABASE` 语句用于显示用 SQL 重新创建已有库的确切语句。`SHOW CREATE SCHEMA` 与其同义。 - -## 语法图 - -**ShowCreateDatabaseStmt:** - -```ebnf+diagram -ShowCreateDatabaseStmt ::= - "SHOW" "CREATE" "DATABASE" | "SCHEMA" ("IF" "NOT" "EXISTS")? DBName -``` - -## 示例 - -{{< copyable "sql" >}} - -```sql -CREATE DATABASE test; -``` - -``` -Query OK, 0 rows affected (0.12 sec) -``` - -{{< copyable "sql" >}} - -```sql -SHOW CREATE DATABASE test; -``` - -``` -+----------+------------------------------------------------------------------+ -| Database | Create Database | -+----------+------------------------------------------------------------------+ -| test | CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET utf8mb4 */ | -+----------+------------------------------------------------------------------+ -1 row in set (0.00 sec) -``` - -{{< copyable "sql" >}} - -```sql -SHOW CREATE SCHEMA IF NOT EXISTS test; -``` - -``` -+----------+-------------------------------------------------------------------------------------------+ -| Database | Create Database | -+----------+-------------------------------------------------------------------------------------------+ -| test | CREATE DATABASE /*!32312 IF NOT EXISTS*/ `test` /*!40100 DEFAULT CHARACTER SET utf8mb4 */ | -+----------+-------------------------------------------------------------------------------------------+ -1 row in set (0.00 sec) -``` - -## MySQL 兼容性 - -`SHOW CREATE DATABASE` 语句与 MySQL 完全兼容。如发现任何兼容性差异，请尝试 [TiDB 支持资源](/support.md)。 - -## 另请参阅 - -* [CREATE TABLE](/sql-statements/sql-statement-create-table.md) -* [DROP TABLE](/sql-statements/sql-statement-drop-table.md) -* [SHOW TABLES](/sql-statements/sql-statement-show-tables.md) -* [SHOW COLUMNS FROM](/sql-statements/sql-statement-show-columns-from.md) +--- +title: SHOW CREATE DATABASE +summary: TiDB 数据库中 SHOW CREATE DATABASE 的使用概况。 +--- + +# SHOW CREATE DATABASE + +`SHOW CREATE DATABASE` 语句用于显示用 SQL 重新创建已有库的确切语句。`SHOW CREATE SCHEMA` 与其同义。 + +## 语法图 + +**ShowCreateDatabaseStmt:** + +```ebnf+diagram +ShowCreateDatabaseStmt ::= + "SHOW" "CREATE" "DATABASE" | "SCHEMA" ("IF" "NOT" "EXISTS")? DBName +``` + +## 示例 + +{{< copyable "sql" >}} + +```sql +CREATE DATABASE test; +``` + +``` +Query OK, 0 rows affected (0.12 sec) +``` + +{{< copyable "sql" >}} + +```sql +SHOW CREATE DATABASE test; +``` + +``` ++----------+------------------------------------------------------------------+ +| Database | Create Database | ++----------+------------------------------------------------------------------+ +| test | CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET utf8mb4 */ | ++----------+------------------------------------------------------------------+ +1 row in set (0.00 sec) +``` + +{{< copyable "sql" >}} + +```sql +SHOW CREATE SCHEMA IF NOT EXISTS test; +``` + +``` ++----------+-------------------------------------------------------------------------------------------+ +| Database | Create Database | ++----------+-------------------------------------------------------------------------------------------+ +| test | CREATE DATABASE /*!32312 IF NOT EXISTS*/ `test` /*!40100 DEFAULT CHARACTER SET utf8mb4 */ | ++----------+-------------------------------------------------------------------------------------------+ +1 row in set (0.00 sec) +``` + +## MySQL 兼容性 + +`SHOW CREATE DATABASE` 语句与 MySQL 完全兼容。如发现任何兼容性差异，请尝试 [TiDB 支持资源](/support.md)。 + +## 另请参阅 + +* [CREATE TABLE](/sql-statements/sql-statement-create-table.md) +* [DROP TABLE](/sql-statements/sql-statement-drop-table.md) +* [SHOW TABLES](/sql-statements/sql-statement-show-tables.md) +* [SHOW COLUMNS FROM](/sql-statements/sql-statement-show-columns-from.md) diff --git a/statistics.md b/statistics.md index d6c5a3de9a53..62b01f68a3ca 100644 --- a/statistics.md +++ b/statistics.md @@ -1,5 +1,6 @@ --- title: 统计信息简介 +summary: 介绍 TiDB 中统计信息的收集和使用。 aliases: ['/docs-cn/dev/statistics/','/docs-cn/dev/reference/performance/statistics/'] --- diff --git a/system-variables.md b/system-variables.md index fc75d0eccd56..ea08830d9150 100644 --- a/system-variables.md +++ b/system-variables.md @@ -1,5 +1,6 @@ --- title: 系统变量 +summary: 使用 TiDB 系统变量来优化性能或修改运行行为。 aliases: ['/docs-cn/dev/system-variables/','/docs-cn/dev/reference/configuration/tidb-server/mysql-variables/','/docs-cn/dev/tidb-specific-system-variables/','/docs-cn/dev/reference/configuration/tidb-server/tidb-specific-variables/','/zh/tidb/dev/tidb-specific-system-variables/'] --- diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index 145cf4c98726..022188549396 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -1,5 +1,6 @@ --- title: TiDB 配置文件描述 +summary: 介绍未包含在命令行参数中的 TiDB 配置文件选项。 aliases: ['/docs-cn/dev/tidb-configuration-file/','/docs-cn/dev/reference/configuration/tidb-server/configuration-file/'] --- diff --git a/tidb-limitations.md b/tidb-limitations.md index 431916643ab1..39021435d3da 100644 --- a/tidb-limitations.md +++ b/tidb-limitations.md @@ -1,74 +1,75 @@ ---- -title: TiDB 使用限制 -aliases: ['/docs-cn/dev/tidb-limitations/'] ---- - -# 使用限制 - -本文会将详细描述 TiDB 中常见的使用限制，包括：标识符长度，最大支持的数据库、表、索引、分区表、序列等的个数。 - -## 标识符长度限制 - -| 标识符类型 | 最大长度（字符）| -|:---------|:--------------| -| Database | 64 | -| Table | 64 | -| Column | 64 | -| Index | 64 | -| View | 64 | -| Sequence | 64 | - -## Databases、Tables、Views、Connections 总个数限制 - -| 类型 | 最大个数 | -|:----------|:----------| -| Databases | unlimited | -| Tables | unlimited | -| Views | unlimited | -| Connections| unlimited| - -## 单个 Database 的限制 - -| 类型 | 最大限制 | -|:----------|:----------| -| Tables |unlimited | - -## 单个 Table 的限制 - -| 类型 | 最大限制（默认值） | -|:----------|:------------------------------| -| Columns | 默认为 1017，最大可调至 4096 | -| Indexes | 默认为 64，最大可调至 512 | -| Rows | 无限制 | -| Size | 无限制 | -| Partitions| 8192 | - -* Columns 的最大限制可通过 [`table-column-count-limit`](/tidb-configuration-file.md#table-column-count-limit-从-v50-版本开始引入) 修改。 -* Indexes 的最大限制可通过 [`index-limit`](/tidb-configuration-file.md#index-limit-从-v50-版本开始引入) 修改。 - -## 单行的限制 - -| 类型 | 最大限制（默认值） | -|:----------|:----------| -| Size | 默认为 6 MiB，可通过 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-从-v50-版本开始引入) 配置项调至 120 MiB | - -## 数据类型限制 - -| 类型 | 最大限制 | -|:----------|:----------| -| CHAR | 256 字符 | -| BINARY | 256 字节 | -| VARBINARY | 65535 字节 | -| VARCHAR | 16383 字符 | -| TEXT | 默认为 6291456 字节（即 6 MiB），可调至 125829120 字节（即 120 MiB） | -| BLOB | 默认为 6291456 字节（即 6 MiB），可调至 125829120 字节（即 120 MiB） | - -## SQL Statements 的限制 - -| 类型 | 最大限制 | -|:----------|:----------| -| 单个事务最大语句数 | 在使用乐观事务并开启事务重试的情况下，默认限制 5000，可通过 [`stmt-count-limit`](/tidb-configuration-file.md#stmt-count-limit) 调整 | - -## TiKV 版本的限制 - -在集群中，如果 TiDB 组件的版本为 v6.2.0 及以上，则 TiKV 组件版本不得低于 v6.2.0。 +--- +title: TiDB 使用限制 +aliases: ['/docs-cn/dev/tidb-limitations/'] +summary: TiDB 中的使用限制包括标识符长度限制、数据库、表、视图、连接总个数限制、单个数据库和表的限制、单行限制、数据类型限制、SQL 语句限制和 TiKV 版本限制。 +--- + +# 使用限制 + +本文会将详细描述 TiDB 中常见的使用限制，包括：标识符长度，最大支持的数据库、表、索引、分区表、序列等的个数。 + +## 标识符长度限制 + +| 标识符类型 | 最大长度（字符）| +|:---------|:--------------| +| Database | 64 | +| Table | 64 | +| Column | 64 | +| Index | 64 | +| View | 64 | +| Sequence | 64 | + +## Databases、Tables、Views、Connections 总个数限制 + +| 类型 | 最大个数 | +|:----------|:----------| +| Databases | unlimited | +| Tables | unlimited | +| Views | unlimited | +| Connections| unlimited| + +## 单个 Database 的限制 + +| 类型 | 最大限制 | +|:----------|:----------| +| Tables |unlimited | + +## 单个 Table 的限制 + +| 类型 | 最大限制（默认值） | +|:----------|:------------------------------| +| Columns | 默认为 1017，最大可调至 4096 | +| Indexes | 默认为 64，最大可调至 512 | +| Rows | 无限制 | +| Size | 无限制 | +| Partitions| 8192 | + +* Columns 的最大限制可通过 [`table-column-count-limit`](/tidb-configuration-file.md#table-column-count-limit-从-v50-版本开始引入) 修改。 +* Indexes 的最大限制可通过 [`index-limit`](/tidb-configuration-file.md#index-limit-从-v50-版本开始引入) 修改。 + +## 单行的限制 + +| 类型 | 最大限制（默认值） | +|:----------|:----------| +| Size | 默认为 6 MiB，可通过 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-从-v50-版本开始引入) 配置项调至 120 MiB | + +## 数据类型限制 + +| 类型 | 最大限制 | +|:----------|:----------| +| CHAR | 256 字符 | +| BINARY | 256 字节 | +| VARBINARY | 65535 字节 | +| VARCHAR | 16383 字符 | +| TEXT | 默认为 6291456 字节（即 6 MiB），可调至 125829120 字节（即 120 MiB） | +| BLOB | 默认为 6291456 字节（即 6 MiB），可调至 125829120 字节（即 120 MiB） | + +## SQL Statements 的限制 + +| 类型 | 最大限制 | +|:----------|:----------| +| 单个事务最大语句数 | 在使用乐观事务并开启事务重试的情况下，默认限制 5000，可通过 [`stmt-count-limit`](/tidb-configuration-file.md#stmt-count-limit) 调整 | + +## TiKV 版本的限制 + +在集群中，如果 TiDB 组件的版本为 v6.2.0 及以上，则 TiKV 组件版本不得低于 v6.2.0。 diff --git a/tikv-control.md b/tikv-control.md index cb31d92f2275..da4c5ef07bca 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -1,6 +1,7 @@ --- title: TiKV Control 使用说明 aliases: ['/docs-cn/dev/tikv-control/','/docs-cn/dev/reference/tools/tikv-control/'] +summary: TiKV Control（tikv-ctl）是 TiKV 的命令行工具，用于管理 TiKV 集群。它的安装目录在 `~/.tiup/components/ctl/{VERSION}/` 目录下。通过 TiUP 使用 TiKV Control，可以调用 `tikv-ctl` 工具。通用参数包括远程模式和本地模式，以及两个简单的命令 `--to-hex` 和 `--to-escaped`。其他子命令包括查看 Raft 状态机的信息、查看 Region 的大小、扫描查看给定范围的 MVCC、查看给定 key 的 MVCC、扫描 raw key、打印某个 key 的值、打印 Region 的 properties 信息、手动 compact 单个 TiKV 的数据、手动 compact 整个 TiKV 集群的数据、设置一个 Region 副本为 tombstone 状态、向 TiKV 发出 consistency-check 请求、Dump snapshot 元文件、打印 Raft 状态机出错的 Region、动态修改 TiKV 的配置、强制 Region 从多副本失败状态恢复服务、恢复损坏的 MVCC 数据、Ldb 命令、打印加密元数据、打印损坏的 SST 文件信息、获取一个 Region 的 RegionReadProgress 状态。 --- # TiKV Control 使用说明 diff --git a/tiup/tiup-bench.md b/tiup/tiup-bench.md index 12d7738be6a2..bcded2e30a76 100644 --- a/tiup/tiup-bench.md +++ b/tiup/tiup-bench.md @@ -1,6 +1,7 @@ --- title: 使用 TiUP bench 组件压测 TiDB aliases: ['/docs-cn/dev/tiup/tiup-bench/','/docs-cn/dev/reference/tools/tiup/bench/'] +summary: TiUP bench 组件集成了多种压测 workloads，包括 TPC-C、TPC-H、CH-benCHmark、YCSB 和自定义 SQL 文件。每种压测都有对应的命令和参数，可以通过 TiUP 运行。TPC-C 测试包括准备数据、运行测试、检查一致性和清理数据等步骤。TPC-H 测试也有类似的步骤，包括准备数据、运行测试和清理数据。YCSB 测试可以分别针对 TiDB 和 TiKV 节点进行，包括准备数据和运行测试。此外，还可以通过 RawSQL 文件进行测试，包括准备数据和执行查询。 --- # 使用 TiUP bench 组件压测 TiDB diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index d4919b8afab5..ef291b8b1b49 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -1,5 +1,6 @@ --- title: 通过 TiUP 部署 TiDB 集群的拓扑文件配置 +summary: 介绍通过 TiUP 部署或扩容 TiDB 集群时提供的拓扑文件配置和示例。 --- # 通过 TiUP 部署 TiDB 集群的拓扑文件配置 diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md index 57375fb08b3e..2dcf7748fcce 100644 --- a/tiup/tiup-cluster.md +++ b/tiup/tiup-cluster.md @@ -1,6 +1,7 @@ --- title: 使用 TiUP 部署运维 TiDB 线上集群 aliases: ['/docs-cn/dev/tiup/tiup-cluster/','/docs-cn/dev/reference/tools/tiup/cluster/'] +summary: 使用 TiUP 的 cluster 组件可以快速部署生产集群，并提供强大的生产集群管理功能，包括升级、缩容、扩容、操作、审计等。部署集群的命令为 tiup cluster deploy，部署完成后可以通过 tiup cluster list 查看集群列表。启动集群的命令为 tiup cluster start，查看集群状态的命令为 tiup cluster display。可以使用 tiup cluster scale-in 进行集群缩容，tiup cluster scale-out 进行集群扩容。另外，还可以使用 tiup cluster upgrade 进行滚动升级，使用 tiup cluster edit-config 进行配置更新。最后，可以使用 tiup cluster exec 在集群节点机器上执行命令。 --- # 使用 TiUP 部署运维 TiDB 线上集群 diff --git a/tiup/tiup-command-clean.md b/tiup/tiup-command-clean.md index 2017507274bc..13b613a8d194 100644 --- a/tiup/tiup-command-clean.md +++ b/tiup/tiup-command-clean.md @@ -1,5 +1,6 @@ --- title: tiup clean +summary: tiup clean 命令用于清除组件运行过程中产生的数据。可以使用 --all 选项清除所有运行记录。 --- # tiup clean diff --git a/tiup/tiup-command-completion.md b/tiup/tiup-command-completion.md index d42b42d730cd..fefbae63bd4d 100644 --- a/tiup/tiup-command-completion.md +++ b/tiup/tiup-command-completion.md @@ -1,5 +1,6 @@ --- title: tiup completion +summary: TiUP 提供了 `tiup completion` 命令，用于生成命令行自动补全的配置文件。目前支持 `bash` 和 `zsh` 两种 shell 的命令补全。安装方式包括在 macOS 上执行 `brew install bash-completion` 或 `brew install bash-completion@2`，在 Linux 上执行 `yum install bash-completion` 或 `apt install bash-completion`。使用方式包括在 `.bash_profile` 中执行 `source` 命令，并在 zsh 中执行 `tiup completion zsh > "${fpath[1]}/_tiup"`。 --- # tiup completion diff --git a/tiup/tiup-command-env.md b/tiup/tiup-command-env.md index 92cae5f1f45a..078c672270e8 100644 --- a/tiup/tiup-command-env.md +++ b/tiup/tiup-command-env.md @@ -1,5 +1,6 @@ --- title: tiup env +summary: TiUP 提供灵活的定制化接口，使用环境变量实现。命令 `tiup env` 用于查询 TiUP 支持的用户自定义环境变量及其值。若未指定环境变量，则输出"{key}"="{value}"列表。若指定了环境变量，则按顺序输出"{value}"列表。若值为空，则代表未设置环境变量的值，TiUP 会使用默认值。 --- # tiup env diff --git a/tiup/tiup-command-help.md b/tiup/tiup-command-help.md index 57aa690ab580..70253671d9ff 100644 --- a/tiup/tiup-command-help.md +++ b/tiup/tiup-command-help.md @@ -1,5 +1,6 @@ --- title: tiup help +summary: TiUP 命令行界面提供丰富的帮助信息，用户可通过 `help` 命令或 `--help` 参数查看。`tiup help ` 等同于 `tiup --help`。语法为 `tiup help [command]`，若不指定命令，则查看 TiUP 自身的帮助信息。选项为无，输出为 `[command]` 或 TiUP 的帮助信息。 --- # tiup help diff --git a/tiup/tiup-command-install.md b/tiup/tiup-command-install.md index 10b705b63dfe..5ee428f1c59c 100644 --- a/tiup/tiup-command-install.md +++ b/tiup/tiup-command-install.md @@ -1,5 +1,6 @@ --- title: tiup install +summary: tiup install 命令用于从镜像仓库下载指定版本的组件包，并在本地解压。当需要运行不存在于镜像仓库中的组件时，会尝试下载并自动运行，若不存在会报错。语法为 tiup install [version] [component2...N] [flags]。输出包括组件的下载信息，若组件不存在则报错"The component "%s" not found"，若版本不存在则报错"version %s not supported by component %s"。 --- # tiup install diff --git a/tiup/tiup-command-list.md b/tiup/tiup-command-list.md index 915ec439c2d4..fc4faff069d8 100644 --- a/tiup/tiup-command-list.md +++ b/tiup/tiup-command-list.md @@ -1,5 +1,6 @@ --- title: tiup list +summary: tiup list 命令用于查询镜像中可用的组件列表。可选的组件名称。若指定，则列出该组件的所有版本；若不指定，则列出所有组件列表。--all 显示所有组件。默认只显示非隐藏组件。--installed 只显示已经安装的组件或版本。--verbose 在组件列表中显示已安装的版本列表。若未指定组件名，输出组件名、组件管理员、组件描述构成的组件信息列表。若指定组件名，输出版本、是否已安装、发布时间、支持的平台构成的版本信息列表。 --- # tiup list diff --git a/tiup/tiup-command-mirror-clone.md b/tiup/tiup-command-mirror-clone.md index fbf5cf98be51..cc9d9051a4ee 100644 --- a/tiup/tiup-command-mirror-clone.md +++ b/tiup/tiup-command-mirror-clone.md @@ -1,5 +1,6 @@ --- title: tiup mirror clone +summary: tiup mirror clone 命令用于克隆已存在的镜像或部分组件生成新镜像。新旧镜像的组件相同，但使用的签名密钥不同。命令语法为 tiup mirror clone [global version] [flags]。选项包括 -f, --full, -a, --arch, -o, --os, --prefix, --{component}。 --- # tiup mirror clone diff --git a/tiup/tiup-command-mirror-grant.md b/tiup/tiup-command-mirror-grant.md index b30042f37c78..ce7ccb288e35 100644 --- a/tiup/tiup-command-mirror-grant.md +++ b/tiup/tiup-command-mirror-grant.md @@ -1,5 +1,6 @@ --- title: tiup mirror grant +summary: tiup mirror grant 命令用于向当前镜像中添加组件管理员。组件管理员可以发布新组件或修改之前发布的组件。添加管理员时，需将公钥发送给镜像管理员。命令仅支持本地镜像使用。语法：tiup mirror grant 。选项：-k, --key（指定管理员密钥）、-n, --name（指定管理员名字）。输出：执行成功无输出，管理员 ID 重复报错，密钥被其他管理员使用报错。 --- # tiup mirror grant diff --git a/tiup/tiup-command-mirror-init.md b/tiup/tiup-command-mirror-init.md index ffe605d3d395..1453755b68d7 100644 --- a/tiup/tiup-command-mirror-init.md +++ b/tiup/tiup-command-mirror-init.md @@ -1,5 +1,6 @@ --- title: tiup mirror init +summary: tiup mirror init 命令用于初始化一个空的镜像。初始化的镜像不包含任何组件和组件管理员，仅生成一些文件。语法为 tiup mirror init [flags]，其中 为本地目录路径，可以为相对路径。选项包括 -k, --key-dir（string，默认 {path}/keys）。输出包括若成功则无输出，若 不为空则输出错误信息，若 不是目录则输出错误信息。 --- # tiup mirror init diff --git a/tiup/tiup-command-mirror-merge.md b/tiup/tiup-command-mirror-merge.md index 0fde825d8655..2c60a4a98ddd 100644 --- a/tiup/tiup-command-mirror-merge.md +++ b/tiup/tiup-command-mirror-merge.md @@ -1,5 +1,6 @@ --- title: tiup mirror merge +summary: tiup mirror merge 命令用于将一个或多个镜像合并到当前镜像。执行此命令需要目标镜像的管理员 ID 在当前镜像中存在，并且用户的 ${TIUP_HOME}/keys 目录中有对应的私钥。语法：tiup mirror merge [mirror-dir-N]。选项：无。输出：成功时无输出，否则会提示缺失管理员或私钥。 --- # tiup mirror merge diff --git a/tiup/tiup-command-mirror-modify.md b/tiup/tiup-command-mirror-modify.md index ca3635494a59..2fc686a0e681 100644 --- a/tiup/tiup-command-mirror-modify.md +++ b/tiup/tiup-command-mirror-modify.md @@ -1,5 +1,6 @@ --- title: tiup mirror modify +summary: tiup mirror modify 命令用于修改已发布的组件。只有合法的组件管理员才能修改组件，且只能修改自己发布的组件。命令语法为 tiup mirror modify [version]。选项包括 -k, --key, --yank, --hide。成功时无输出，无权限时会有相应错误提示。 --- # tiup mirror modify diff --git a/tiup/tiup-command-mirror-publish.md b/tiup/tiup-command-mirror-publish.md index c165fab28838..e9883217595c 100644 --- a/tiup/tiup-command-mirror-publish.md +++ b/tiup/tiup-command-mirror-publish.md @@ -1,5 +1,6 @@ --- title: tiup mirror publish +summary: tiup mirror publish 命令用于发布新组件或已有组件的新版本。只有有权限的组件管理员才可以发布组件。命令语法为 tiup mirror publish [flags]。其中各参数含义为组件名、版本号、tarball 包路径、组件可执行文件位置。命令还包含选项 -k, --key, --arch, --os, --desc, --hide。成功时无输出，无权限时会有相应错误提示。 --- # tiup mirror publish diff --git a/tiup/tiup-command-mirror-rotate.md b/tiup/tiup-command-mirror-rotate.md index 6952fb3c27ea..0ec73b5ca919 100644 --- a/tiup/tiup-command-mirror-rotate.md +++ b/tiup/tiup-command-mirror-rotate.md @@ -1,5 +1,6 @@ --- title: tiup mirror rotate +summary: TiUP 的镜像中有一个重要文件 root.json，记录了系统需要使用的公钥和信任链基础。包含管理员签名、用于验证的公钥和过期时间。更新 root.json 需要管理员重新签名，使用命令 `tiup mirror rotate` 自动化更新流程。需要确保 TiUP 客户端升级到 v1.5.0 或以上版本。命令启动编辑器修改内容，等待管理员签名。选项包括临时服务器监听地址。输出为各个镜像管理员当前的签名状态。 --- # tiup mirror rotate diff --git a/tiup/tiup-command-mirror-set.md b/tiup/tiup-command-mirror-set.md index 6624d193da46..029e8c696112 100644 --- a/tiup/tiup-command-mirror-set.md +++ b/tiup/tiup-command-mirror-set.md @@ -1,5 +1,6 @@ --- title: tiup mirror set +summary: tiup mirror set 命令用于切换当前镜像，支持本地文件系统和远程网络两种镜像。命令语法为 tiup mirror set [flags]，其中 为镜像地址，可以是网络地址或本地文件路径。选项 -r, --root 用于指定根证书。输出为无。 --- # tiup mirror set diff --git a/tiup/tiup-command-mirror-sign.md b/tiup/tiup-command-mirror-sign.md index 9e6719165296..1fec8b47b943 100644 --- a/tiup/tiup-command-mirror-sign.md +++ b/tiup/tiup-command-mirror-sign.md @@ -1,5 +1,6 @@ --- title: tiup mirror sign +summary: tiup mirror sign 命令用于对镜像中定义的元信息文件进行签名。语法为 tiup mirror sign 。选项包括 -k, --key 和 --timeout。输出包括成功、文件已被指定的 key 签名过和文件不是合法的 manifest。 --- # tiup mirror sign diff --git a/tiup/tiup-command-mirror.md b/tiup/tiup-command-mirror.md index 25510921eeaf..f873e4ec1433 100644 --- a/tiup/tiup-command-mirror.md +++ b/tiup/tiup-command-mirror.md @@ -1,5 +1,6 @@ --- title: tiup mirror +summary: TiUP 中的镜像是一个重要概念，支持本地镜像和远程镜像。命令 `tiup mirror` 用于管理镜像，包括创建、发布、密钥管理等功能。语法为 `tiup mirror [flags]`，支持的子命令包括 genkey、sign、init、set、grant、publish、modify、rotate、clone、merge。详细信息请参考 TiUP 命令清单。 --- # tiup mirror diff --git a/tiup/tiup-command-status.md b/tiup/tiup-command-status.md index 8b32393226d3..dc080c928f11 100644 --- a/tiup/tiup-command-status.md +++ b/tiup/tiup-command-status.md @@ -1,5 +1,6 @@ --- title: tiup status +summary: tiup status 命令用于查看组件的运行信息，包括组件名称、进程 ID、运行状态、启动时间、数据目录、二进制文件路径和启动参数。组件可能处于在线、离线、无法访问、已缩容下线、下线中或未知状态。这些状态来自于 PD 的调度信息。 --- # tiup status diff --git a/tiup/tiup-command-telemetry.md b/tiup/tiup-command-telemetry.md index 2f4a3ea48bc8..b82d15cee570 100644 --- a/tiup/tiup-command-telemetry.md +++ b/tiup/tiup-command-telemetry.md @@ -1,5 +1,6 @@ --- title: tiup telemetry +summary: TiUP 遥测功能在 v1.11.3 及以上版本默认关闭，以下版本默认开启。开启后会分享使用情况信息给 PingCAP，包括遥测标示符、命令执行情况、部署情况等。不会分享集群准确名字、拓扑结构、配置文件。使用命令 `tiup telemetry` 控制遥测，支持 status、reset、enable、disable 命令。 --- # tiup telemetry diff --git a/tiup/tiup-command-uninstall.md b/tiup/tiup-command-uninstall.md index a373a1615612..3622de517d16 100644 --- a/tiup/tiup-command-uninstall.md +++ b/tiup/tiup-command-uninstall.md @@ -1,5 +1,6 @@ --- title: tiup uninstall +summary: tiup uninstall 命令用于卸载已安装的组件。语法为 tiup uninstall [component2...N] [flags]。选项包括 --all 用于卸载指定组件的全部已安装版本，--self 用于卸载 TiUP 自身。正常退出时会显示"Uninstalled component "%s" successfully!"，若未指定 也未指定 --all 则会报错"Use "tiup uninstall tidbx --all" if you want to remove all versions."。 --- # tiup uninstall diff --git a/tiup/tiup-command-update.md b/tiup/tiup-command-update.md index b87656d4e0ea..3b3b6140fc9e 100644 --- a/tiup/tiup-command-update.md +++ b/tiup/tiup-command-update.md @@ -1,5 +1,6 @@ --- title: tiup update +summary: tiup update 命令用于升级已安装的组件或自身。语法为 tiup update [组件名] [版本]，可指定多个组件或版本。选项包括 --all（升级所有组件）、--force（强制升级已安装版本）、--nightly（升级到 nightly 版本）、--self（升级 TiUP 自身）。 --- # tiup update diff --git a/tiup/tiup-component-cluster-audit-cleanup.md b/tiup/tiup-component-cluster-audit-cleanup.md index ed439c8c6602..7c8d9f5331f5 100644 --- a/tiup/tiup-component-cluster-audit-cleanup.md +++ b/tiup/tiup-component-cluster-audit-cleanup.md @@ -1,5 +1,6 @@ --- title: tiup cluster audit cleanup +summary: tiup cluster audit cleanup 命令用于清理 tiup cluster 产生的执行日志。--retain-days 选项用于设置执行日志保留天数，默认值为 60 天。-h, --help 选项用于输出帮助信息。执行命令后会输出 "clean audit log successfully"。 --- # tiup cluster audit cleanup diff --git a/tiup/tiup-component-cluster-audit.md b/tiup/tiup-component-cluster-audit.md index d946d76f2657..b7d4e6ce906d 100644 --- a/tiup/tiup-component-cluster-audit.md +++ b/tiup/tiup-component-cluster-audit.md @@ -1,5 +1,6 @@ --- title: tiup cluster audit +summary: tiup cluster audit 命令用于查看集群执行的历史命令和执行日志。若不填写 audit-id，则按时间倒序输出操作记录表格，包括 audit-id、命令执行时间和命令。若填写 audit-id，则查看指定的执行日志。选项 -h, --help 用于输出帮助信息。输出包括指定的执行日志或包含 ID、时间和命令的表格。 --- # tiup cluster audit diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index 437cce99233f..ebbf31235f59 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -1,5 +1,6 @@ --- title: tiup cluster check +summary: TiUP Cluster 提供了 `check` 子命令，用于检查集群的硬件和软件环境是否满足正常运行条件。检查包括操作系统版本、CPU 支持、系统时间、内核参数、磁盘挂载参数等。用户可以通过指定选项来启用 CPU 核心数、内存大小和磁盘性能测试的检查。检查结果将以表格形式输出，包括目标节点、检查项、检查结果和结果描述。 --- # tiup cluster check diff --git a/tiup/tiup-component-cluster-clean.md b/tiup/tiup-component-cluster-clean.md index eea36da62198..f259a73694b5 100644 --- a/tiup/tiup-component-cluster-clean.md +++ b/tiup/tiup-component-cluster-clean.md @@ -1,5 +1,6 @@ --- title: tiup cluster clean +summary: tiup cluster clean 命令用于在测试环境中重置集群到刚部署的状态。它会停止集群并删除数据。警告：生产环境禁止使用。语法：tiup cluster clean 。选项包括 --all（清理数据和日志）、--data（开启数据清理）、--log（开启日志清理）、--ignore-node（指定不清理的节点）、--ignore-role（指定不清理的角色）、-h, --help（输出帮助信息）。输出为 tiup-cluster 的执行日志。 --- # tiup cluster clean diff --git a/tiup/tiup-component-cluster-deploy.md b/tiup/tiup-component-cluster-deploy.md index 92ee66c05f3f..26b3e880908e 100644 --- a/tiup/tiup-component-cluster-deploy.md +++ b/tiup/tiup-component-cluster-deploy.md @@ -1,5 +1,6 @@ --- title: tiup cluster deploy +summary: tiup cluster deploy 命令用于部署全新集群。语法为 tiup cluster deploy [flags]。选项包括 -u, -i, -p, --ignore-config-check, --no-labels, --skip-create-user, -h。输出为部署日志。 --- # tiup cluster deploy diff --git a/tiup/tiup-component-cluster-destroy.md b/tiup/tiup-component-cluster-destroy.md index e46c35c8a921..8d4b2922004f 100644 --- a/tiup/tiup-component-cluster-destroy.md +++ b/tiup/tiup-component-cluster-destroy.md @@ -1,5 +1,6 @@ --- title: tiup cluster destroy +summary: tiup cluster destroy 命令用于销毁集群，包括停止集群、删除服务的日志目录、部署目录和数据目录。选项包括 --force（忽略错误）、--retain-node-data（指定保留数据的节点）、--retain-role-data（指定保留数据的角色）、-h（输出帮助信息）。执行日志将作为输出。 --- # tiup cluster destroy diff --git a/tiup/tiup-component-cluster-disable.md b/tiup/tiup-component-cluster-disable.md index 12581aae414c..a3afb2fe31ca 100644 --- a/tiup/tiup-component-cluster-disable.md +++ b/tiup/tiup-component-cluster-disable.md @@ -1,5 +1,6 @@ --- title: tiup cluster disable +summary: tiup cluster disable 命令用于关闭集群服务在机器重启后的自启动。使用该命令可以指定要关闭自启的集群、节点和角色。如果不指定节点和角色，则默认关闭所有节点和角色的自启动。输出为 tiup-cluster 的执行日志。 --- # tiup cluster disable diff --git a/tiup/tiup-component-cluster-display.md b/tiup/tiup-component-cluster-display.md index f99af3b66079..a300c0eb309a 100644 --- a/tiup/tiup-component-cluster-display.md +++ b/tiup/tiup-component-cluster-display.md @@ -1,5 +1,6 @@ --- title: tiup cluster display +summary: tiup cluster display 命令用于查看集群中每个组件的运行状态。可以通过指定选项来展示特定信息，如节点的 CPU 和内存使用情况，节点的 uptime 信息等。输出包括集群名称、版本、SSH 客户端类型、Dashboard 地址以及节点的 ID、角色、主机 IP、端口号、操作系统和机器架构、服务状态、数据目录和部署目录。节点服务状态包括在线、离线、已缩容下线、下线中和未知。详细状态含义可参考相关文档。 --- # tiup cluster display diff --git a/tiup/tiup-component-cluster-edit-config.md b/tiup/tiup-component-cluster-edit-config.md index 2991be6df1ba..d533d452f8f2 100644 --- a/tiup/tiup-component-cluster-edit-config.md +++ b/tiup/tiup-component-cluster-edit-config.md @@ -1,5 +1,6 @@ --- title: tiup cluster edit-config +summary: tiup cluster edit-config 命令用于调整部署集群后的配置。执行命令后会启动一个编辑器，允许用户修改指定集群的拓扑文件。注意不能增删机器，需执行 tiup cluster reload 命令来重新加载配置。语法为 tiup cluster edit-config ，选项包括 -h, --help。执行命令后正常情况下无输出，若修改了不能修改的字段则会报错并提示用户重新编辑。 --- # tiup cluster edit-config diff --git a/tiup/tiup-component-cluster-enable.md b/tiup/tiup-component-cluster-enable.md index 330dd283ecf9..9f04c5ab7757 100644 --- a/tiup/tiup-component-cluster-enable.md +++ b/tiup/tiup-component-cluster-enable.md @@ -1,5 +1,6 @@ --- title: tiup cluster enable +summary: tiup cluster enable 命令用于设置集群服务在机器重启后的自启动。命令会执行 systemctl enable 来开启服务的自启。可以指定节点和角色来开启自启，同时可以输出帮助信息。执行日志将由 tiup-cluster 记录。 --- # tiup cluster enable diff --git a/tiup/tiup-component-cluster-help.md b/tiup/tiup-component-cluster-help.md index 324b3a8f2111..d08def2f7a4b 100644 --- a/tiup/tiup-component-cluster-help.md +++ b/tiup/tiup-component-cluster-help.md @@ -1,5 +1,6 @@ --- title: tiup cluster help +summary: tiup-cluster 是一个命令行工具，提供丰富的帮助信息。用户可以通过 `help` 命令或 `--help` 参数获取帮助信息。`tiup cluster help ` 等同于 `tiup cluster --help`。语法为 `tiup cluster help [command] [flags]`。使用 `-h` 或 `--help` 输出帮助信息，默认关闭。输出为 `[command]` 或 tiup-cluster 的帮助信息。 --- # tiup cluster help diff --git a/tiup/tiup-component-cluster-import.md b/tiup/tiup-component-cluster-import.md index d69348ca592c..e50268a12e25 100644 --- a/tiup/tiup-component-cluster-import.md +++ b/tiup/tiup-component-cluster-import.md @@ -1,5 +1,6 @@ --- title: tiup cluster import +summary: TiUP Cluster 提供了 `import` 命令，用于将 TiDB Ansible 部署的集群过渡到使用 tiup-cluster 组件管理。导入过程的日志信息将会输出。暂不支持导入启用了 TLS 加密功能、纯 KV 集群、启用了 Kafka 的集群、启用了 Spark 的集群、启用了 TiDB Lightning/Importer 的集群、仍使用老版本 `push` 的方式收集监控指标、单独为机器的 `node_exporter` / `blackbox_exporter` 设置了非默认端口的集群。如果集群中有部分节点未部署监控，应当先补充对应节点的信息，并将补充的监控组件部署完整。 --- # tiup cluster import diff --git a/tiup/tiup-component-cluster-list.md b/tiup/tiup-component-cluster-list.md index 05faaf6fcd93..707ab5215aa8 100644 --- a/tiup/tiup-component-cluster-list.md +++ b/tiup/tiup-component-cluster-list.md @@ -1,5 +1,6 @@ --- title: tiup cluster list +summary: tiup-cluster 支持使用同一个中控机部署多套集群。命令 `tiup cluster list` 可以查看当前登录的用户使用该中控机部署了哪些集群。输出包含 Name、User、Version、Path、PrivateKey 字段的表格。注意：部署的集群数据默认放在 `~/.tiup/storage/cluster/clusters/` 目录下，当前登录用户无法查看其他用户部署的集群。 --- # tiup cluster list diff --git a/tiup/tiup-component-cluster-meta-backup.md b/tiup/tiup-component-cluster-meta-backup.md index 5f9d4a7c168a..59b59df1b2af 100644 --- a/tiup/tiup-component-cluster-meta-backup.md +++ b/tiup/tiup-component-cluster-meta-backup.md @@ -1,5 +1,6 @@ --- title: tiup cluster meta backup +summary: TiUP meta 文件丢失会导致无法管理集群。使用“tiup cluster meta backup”命令定期备份文件。命令语法为“tiup cluster meta backup ”。选项包括指定备份文件存储目录和帮助信息。输出为 tiup-cluster 的执行日志。 --- # tiup cluster meta backup diff --git a/tiup/tiup-component-cluster-meta-restore.md b/tiup/tiup-component-cluster-meta-restore.md index 1aaf32a56528..c029c0abfac2 100644 --- a/tiup/tiup-component-cluster-meta-restore.md +++ b/tiup/tiup-component-cluster-meta-restore.md @@ -1,5 +1,6 @@ --- title: tiup cluster meta restore +summary: TiUP cluster meta restore 命令用于从备份文件中恢复 TiUP meta 文件。语法为 tiup cluster meta restore 。选项包括 -h, --help，用于输出帮助信息。恢复操作会覆盖当前的 meta 文件，建议仅在 meta 文件丢失的情况下进行恢复。执行日志将作为输出。 --- # tiup cluster meta restore diff --git a/tiup/tiup-component-cluster-patch.md b/tiup/tiup-component-cluster-patch.md index a2a6f502daa1..0044d3104b74 100644 --- a/tiup/tiup-component-cluster-patch.md +++ b/tiup/tiup-component-cluster-patch.md @@ -1,5 +1,6 @@ --- title: tiup cluster patch +summary: tiup cluster patch 命令用于在集群运行过程中动态替换某个服务的二进制文件。它会上传替换的二进制包到目标机器，并通过 API 下线节点，停止目标服务，解压替换二进制包，最后启动目标服务。在使用命令前需要准备二进制包，包括确定组件名、版本、操作系统和平台，下载组件包，创建临时打包目录，解压原二进制包，复制要替换的文件到临时目录，最后打包所有文件。命令还包括一些选项，如 --overwrite、--transfer-timeout、-N、-R、--offline 等。 --- # tiup cluster patch diff --git a/tiup/tiup-component-cluster-prune.md b/tiup/tiup-component-cluster-prune.md index 53bab15cf001..df624222a8c8 100644 --- a/tiup/tiup-component-cluster-prune.md +++ b/tiup/tiup-component-cluster-prune.md @@ -1,5 +1,6 @@ --- title: tiup cluster prune +summary: tiup cluster prune 命令用于在缩容集群时清理数据。对于某些组件，需要等数据调度完成后，用户手动执行该命令。选项包括 -h 或 --help，用于输出帮助信息。清理过程会生成日志。 --- # tiup cluster prune diff --git a/tiup/tiup-component-cluster-reload.md b/tiup/tiup-component-cluster-reload.md index 7b8652eaa3ae..4c11f7cd21ce 100644 --- a/tiup/tiup-component-cluster-reload.md +++ b/tiup/tiup-component-cluster-reload.md @@ -1,5 +1,6 @@ --- title: tiup cluster reload +summary: tiup cluster reload 命令用于在修改集群配置后重新加载配置，使其生效。命令会将配置发布到远端机器，并按顺序重启服务，重启过程中集群可用。可选参数包括 --force（忽略错误强制 reload）、--transfer-timeout（设置最长等待时间）、--ignore-config-check（跳过配置检查）、-N, --node（指定要重启的节点）、-R, --role（指定要重启的角色）、--skip-restart（仅刷新配置不重启节点）、-h, --help（输出帮助信息）。执行日志会输出到 tiup-cluster。 --- # tiup cluster reload diff --git a/tiup/tiup-component-cluster-rename.md b/tiup/tiup-component-cluster-rename.md index 31d2c440284c..f506a63a13f6 100644 --- a/tiup/tiup-component-cluster-rename.md +++ b/tiup/tiup-component-cluster-rename.md @@ -1,5 +1,6 @@ --- title: tiup cluster rename +summary: tiup cluster rename 命令用于更改部署集群后的集群名。如果要更改集群名，可以使用 tiup cluster rename 命令。注意：如果配置了 grafana_servers 的 dashboard_dir 字段，需要更新本地 dashboards 目录中的 *.json 文件的 datasource 字段的值，并执行 tiup cluster reload -R grafana 命令。执行日志将输出到 tiup-cluster。 --- # tiup cluster rename diff --git a/tiup/tiup-component-cluster-replay.md b/tiup/tiup-component-cluster-replay.md index 8c0012262fd3..0011858ddb05 100644 --- a/tiup/tiup-component-cluster-replay.md +++ b/tiup/tiup-component-cluster-replay.md @@ -1,5 +1,6 @@ --- title: tiup cluster replay +summary: tiup cluster replay 命令用于重试集群操作中失败的命令，并跳过已成功的步骤。使用 `tiup cluster audit` 查看历史命令及其 audit-id。执行命令：tiup cluster replay 。选项：-h, --help。输出为对应命令的输出。 --- # tiup cluster replay diff --git a/tiup/tiup-component-cluster-restart.md b/tiup/tiup-component-cluster-restart.md index bf3be5ed5511..0dd9eb079435 100644 --- a/tiup/tiup-component-cluster-restart.md +++ b/tiup/tiup-component-cluster-restart.md @@ -1,5 +1,6 @@ --- title: tiup cluster restart +summary: tiup cluster restart 命令用于重启指定集群的所有或部分服务。重启过程中会有一段时间服务不可用。语法为 tiup cluster restart [flags]。选项包括 -N, --node（strings，默认为 []，表示所有节点），-R, --role（strings，默认为 []，表示所有角色），-h, --help。输出为重启服务的日志。 --- # tiup cluster restart diff --git a/tiup/tiup-component-cluster-scale-in.md b/tiup/tiup-component-cluster-scale-in.md index 2ddf4fa65220..d91defbe96d6 100644 --- a/tiup/tiup-component-cluster-scale-in.md +++ b/tiup/tiup-component-cluster-scale-in.md @@ -1,5 +1,6 @@ --- title: tiup cluster scale-in +summary: tiup cluster scale-in 命令用于集群缩容，包括下线 TiKV、TiFlash 和 TiDB Binlog 组件，以及其他组件。特殊处理包括通过 API 执行移除操作，并清理相关数据文件。命令语法为 tiup cluster scale-in ，必须指定要缩容的节点。其他选项包括 --force 用于强制移除宕机节点，--transfer-timeout 设置最长等待时间，-h 输出帮助信息。输出为缩容日志。 --- # tiup cluster scale-in diff --git a/tiup/tiup-component-cluster-scale-out.md b/tiup/tiup-component-cluster-scale-out.md index 57c7313f5275..de78a63547e6 100644 --- a/tiup/tiup-component-cluster-scale-out.md +++ b/tiup/tiup-component-cluster-scale-out.md @@ -1,5 +1,6 @@ --- title: tiup cluster scale-out +summary: tiup cluster scale-out 命令用于集群扩容，内部逻辑与部署类似。PD 节点的扩容通过 join 方式加入集群，并更新相关服务配置；其他服务直接启动加入集群。命令语法为 tiup cluster scale-out 。选项包括 -u, --user, -i, --identity_file, -p, --password, --no-labels, --skip-create-user, -h, --help。输出为扩容日志。 --- # tiup cluster scale-out diff --git a/tiup/tiup-component-cluster-start.md b/tiup/tiup-component-cluster-start.md index 52b7d7afd16e..15c1866007ea 100644 --- a/tiup/tiup-component-cluster-start.md +++ b/tiup/tiup-component-cluster-start.md @@ -1,5 +1,6 @@ --- title: tiup cluster start +summary: tiup cluster start 命令用于启动指定集群的所有或部分服务。语法为 tiup cluster start [flags]。选项包括 --init（以安全方式启动集群）、-N, --node（指定要启动的节点）、-R, --role（指定要启动的角色）、-h, --help。输出为启动日志。 --- # tiup cluster start diff --git a/tiup/tiup-component-cluster-stop.md b/tiup/tiup-component-cluster-stop.md index 71522bd70e25..a10552cc6d12 100644 --- a/tiup/tiup-component-cluster-stop.md +++ b/tiup/tiup-component-cluster-stop.md @@ -1,5 +1,6 @@ --- title: tiup cluster stop +summary: tiup cluster stop 命令用于停止指定集群的所有服务或部分服务。核心服务停止后集群将无法提供服务。语法为 tiup cluster stop 。选项包括 -N, --node（strings，默认为 []，表示所有节点），-R, --role（strings，默认为 []，表示所有角色），-h, --help。停止服务的日志将会输出。 --- # tiup cluster stop diff --git a/tiup/tiup-component-cluster-template.md b/tiup/tiup-component-cluster-template.md index 65555129b83d..549e6e0b8c88 100644 --- a/tiup/tiup-component-cluster-template.md +++ b/tiup/tiup-component-cluster-template.md @@ -1,5 +1,6 @@ --- title: tiup cluster template +summary: TiUP 内置了拓扑文件的模版，用户可以通过修改该模版来生成最终的拓扑文件。使用 tiup cluster template 命令可以输出 TiUP 内置的模版内容。该命令有多个选项，包括输出详细的拓扑模版、输出本地集群的简单拓扑模版以及输出多数据中心的拓扑模版。根据指定选项输出拓扑模版，可重定向到拓扑文件中用于部署。 --- # tiup cluster template diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md index 67645c844d6d..587c1c075959 100644 --- a/tiup/tiup-component-cluster-upgrade.md +++ b/tiup/tiup-component-cluster-upgrade.md @@ -1,5 +1,6 @@ --- title: tiup cluster upgrade +summary: tiup cluster upgrade 命令用于将指定集群升级到特定版本。命令语法为 tiup cluster upgrade [flags]。可使用 --force 选项忽略升级过程的错误，强制替换二进制文件并启动集群。还可通过设置 --transfer-timeout 设置最长等待时间，超时后会跳过等待直接升级服务。其他选项包括 --ignore-config-check、--ignore-version-check、--offline 等。升级服务的日志将会输出。 --- # tiup cluster upgrade diff --git a/tiup/tiup-component-cluster.md b/tiup/tiup-component-cluster.md index d5a5092fc5a5..9b2fc6332b28 100644 --- a/tiup/tiup-component-cluster.md +++ b/tiup/tiup-component-cluster.md @@ -1,5 +1,6 @@ --- title: TiUP Cluster +summary: TiUP Cluster 是使用 Golang 编写的集群管理组件，可进行部署、启动、关闭、销毁、弹性扩缩容、升级 TiDB 集群、管理参数。支持的命令有 import、template、check、deploy、list、display、start、stop、restart、scale-in、scale-out、upgrade、prune、edit-config、reload、patch、rename、clean、destroy、audit、replay、enable、disable、meta backup、meta restore、help。 --- # TiUP Cluster diff --git a/tiup/tiup-component-dm-audit.md b/tiup/tiup-component-dm-audit.md index ba4f69501c50..bae1cda76673 100644 --- a/tiup/tiup-component-dm-audit.md +++ b/tiup/tiup-component-dm-audit.md @@ -1,5 +1,6 @@ --- title: tiup dm audit +summary: tiup dm audit 命令用于查看所有集群上的历史命令和执行日志。若不填写 audit-id，则按时间倒序输出操作记录表格，包括 audit-id、命令执行时间和命令。若填写 audit-id，则查看指定的执行日志。选项 -h, --help 用于输出帮助信息，默认关闭。输出包括指定的 audit-id 对应的执行日志或包含 ID、时间和命令字段的表格。 --- # tiup dm audit diff --git a/tiup/tiup-component-dm-deploy.md b/tiup/tiup-component-dm-deploy.md index b20c14962d44..db3c40f3ccf0 100644 --- a/tiup/tiup-component-dm-deploy.md +++ b/tiup/tiup-component-dm-deploy.md @@ -1,5 +1,6 @@ --- title: tiup dm deploy +summary: tiup dm deploy 命令用于部署全新的集群。语法为 tiup dm deploy [flags]，其中 cluster-name 表示新集群的名字，version 为要部署的 DM 集群版本号，topology.yaml 为事先编写好的拓扑文件。选项包括 -u, -i, -p, -h，分别用于指定连接目标机器的用户名、密钥文件、密码登录和输出帮助信息。输出为部署日志。 --- # tiup dm deploy diff --git a/tiup/tiup-component-dm-destroy.md b/tiup/tiup-component-dm-destroy.md index 24e3bb500135..e7e7dbeaeca6 100644 --- a/tiup/tiup-component-dm-destroy.md +++ b/tiup/tiup-component-dm-destroy.md @@ -1,5 +1,6 @@ --- title: tiup dm destroy +summary: tiup dm destroy 命令用于销毁集群，包括停止集群、删除日志目录、部署目录和数据目录。语法为 tiup dm destroy 。选项 -h, --help 用于输出帮助信息。输出为 tiup-dm 的执行日志。 --- # tiup dm destroy diff --git a/tiup/tiup-component-dm-display.md b/tiup/tiup-component-dm-display.md index 54f67a4f79cd..1a47be7f630b 100644 --- a/tiup/tiup-component-dm-display.md +++ b/tiup/tiup-component-dm-display.md @@ -1,5 +1,6 @@ --- title: tiup dm display +summary: tiup-dm 提供了 `tiup dm display` 命令来高效查看集群中每个组件的运行状态。命令语法为 `tiup dm display `，可指定要查询的节点和角色。输出包括集群名称、版本、SSH 客户端类型，以及节点 ID、角色、IP、端口号、操作系统、状态、数据目录和部署目录等信息。 --- # tiup dm display diff --git a/tiup/tiup-component-dm-edit-config.md b/tiup/tiup-component-dm-edit-config.md index fcc490cefebb..148e5e6c8673 100644 --- a/tiup/tiup-component-dm-edit-config.md +++ b/tiup/tiup-component-dm-edit-config.md @@ -1,5 +1,6 @@ --- title: tiup dm edit-config +summary: tiup dm edit-config 命令用于调整部署集群服务的配置。使用命令后会启动一个编辑器，允许用户修改指定集群的拓扑文件。注意：修改配置时不能增删机器，需执行 tiup dm reload 命令来重新加载配置。语法：tiup dm edit-config 。选项：-h, --help 输出帮助信息。输出：正常情况无输出，若修改了不能修改的字段，则保存文件时报错并提示用户重新编辑。 --- # tiup dm edit-config diff --git a/tiup/tiup-component-dm-enable.md b/tiup/tiup-component-dm-enable.md index d43920e1d92d..44f1f2d7dbe7 100644 --- a/tiup/tiup-component-dm-enable.md +++ b/tiup/tiup-component-dm-enable.md @@ -1,5 +1,6 @@ --- title: tiup dm enable +summary: tiup dm enable 命令用于设置集群服务在机器重启后的自启动。命令语法为 tiup dm enable ，其中 cluster-name 为要启用自启的集群。选项包括 -N, --node 和 -R, --role，分别用于指定要开启自启的节点和角色。若不指定选项，默认开启所有节点和角色的自启。执行日志将作为输出。 --- # tiup dm enable diff --git a/tiup/tiup-component-dm-help.md b/tiup/tiup-component-dm-help.md index bb67da1feb0c..44ad2570d179 100644 --- a/tiup/tiup-component-dm-help.md +++ b/tiup/tiup-component-dm-help.md @@ -1,5 +1,6 @@ --- title: tiup dm help +summary: tiup-dm 提供丰富的命令行界面帮助信息，可通过 `help` 命令或 `--help` 参数获取。`tiup dm help ` 等同于 `tiup dm --help`。语法：`tiup dm help [command] [flags]`。`[command]` 用于指定要查看的命令帮助信息，若不指定，则查看 tiup-dm 自身的帮助信息。使用 `-h, --help` 输出帮助信息，数据类型为 `BOOLEAN`，默认关闭。输出为 `[command]` 或 tiup-dm 的帮助信息。 --- # tiup dm help diff --git a/tiup/tiup-component-dm-import.md b/tiup/tiup-component-dm-import.md index 3356ab2dff90..2c9b70e56374 100644 --- a/tiup/tiup-component-dm-import.md +++ b/tiup/tiup-component-dm-import.md @@ -1,5 +1,6 @@ --- title: tiup dm import +summary: TiUP DM 提供了 `import` 命令，用于将 DM v1.0 集群导入到全新的 v2.0 集群。在导入前，请先停止原集群，并确认升级 TiUP DM 组件到最新版本。导入过程中会生成日志信息，不支持导入 v1.0 集群中的 DM Portal 组件。对于需要升级到 v2.0 的数据迁移任务，请不要执行 `stop-task`。具体语法和选项可以使用 `tiup dm import [flags]` 命令查看。 --- # tiup dm import 仅适用于升级 DM v1.0 diff --git a/tiup/tiup-component-dm-list.md b/tiup/tiup-component-dm-list.md index ce6ddb7debec..73af188c922c 100644 --- a/tiup/tiup-component-dm-list.md +++ b/tiup/tiup-component-dm-list.md @@ -1,5 +1,6 @@ --- title: tiup dm list +summary: tiup-dm 支持使用同一个中控机部署多套集群。命令 `tiup dm list` 可以查看当前登录的用户使用该中控机部署了哪些集群。部署的集群数据默认放在 `~/.tiup/storage/dm/clusters/` 目录下。在同一台中控机上，当前登录用户无法查看其他用户部署的集群。该命令输出含有集群名字、部署用户、集群版本、集群部署数据在中控机上的路径、连接集群的私钥所在路径的表格。 --- # tiup dm list diff --git a/tiup/tiup-component-dm-prune.md b/tiup/tiup-component-dm-prune.md index cde98b0f6ae8..0117587ceaa3 100644 --- a/tiup/tiup-component-dm-prune.md +++ b/tiup/tiup-component-dm-prune.md @@ -1,5 +1,6 @@ --- title: tiup dm prune +summary: tiup dm prune 命令用于在缩容集群后清理 etcd 中的少量元信息。通常情况下不会有问题，但如果需要清理，可以手动执行该命令。语法为 tiup dm prune ，选项包括 -h, --help，输出为清理过程的日志。 --- # tiup dm prune diff --git a/tiup/tiup-component-dm-reload.md b/tiup/tiup-component-dm-reload.md index bc6342c5d69a..f7f8b930e78a 100644 --- a/tiup/tiup-component-dm-reload.md +++ b/tiup/tiup-component-dm-reload.md @@ -1,5 +1,6 @@ --- title: tiup dm reload +summary: tiup dm reload 命令用于在修改集群配置后重新加载配置。该命令将中控机的配置发布到远端机器，并按顺序重启服务，重启过程中集群可用。语法为 tiup dm reload 。选项包括 -N, --node（重启节点）、-R, --role（重启角色）、--skip-restart（仅刷新配置不重启节点）、-h, --help（输出帮助信息）。输出为 tiup-dm 的执行日志。 --- # tiup dm reload diff --git a/tiup/tiup-component-dm-replay.md b/tiup/tiup-component-dm-replay.md index 7cfb06450c75..e272cfd56392 100644 --- a/tiup/tiup-component-dm-replay.md +++ b/tiup/tiup-component-dm-replay.md @@ -1,5 +1,6 @@ --- title: tiup dm replay +summary: tiup dm replay 命令用于重试集群操作中失败的命令，并跳过已成功的步骤。使用命令时需指定要重试的命令对应的 audit-id，可通过 tiup dm audit 查看历史命令及其 audit-id。命令输出为对应命令的输出。 --- # tiup dm replay diff --git a/tiup/tiup-component-dm-restart.md b/tiup/tiup-component-dm-restart.md index 62ddce1f8cec..ae20132f4b87 100644 --- a/tiup/tiup-component-dm-restart.md +++ b/tiup/tiup-component-dm-restart.md @@ -1,5 +1,6 @@ --- title: tiup dm restart +summary: tiup dm restart 命令用于重启指定集群的所有或部分服务。重启过程中会有一段时间服务不可用。语法为 tiup dm restart [flags]，其中 为要操作的集群名字。选项包括 -N, --node（strings，默认为 []，表示所有节点），-R, --role（strings，默认为 []，表示所有角色），-h, --help。输出为重启服务的日志。 --- # tiup dm restart diff --git a/tiup/tiup-component-dm-scale-in.md b/tiup/tiup-component-dm-scale-in.md index 801539b835b6..f4737ee033bb 100644 --- a/tiup/tiup-component-dm-scale-in.md +++ b/tiup/tiup-component-dm-scale-in.md @@ -1,5 +1,6 @@ --- title: tiup dm scale-in +summary: tiup dm scale-in 命令用于集群缩容，即下线服务并移除指定节点和相关文件。语法为 tiup dm scale-in ，其中 为集群名。选项包括 -N, --node（必须非空，选择要缩容的节点），--force（强制移除宕机节点），-h, --help（输出帮助信息）。输出为缩容日志。 --- # tiup dm scale-in diff --git a/tiup/tiup-component-dm-scale-out.md b/tiup/tiup-component-dm-scale-out.md index b7fc92c78343..9c483e86b3b3 100644 --- a/tiup/tiup-component-dm-scale-out.md +++ b/tiup/tiup-component-dm-scale-out.md @@ -1,5 +1,6 @@ --- title: tiup dm scale-out +summary: tiup dm scale-out 命令用于集群扩容，内部逻辑与部署类似。首先建立新节点的 SSH 连接，在目标节点上创建必要的目录，然后执行部署并启动服务。命令语法为 tiup dm scale-out 。选项包括 -u, --user（string，默认为当前执行命令的用户），-i, --identity_file（string，默认 ~/.ssh/id_rsa），-p, --password，-h, --help。输出为扩容日志。 --- # tiup dm scale-out diff --git a/tiup/tiup-component-dm-stop.md b/tiup/tiup-component-dm-stop.md index 11e53164be6c..728966a692d9 100644 --- a/tiup/tiup-component-dm-stop.md +++ b/tiup/tiup-component-dm-stop.md @@ -1,5 +1,6 @@ --- title: tiup dm stop +summary: tiup dm stop 命令用于停止指定集群的所有服务或部分服务。核心服务停止后集群将无法提供服务。语法为 tiup dm stop [flags]。选项包括 -N, --node（strings，默认为 []，表示所有节点），-R, --role（strings，默认为 []，表示所有角色），-h, --help。停止服务的日志将会输出。 --- # tiup dm stop diff --git a/tiup/tiup-component-dm-template.md b/tiup/tiup-component-dm-template.md index f53fb2e22997..f63b9b7f26e2 100644 --- a/tiup/tiup-component-dm-template.md +++ b/tiup/tiup-component-dm-template.md @@ -1,5 +1,6 @@ --- title: tiup dm template +summary: tiup dm template 命令用于输出 TiUP 内置的集群拓扑模版内容。可以通过修改模版来生成最终的拓扑文件。可选的 --full 选项输出详细的拓扑模版，带上可配置的参数。输出拓扑模版到标准输出，可重定向到拓扑文件中用于部署。 --- # tiup dm template diff --git a/tiup/tiup-component-dm-upgrade.md b/tiup/tiup-component-dm-upgrade.md index 6241aad823a4..c5648167b633 100644 --- a/tiup/tiup-component-dm-upgrade.md +++ b/tiup/tiup-component-dm-upgrade.md @@ -1,5 +1,6 @@ --- title: tiup dm upgrade +summary: tiup dm upgrade 命令用于将指定集群升级到特定版本。语法为 tiup dm upgrade [flags]。cluster-name 为要操作的集群名字，version 为要升级到的目标版本。选项 --offline 声明当前集群处于离线状态，-h, --help 输出帮助信息。升级服务的日志可查看。 --- # tiup dm upgrade diff --git a/tiup/tiup-component-dm.md b/tiup/tiup-component-dm.md index 66e56ca48144..ffc5c6c54aad 100644 --- a/tiup/tiup-component-dm.md +++ b/tiup/tiup-component-dm.md @@ -1,5 +1,6 @@ --- title: TiUP DM +summary: TiUP DM 是用于对 DM 集群进行日常运维工作的管理工具，包括部署、启动、关闭、销毁、弹性扩缩容、升级、参数管理等操作。命令包括 import、template、deploy、list、display、start、stop、restart、scale-in、scale-out、upgrade、prune、edit-config、reload、patch、destroy、audit、replay、enable、disable、help。 --- # TiUP DM diff --git a/tiup/tiup-component-management.md b/tiup/tiup-component-management.md index 827e3c916e6e..780000efa9b6 100644 --- a/tiup/tiup-component-management.md +++ b/tiup/tiup-component-management.md @@ -1,6 +1,7 @@ --- title: 使用 TiUP 命令管理组件 aliases: ['/docs-cn/dev/tiup/tiup-component-management/','/docs-cn/dev/reference/tools/tiup/manage-component/','/docs-cn/dev/reference/tools/tiup/manage-tiup-component/'] +summary: TiUP 是一个用于管理组件的命令行工具。它提供了一系列命令来查询组件列表、安装、升级、运行、查看状态、清理实例和卸载组件。此外，还可以使用实验性的 `link` 和 `unlink` 命令来将组件的二进制符号链接到可执行文件目录。 --- # 使用 TiUP 命令管理组件 diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index af5b3c2ed617..99b05d4f3395 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -1,5 +1,6 @@ --- title: 通过 TiUP 部署 DM 集群的拓扑文件配置 +summary: TiUP 部署 DM 集群的拓扑文件配置包括全局配置、组件配置、master 服务器配置、worker 服务器配置、监控服务器配置、Grafana 服务器配置和 Alertmanager 服务器配置。每个配置包含不同字段，如部署目录、数据目录、日志目录等。部署完成后部分字段不能再修改。 --- # 通过 TiUP 部署 DM 集群的拓扑文件配置 diff --git a/tiup/tiup-documentation-guide.md b/tiup/tiup-documentation-guide.md index b0fc8c02d48e..b40b010ca1b2 100644 --- a/tiup/tiup-documentation-guide.md +++ b/tiup/tiup-documentation-guide.md @@ -1,6 +1,7 @@ --- title: TiUP 文档地图 aliases: ['/docs-cn/dev/tiup/tiup-documentation-guide/'] +summary: TiUP 文档地图包括使用文档和资源两部分。使用文档包括 TiUP 概览、TiUP 术语、TiUP 组件管理、TiUP FAQ、TiUP 故障排查和 TiUP 参考手册。资源包括 TiUP 版本发布说明、AskTUG TiUP 主题和 TiUP Issues。 --- # TiUP 文档地图 diff --git a/tiup/tiup-faq.md b/tiup/tiup-faq.md index 8f339ce45c81..0ac625e09876 100644 --- a/tiup/tiup-faq.md +++ b/tiup/tiup-faq.md @@ -1,6 +1,7 @@ --- title: TiUP FAQ aliases: ['/docs-cn/dev/tiup/tiup-faq/'] +summary: TiUP 支持自定义镜像源，可以使用环境变量 TIUP_MIRRORS 指定镜像源地址。开发者可以通过 tiup-publish 组件将自己编写的组件发布到 TiUP 的官方镜像仓库。TiUP Playground 用于快速搭建开发环境，而 TiUP Cluster 用于部署生产环境集群。拓扑文件样例包括两地三中心、最小部署和完整拓扑文件。同一主机可以部署多个实例，但需要配置不同的端口和目录信息。集群部署期间可能出现 ssh 连接错误，可尝试加大 ssh 默认连接数并重启 sshd 服务解决。 --- # TiUP FAQ diff --git a/tiup/tiup-mirror-reference.md b/tiup/tiup-mirror-reference.md index 5c8b6fa17cee..dff3c0359fc0 100644 --- a/tiup/tiup-mirror-reference.md +++ b/tiup/tiup-mirror-reference.md @@ -1,5 +1,6 @@ --- title: TiUP 镜像参考指南 +summary: TiUP 镜像是存放 TiUP 组件和元信息的仓库。镜像存在两种形式：本地镜像和远程镜像。镜像可通过命令创建和更新。镜像目录结构包括根证书、索引、组件、快照和时间戳。客户端通过逻辑保证下载文件安全。 --- # TiUP 镜像参考指南 diff --git a/tiup/tiup-mirror.md b/tiup/tiup-mirror.md index 015dcfc15913..83a1ef30d074 100644 --- a/tiup/tiup-mirror.md +++ b/tiup/tiup-mirror.md @@ -1,6 +1,7 @@ --- title: 搭建私有镜像 aliases: ['/docs-cn/dev/tiup/tiup-mirror/','/docs-cn/dev/tiup/tiup-mirrors/','/docs-cn/dev/reference/tools/tiup/mirror/','/docs-cn/dev/reference/tools/tiup/mirrors/'] +summary: TiUP 提供了构建私有镜像的方案，使用 mirror 指令来实现，可用于离线部署。执行 `tiup mirror clone` 命令，可构建本地地镜像。克隆完成后，可以通过 SCP、NFS、HTTP 或 HTTPS 共享仓库。使用 `TIUP_MIRRORS` 环境变量来使用镜像。重新运行 `tiup mirror clone` 命令会创建新的 manifest，并下载可用的最新版本的组件。可以创建自定义仓库，并使用自己构建的 TiDB 组件。 --- # 搭建私有镜像 diff --git a/tiup/tiup-overview.md b/tiup/tiup-overview.md index 1ec7edec257e..b967bd3f0325 100644 --- a/tiup/tiup-overview.md +++ b/tiup/tiup-overview.md @@ -1,6 +1,7 @@ --- title: TiUP 简介 aliases: ['/docs-cn/dev/tiup/tiup-overview/','/docs-cn/dev/reference/tools/tiup/overview/'] +summary: TiUP 是 TiDB 生态中的包管理工具，简化了软件的安装和升级维护工作。安装 TiUP 十分简洁，只需执行一行命令即可完成。TiUP 的愿景是降低 TiDB 生态中所有工具的使用门槛，通过命令和组件来实现包管理和操作。 --- # TiUP 简介 diff --git a/tiup/tiup-playground.md b/tiup/tiup-playground.md index c9ed2c47350d..60e0ab2849a6 100644 --- a/tiup/tiup-playground.md +++ b/tiup/tiup-playground.md @@ -1,6 +1,7 @@ --- title: 本地快速部署 TiDB 集群 aliases: ['/docs-cn/dev/tiup/tiup-playground/','/docs-cn/dev/reference/tools/tiup/playground/'] +summary: TiDB 集群是分布式系统，由多个组件构成。想要快速体验 TiDB，可以使用 TiUP 中的 playground 组件快速搭建本地测试环境。通过命令行参数可以设置各组件的数量和配置，也可以启动多个组件实例。使用 `tiup client` 可以快速连接到本地启动的 TiDB 集群。还可以查看已启动集群的信息，扩容或缩容集群。 --- # 本地快速部署 TiDB 集群 diff --git a/tiup/tiup-reference.md b/tiup/tiup-reference.md index 12775784e652..107a8f906323 100644 --- a/tiup/tiup-reference.md +++ b/tiup/tiup-reference.md @@ -1,5 +1,6 @@ --- title: TiUP 命令概览 +summary: TiUP 是 TiDB 生态的包管理器，管理着诸如 TiDB、PD、TiKV 等组件。它支持执行命令和运行组件，可以通过 `--help` 获取命令信息。选项包括打印二进制文件路径、指定组件路径、指定组件 tag、打印版本和帮助信息。TiUP 包含众多命令和子命令，以及组件清单。 --- # TiUP 命令概览 diff --git a/tiup/tiup-terminology-and-concepts.md b/tiup/tiup-terminology-and-concepts.md index cb7e8c7b7b28..b716fdf46a59 100644 --- a/tiup/tiup-terminology-and-concepts.md +++ b/tiup/tiup-terminology-and-concepts.md @@ -1,6 +1,7 @@ --- title: TiUP 术语及核心概念 aliases: ['/docs-cn/dev/tiup/tiup-terminology-and-concepts/'] +summary: TiUP 是一个用于下载、更新、卸载组件的程序，通过各种组件来扩展其功能。组件是可以运行的程序或脚本，通过 tiup 命令来运行。TiUP 组件可以从镜像仓库下载，用户可以通过设置 TIUP_MIRRORS 环境变量来自定义镜像仓库。 --- # TiUP 术语及核心概念 diff --git a/tiup/tiup-troubleshooting-guide.md b/tiup/tiup-troubleshooting-guide.md index 6ccb772c5033..f4414790e0c6 100644 --- a/tiup/tiup-troubleshooting-guide.md +++ b/tiup/tiup-troubleshooting-guide.md @@ -1,6 +1,7 @@ --- title: TiUP 故障排查 aliases: ['/docs-cn/dev/tiup/tiup-troubleshooting-guide/'] +summary: TiUP 故障排查包括命令故障排查和集群组件故障排查。命令故障包括强制刷新组件列表和版本信息，网络中断导致的下载问题，以及 checksum 错误。集群组件故障包括 SSH 私钥问题，升级中断和缺失组件文件的解决方法。可通过 Github Issues 或 AskTUG 求助。 --- # TiUP 故障排查 diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index 7a5b3e878429..3eadd3f95102 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -1,140 +1,140 @@ ---- -title: 读写延迟增加 -summary: 介绍读写延时增加、抖动时的排查思路，可能的原因和解决方法。 -aliases: ['/docs-cn/dev/troubleshoot-cpu-issues/'] ---- - -# 读写延迟增加 - -本文档介绍读写延迟增加、抖动时的排查思路，可能的原因和解决方法。 - -## 常见原因 - -### TiDB 执行计划不对导致延迟增高 - -查询语句的执行计划不稳定，偶尔执行计划选择错误的索引，导致查询延迟增加。 - -**现象：** - -* 如果慢日志中输出了执行计划，可以直接查看执行计划。用 `select tidb_decode_plan('xxx...')` 语句可以解析出具体的执行计划。 -* 监控中的 key 扫描异常升高；慢日志中 SQL 执行时间 `Scan Keys` 数目较大。 -* SQL 执行时间相比于其他数据库（例如 MySQL）有较大差距。可以对比其他数据库执行计划，例如 `Join Order` 是否不同。 - -**可能的原因：** - -* 统计信息不准确 - -**解决方案：** - -* 更新统计信息 - * 手动 `analyze table`，配合 crontab 定期 `analyze`，维持统计信息准确度。 - * 自动 `auto analyze`，调低 `analyze ratio` 阈值，提高收集频次，并设置运行时间窗口。示例如下： - * `set global tidb_auto_analyze_ratio=0.2;` - * `set global tidb_auto_analyze_start_time='00:00 +0800';` - * `set global tidb_auto_analyze_end_time='06:00 +0800';` -* 绑定执行计划 - * 修改业务 SQL，使用 `use index` 固定使用列上的索引。 - * 3.0 版本下，业务可以不用修改 SQL，使用 `create global binding` 创建 `force index` 的绑定 SQL。 - * 4.0 版本支持 SQL Plan Management，可以避免因执行计划不稳定导致的性能下降。 - -### PD 异常 - -**现象：** - -监控中 PD TSO 的 **wait duration** 异常升高。**wait duration** 代表从开始等待 PD 返回，到等待结束的时间。 - -**可能的原因：** - -* 磁盘问题。PD 所在的节点 I/O 被占满，排查是否有其他 I/O 高的组件与 PD 混合部署以及磁盘的健康情况，可通过监控 Grafana -> **disk performance** -> **latency** 和 **load** 等指标进行验证，必要时可以使用 fio 工具对盘进行检测，见案例 [case-292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md)。 - -* PD 之间的网络问题。PD 日志中有 `"lost the TCP streaming connection"`，排查 PD 之间网络是否有问题，可通过监控 Grafana -> **PD** -> **etcd** 的 **round trip** 来验证，见案例 [case-177](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case177.md)。 - -* 系统负载高，日志中能看到 `"server is likely overloaded"`，见案例 [case-214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md)。 - -* 选举不出 leader。PD 日志中有 `"lease is not expired"`，见 issues [https://github.com/etcd-io/etcd/issues/10355](https://github.com/etcd-io/etcd/issues/10355)。v3.0.x 版本和 v2.1.19 版本已解决该问题，见案例 [case-875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)。 - -* 选举慢。Region 加载时间长，从 PD 日志中 `grep "regions cost"`（例如日志中可能是 `load 460927 regions cost 11.77099s`），如果出现秒级，则说明较慢，v3.0 版本可开启 Region Storage（设置 `use-region-storage` 为 `true`），该特性能极大缩短加载 Region 的时间，见案例 [case-429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md)。 - -* TiDB 与 PD 之间的网络问题，应排查网络相关情况。通过监控 Grafana -> **blackbox_exporter** -> **ping latency** 确定 TiDB 到 PD leader 的网络是否正常。 - -* PD 报 `FATAL` 错误，日志中有 `"range failed to find revision pair"`。v3.0.8 中已经解决问题，见 PR [https://github.com/pingcap/pd/pull/2040](https://github.com/pingcap/pd/pull/2040)。详情请参考案例 [case-947](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case947.md)。 - -* 使用 `/api/v1/regions` 接口时 Region 数量过多可能会导致 PD OOM。已于 v3.0.8 版本修复，见 [https://github.com/pingcap/pd/pull/1986](https://github.com/pingcap/pd/pull/1986)。 - -* 滚动升级的时候 PD OOM，gRPC 消息大小没限制，监控可看到 TCP InSegs 较大，已于 v3.0.6 版本修复，见 [https://github.com/pingcap/pd/pull/1952](https://github.com/pingcap/pd/pull/1952)。 - -* PD panic，请[提交 bug](https://github.com/tikv/pd/issues/new?labels=kind/bug&template=bug-report.md)。 - -* 其他原因，通过 `curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2` 抓取 goroutine，并[提交 bug](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 - -### TiKV 异常 - -**现象：** - -监控中 **KV Cmd Duration** 异常升高。KV Cmd Duration 是 TiDB 发送请求给 TiKV 到收到回复的延迟。 - -**可能的原因：** - -* 查看 gRPC duration。gRPC duration 是请求在 TiKV 端的总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间网络延迟可能很高，或者 TiDB 和 TiKV 之间的网卡带宽被占满。 - -* TiKV 重启了导致重新选举 - * TiKV panic 之后又被 `systemd` 重新拉起正常运行，可以通过查看 TiKV 的日志来确认是否有 `panic`，这种情况属于非预期，需要报 bug。 - * 被第三者 `stop`/`kill`，被 `systemd` 重新拉起。查看 `dmesg` 和 `TiKV log` 确认原因。 - * TiKV 发生 OOM 导致重启了。 - * 动态调整 `THP` 导致 hung 住，见案例 [case-500](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case500.md)。 - -* 查看监控：Grafana -> **TiKV-details** -> **errors** 面板 `server is busy` 看到 TiKV RocksDB 出现 write stall 导致发生重新选举。 - -* TiKV 发生网络隔离导致重新选举。 - -* `block-cache` 配置太大导致 OOM，在监控 Grafana -> **TiKV-details** 选中对应的 instance 之后查看 RocksDB 的 `block cache size` 监控来确认是否是该问题。同时请检查 `[storage.block-cache] capacity = # "1GB"` 参数是否设置合理，默认情况下 TiKV 的 `block-cache` 设置为机器总内存的 `45%`。在容器化部署时需要显式指定该参数，因为 TiKV 获取的是物理机的内存，可能会超出单个 container 的内存限制。 - -* Coprocessor 收到大量大查询，返回的数据量太大，gRPC 发送速度跟不上 Coprocessor 向客户端输出数据的速度导致 OOM。可以通过检查监控：Grafana -> **TiKV-details** -> **coprocessor overview** 的 `response size` 是否超过 `network outbound` 流量来确认是否属于这种情况。 - -### TiKV 单线程瓶颈 - -TiKV 中存在一些单线程线程，可能会成为瓶颈。 - -* 单个 TiKV Region 过多导致单个 gRPC 线程成为瓶颈（查看 Grafana -> TiKV-details -> `Thread CPU/gRPC CPU Per Thread` 监控），v3.x 以上版本可以开启 Hibernate Region 特性来解决，见案例 [case-612](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case612.md)。 -* v3.0 之前版本 Raftstore 单线程或者 Apply 单线程到达瓶颈（Grafana -> TiKV-details -> `Thread CPU/raft store CPU 和 Async apply CPU` 超过 `80%`），可以选择扩容 TiKV（v2.x 版本）实例或者升级到多线程模型的 v3.x 版本。 - -### CPU Load 升高 - -**现象：** - -CPU 资源使用到达瓶颈 - -**可能的原因：** - -* 热点问题。 -* 整体负载高，排查 TiDB 的 slow query 和 expensive query。对运行的 query 进行优化，如果缺索引就加索引，如果可以批量执行就批量执行。另一个方案是对集群进行扩容。 - -## 其它原因 - -### 集群维护 - -通常大多数的线上集群有 3 或 5 个 PD 节点，如果维护的主机上有 PD 组件，需要具体考虑节点是 leader 还是 follower，关闭 follower 对集群运行没有任何影响，关闭 leader 需要先切换，并在切换时有 3 秒左右的性能抖动。 - -### 少数派副本离线 - -TiDB 集群默认配置为 3 副本，每一个 Region 都会在集群中保存 3 份，它们之间通过 Raft 协议来选举 Leader 并同步数据。Raft 协议可以保证在数量小于副本数（注意：不是节点数）一半的节点挂掉或者隔离的情况下，仍然能够提供服务，并且不丢失任何数据。对于 3 副本集群，挂掉一个节点可能会导致性能抖动，可用性和正确性理论上不会受影响。 - -### 新增索引 - -由于创建索引在扫表回填索引的时候会消耗大量资源，甚至与一些频繁更新的字段会发生冲突导致正常业务受到影响。大表创建索引的过程往往会持续很长时间，所以要尽可能地平衡执行时间和集群性能之间的关系，比如选择非高频更新时间段。 - -**参数调整：** - -目前主要使用 `tidb_ddl_reorg_worker_cnt` 和 `tidb_ddl_reorg_batch_size` 这两个参数来动态调整索引创建速度，通常来说它们的值越小对系统影响越小，但是执行时间越长。 - -一般情况下，先将值保持为默认的 `4` 和 `256`，观察集群资源使用情况和响应速度，再逐渐调大 `tidb_ddl_reorg_worker_cnt` 参数来增加并发，观察监控如果系统没有发生明显的抖动，再逐渐调大 `tidb_ddl_reorg_batch_size` 参数，但如果索引涉及的列更新很频繁的话就会造成大量冲突造成失败重试。 - -另外还可以通过调整参数 `tidb_ddl_reorg_priority` 为 `PRIORITY_HIGH` 来让创建索引的任务保持高优先级来提升速度，但在通用 OLTP 系统上，一般建议保持默认。 - -### GC 压力大 - -TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。GC 的任务便是清理不再需要的旧数据。 - -* Resolve Locks 阶段在 TiKV 一侧会产生大量的 scan_lock 请求，可以在 gRPC 相关的 metrics 中观察到。`scan_lock` 请求会对全部的 Region 调用。 -* Delete Ranges 阶段会往 TiKV 发送少量的 `unsafe_destroy_range` 请求，也可能没有。可以在 gRPC 相关的 metrics 中和 GC 分类下的 GC tasks 中观察到。 -* Do GC 阶段，默认每台 TiKV 会自动扫描本机上的 leader Region 并对每一个 leader 进行 GC，这一活动可以在 GC 分类下的 GC tasks 中观察到。 +--- +title: 读写延迟增加 +summary: 介绍读写延时增加、抖动时的排查思路，可能的原因和解决方法。 +aliases: ['/docs-cn/dev/troubleshoot-cpu-issues/'] +--- + +# 读写延迟增加 + +本文档介绍读写延迟增加、抖动时的排查思路，可能的原因和解决方法。 + +## 常见原因 + +### TiDB 执行计划不对导致延迟增高 + +查询语句的执行计划不稳定，偶尔执行计划选择错误的索引，导致查询延迟增加。 + +**现象：** + +* 如果慢日志中输出了执行计划，可以直接查看执行计划。用 `select tidb_decode_plan('xxx...')` 语句可以解析出具体的执行计划。 +* 监控中的 key 扫描异常升高；慢日志中 SQL 执行时间 `Scan Keys` 数目较大。 +* SQL 执行时间相比于其他数据库（例如 MySQL）有较大差距。可以对比其他数据库执行计划，例如 `Join Order` 是否不同。 + +**可能的原因：** + +* 统计信息不准确 + +**解决方案：** + +* 更新统计信息 + * 手动 `analyze table`，配合 crontab 定期 `analyze`，维持统计信息准确度。 + * 自动 `auto analyze`，调低 `analyze ratio` 阈值，提高收集频次，并设置运行时间窗口。示例如下： + * `set global tidb_auto_analyze_ratio=0.2;` + * `set global tidb_auto_analyze_start_time='00:00 +0800';` + * `set global tidb_auto_analyze_end_time='06:00 +0800';` +* 绑定执行计划 + * 修改业务 SQL，使用 `use index` 固定使用列上的索引。 + * 3.0 版本下，业务可以不用修改 SQL，使用 `create global binding` 创建 `force index` 的绑定 SQL。 + * 4.0 版本支持 SQL Plan Management，可以避免因执行计划不稳定导致的性能下降。 + +### PD 异常 + +**现象：** + +监控中 PD TSO 的 **wait duration** 异常升高。**wait duration** 代表从开始等待 PD 返回，到等待结束的时间。 + +**可能的原因：** + +* 磁盘问题。PD 所在的节点 I/O 被占满，排查是否有其他 I/O 高的组件与 PD 混合部署以及磁盘的健康情况，可通过监控 Grafana -> **disk performance** -> **latency** 和 **load** 等指标进行验证，必要时可以使用 fio 工具对盘进行检测，见案例 [case-292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md)。 + +* PD 之间的网络问题。PD 日志中有 `"lost the TCP streaming connection"`，排查 PD 之间网络是否有问题，可通过监控 Grafana -> **PD** -> **etcd** 的 **round trip** 来验证，见案例 [case-177](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case177.md)。 + +* 系统负载高，日志中能看到 `"server is likely overloaded"`，见案例 [case-214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md)。 + +* 选举不出 leader。PD 日志中有 `"lease is not expired"`，见 issues [https://github.com/etcd-io/etcd/issues/10355](https://github.com/etcd-io/etcd/issues/10355)。v3.0.x 版本和 v2.1.19 版本已解决该问题，见案例 [case-875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)。 + +* 选举慢。Region 加载时间长，从 PD 日志中 `grep "regions cost"`（例如日志中可能是 `load 460927 regions cost 11.77099s`），如果出现秒级，则说明较慢，v3.0 版本可开启 Region Storage（设置 `use-region-storage` 为 `true`），该特性能极大缩短加载 Region 的时间，见案例 [case-429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md)。 + +* TiDB 与 PD 之间的网络问题，应排查网络相关情况。通过监控 Grafana -> **blackbox_exporter** -> **ping latency** 确定 TiDB 到 PD leader 的网络是否正常。 + +* PD 报 `FATAL` 错误，日志中有 `"range failed to find revision pair"`。v3.0.8 中已经解决问题，见 PR [https://github.com/pingcap/pd/pull/2040](https://github.com/pingcap/pd/pull/2040)。详情请参考案例 [case-947](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case947.md)。 + +* 使用 `/api/v1/regions` 接口时 Region 数量过多可能会导致 PD OOM。已于 v3.0.8 版本修复，见 [https://github.com/pingcap/pd/pull/1986](https://github.com/pingcap/pd/pull/1986)。 + +* 滚动升级的时候 PD OOM，gRPC 消息大小没限制，监控可看到 TCP InSegs 较大，已于 v3.0.6 版本修复，见 [https://github.com/pingcap/pd/pull/1952](https://github.com/pingcap/pd/pull/1952)。 + +* PD panic，请[提交 bug](https://github.com/tikv/pd/issues/new?labels=kind/bug&template=bug-report.md)。 + +* 其他原因，通过 `curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2` 抓取 goroutine，并[提交 bug](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 + +### TiKV 异常 + +**现象：** + +监控中 **KV Cmd Duration** 异常升高。KV Cmd Duration 是 TiDB 发送请求给 TiKV 到收到回复的延迟。 + +**可能的原因：** + +* 查看 gRPC duration。gRPC duration 是请求在 TiKV 端的总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间网络延迟可能很高，或者 TiDB 和 TiKV 之间的网卡带宽被占满。 + +* TiKV 重启了导致重新选举 + * TiKV panic 之后又被 `systemd` 重新拉起正常运行，可以通过查看 TiKV 的日志来确认是否有 `panic`，这种情况属于非预期，需要报 bug。 + * 被第三者 `stop`/`kill`，被 `systemd` 重新拉起。查看 `dmesg` 和 `TiKV log` 确认原因。 + * TiKV 发生 OOM 导致重启了。 + * 动态调整 `THP` 导致 hung 住，见案例 [case-500](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case500.md)。 + +* 查看监控：Grafana -> **TiKV-details** -> **errors** 面板 `server is busy` 看到 TiKV RocksDB 出现 write stall 导致发生重新选举。 + +* TiKV 发生网络隔离导致重新选举。 + +* `block-cache` 配置太大导致 OOM，在监控 Grafana -> **TiKV-details** 选中对应的 instance 之后查看 RocksDB 的 `block cache size` 监控来确认是否是该问题。同时请检查 `[storage.block-cache] capacity = # "1GB"` 参数是否设置合理，默认情况下 TiKV 的 `block-cache` 设置为机器总内存的 `45%`。在容器化部署时需要显式指定该参数，因为 TiKV 获取的是物理机的内存，可能会超出单个 container 的内存限制。 + +* Coprocessor 收到大量大查询，返回的数据量太大，gRPC 发送速度跟不上 Coprocessor 向客户端输出数据的速度导致 OOM。可以通过检查监控：Grafana -> **TiKV-details** -> **coprocessor overview** 的 `response size` 是否超过 `network outbound` 流量来确认是否属于这种情况。 + +### TiKV 单线程瓶颈 + +TiKV 中存在一些单线程线程，可能会成为瓶颈。 + +* 单个 TiKV Region 过多导致单个 gRPC 线程成为瓶颈（查看 Grafana -> TiKV-details -> `Thread CPU/gRPC CPU Per Thread` 监控），v3.x 以上版本可以开启 Hibernate Region 特性来解决，见案例 [case-612](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case612.md)。 +* v3.0 之前版本 Raftstore 单线程或者 Apply 单线程到达瓶颈（Grafana -> TiKV-details -> `Thread CPU/raft store CPU 和 Async apply CPU` 超过 `80%`），可以选择扩容 TiKV（v2.x 版本）实例或者升级到多线程模型的 v3.x 版本。 + +### CPU Load 升高 + +**现象：** + +CPU 资源使用到达瓶颈 + +**可能的原因：** + +* 热点问题。 +* 整体负载高，排查 TiDB 的 slow query 和 expensive query。对运行的 query 进行优化，如果缺索引就加索引，如果可以批量执行就批量执行。另一个方案是对集群进行扩容。 + +## 其它原因 + +### 集群维护 + +通常大多数的线上集群有 3 或 5 个 PD 节点，如果维护的主机上有 PD 组件，需要具体考虑节点是 leader 还是 follower，关闭 follower 对集群运行没有任何影响，关闭 leader 需要先切换，并在切换时有 3 秒左右的性能抖动。 + +### 少数派副本离线 + +TiDB 集群默认配置为 3 副本，每一个 Region 都会在集群中保存 3 份，它们之间通过 Raft 协议来选举 Leader 并同步数据。Raft 协议可以保证在数量小于副本数（注意：不是节点数）一半的节点挂掉或者隔离的情况下，仍然能够提供服务，并且不丢失任何数据。对于 3 副本集群，挂掉一个节点可能会导致性能抖动，可用性和正确性理论上不会受影响。 + +### 新增索引 + +由于创建索引在扫表回填索引的时候会消耗大量资源，甚至与一些频繁更新的字段会发生冲突导致正常业务受到影响。大表创建索引的过程往往会持续很长时间，所以要尽可能地平衡执行时间和集群性能之间的关系，比如选择非高频更新时间段。 + +**参数调整：** + +目前主要使用 `tidb_ddl_reorg_worker_cnt` 和 `tidb_ddl_reorg_batch_size` 这两个参数来动态调整索引创建速度，通常来说它们的值越小对系统影响越小，但是执行时间越长。 + +一般情况下，先将值保持为默认的 `4` 和 `256`，观察集群资源使用情况和响应速度，再逐渐调大 `tidb_ddl_reorg_worker_cnt` 参数来增加并发，观察监控如果系统没有发生明显的抖动，再逐渐调大 `tidb_ddl_reorg_batch_size` 参数，但如果索引涉及的列更新很频繁的话就会造成大量冲突造成失败重试。 + +另外还可以通过调整参数 `tidb_ddl_reorg_priority` 为 `PRIORITY_HIGH` 来让创建索引的任务保持高优先级来提升速度，但在通用 OLTP 系统上，一般建议保持默认。 + +### GC 压力大 + +TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。GC 的任务便是清理不再需要的旧数据。 + +* Resolve Locks 阶段在 TiKV 一侧会产生大量的 scan_lock 请求，可以在 gRPC 相关的 metrics 中观察到。`scan_lock` 请求会对全部的 Region 调用。 +* Delete Ranges 阶段会往 TiKV 发送少量的 `unsafe_destroy_range` 请求，也可能没有。可以在 gRPC 相关的 metrics 中和 GC 分类下的 GC tasks 中观察到。 +* Do GC 阶段，默认每台 TiKV 会自动扫描本机上的 leader Region 并对每一个 leader 进行 GC，这一活动可以在 GC 分类下的 GC tasks 中观察到。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 9b24820f6aa8..0abce246dc27 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -1,177 +1,178 @@ ---- -title: TiDB 热点问题处理 -aliases: ['/docs-cn/dev/troubleshoot-hot-spot-issues/'] ---- - -# TiDB 热点问题处理 - -本文介绍如何定位和解决读写热点问题。 - -TiDB 作为分布式数据库，内建负载均衡机制，尽可能将业务负载均匀地分布到不同计算或存储节点上，更好地利用上整体系统资源。然而，机制不是万能的，在一些场景下仍会有部分业务负载不能被很好地分散，影响性能，形成单点的过高负载，也称为热点。 - -TiDB 提供了完整的方案用于排查、解决或规避这类热点。通过均衡负载热点，可以提升整体性能，包括提高 QPS 和降低延迟等。 - -## 常见热点场景 - -### TiDB 编码规则回顾 - -TiDB 对每个表分配一个 TableID，每一个索引都会分配一个 IndexID，每一行分配一个 RowID（默认情况下，如果表使用整数型的 Primary Key，那么会用 Primary Key 的值当做 RowID）。其中 TableID 在整个集群内唯一，IndexID/RowID 在表内唯一，这些 ID 都是 int64 类型。 - -每行数据按照如下规则进行编码成 Key-Value pair： - -```text -Key: tablePrefix{tableID}_recordPrefixSep{rowID} -Value: [col1, col2, col3, col4] -``` - -其中 Key 的 `tablePrefix` 和 `recordPrefixSep` 都是特定的字符串常量，用于在 KV 空间内区分其他数据。 - -对于 Index 数据，会按照如下规则编码成 Key-Value pair： - -```text -Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue -Value: rowID -``` - -Index 数据还需要考虑 Unique Index 和非 Unique Index 两种情况，对于 Unique Index，可以按照上述编码规则。但是对于非 Unique Index，通过这种编码并不能构造出唯一的 Key，因为同一个 Index 的 `tablePrefix{tableID}_indexPrefixSep{indexID}` 都一样，可能有多行数据的 `ColumnsValue` 是一样的，所以对于非 Unique Index 的编码做了一点调整： - -```text -Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue_rowID -Value: null -``` - -### 表热点 - -从 TiDB 编码规则可知，同一个表的数据会在以表 ID 开头为前缀的一个 range 中，数据的顺序按照 RowID 的值顺序排列。在表 insert 的过程中如果 RowID 的值是递增的，则插入的行只能在末端追加。当 Region 达到一定的大小之后会进行分裂，分裂之后还是只能在 range 范围的末端追加，永远只能在一个 Region 上进行 insert 操作，形成热点。 - -常见的 increment 类型自增主键就是顺序递增的，默认情况下，在主键为整数型时，会用主键值当做 RowID，此时 RowID 为顺序递增，在大量 insert 时形成表的写入热点。 - -同时，TiDB 中 RowID 默认也按照自增的方式顺序递增，主键不为整数类型时，同样会遇到写入热点的问题。 - -此外，当写入或读取数据存在热点时，即出现新建表或分区的写入热点问题和只读场景下周期性读热点问题时，你可以使用表属性控制 Region 合并。具体的热点场景描述和解决方法可以查看[使用表属性控制 Region 合并的使用场景](/table-attributes.md#使用场景)。 - -### 索引热点 - -索引热点与表热点类似，常见的热点场景出现在时间顺序单调递增的字段，或者插入大量重复值的场景。 - -## 确定存在热点问题 - -性能问题不一定是热点造成的，也可能存在多个因素共同影响，在排查前需要先确认是否与热点相关。 - -- 判断写热点依据：打开监控面板 TiKV-Trouble-Shooting 中 Hot Write 面板，观察 Raftstore CPU 监控是否存在个别 TiKV 节点的指标明显高于其他节点的现象。 - -- 判断读热点依据：打开监控面板 TIKV-Details 中 Thread_CPU，查看 coprocessor cpu 有没有明显的某个 TiKV 特别高。 - -## 使用 TiDB Dashboard 定位热点表 - -[TiDB Dashboard](/dashboard/dashboard-intro.md) 中的[流量可视化](/dashboard/dashboard-key-visualizer.md)功能可帮助用户缩小热点排查范围到表级别。以下是流量可视化功能展示的一个热力图样例，该图横坐标是时间，纵坐标是各个表和索引，颜色越亮代表其流量越大。可在工具栏中切换显示读或写流量。 - -![Dashboard 示例1](/media/troubleshoot-hot-spot-issues-1.png) - -当图中写入流量图出现以下明亮斜线（斜向上或斜向下）时，由于写入只出现在末端，随着表 Region 数量变多，呈现出阶梯状。此时说明该表构成了写入热点： - -![Dashboard 示例2](/media/troubleshoot-hot-spot-issues-2.png) - -对于读热点，在热力图中一般表现为一条明亮的横线，通常是有大量访问的小表，如下图所示： - -![Dashboard 示例3](/media/troubleshoot-hot-spot-issues-3.png) - -将鼠标移到亮色块上，即可看到是什么表或索引具有大流量，如下图所示： - -![Dashboard 示例4](/media/troubleshoot-hot-spot-issues-4.png) - -## 使用 SHARD_ROW_ID_BITS 处理热点表 - -对于非聚簇索引主键或没有主键的表，TiDB 会使用一个隐式的自增 RowID，大量 `INSERT` 时会把数据集中写入单个 Region，造成写入热点。 - -通过设置 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)，可以把 RowID 打散写入多个不同的 Region，缓解写入热点问题。 - -``` -SHARD_ROW_ID_BITS = 4 表示 16 个分片 -SHARD_ROW_ID_BITS = 6 表示 64 个分片 -SHARD_ROW_ID_BITS = 0 表示默认值 1 个分片 -``` - -语句示例： - -```sql -CREATE TABLE：CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4; -ALTER TABLE：ALTER TABLE t SHARD_ROW_ID_BITS = 4; -``` - -`SHARD_ROW_ID_BITS` 的值可以动态修改，每次修改之后，只对新写入的数据生效。 - -对于含有 `CLUSTERED` 主键的表，TiDB 会使用表的主键作为 RowID，因为 `SHARD_ROW_ID_BITS` 会改变 RowID 生成规则，所以此时无法使用 `SHARD_ROW_ID_BITS` 选项。而对于使用 `NONCLUSTERED` 主键的表，TiDB 会使用自动分配的 64 位整数作为 RowID，此时也可以使用 `SHARD_ROW_ID_BITS` 特性。要了解关于 `CLUSTERED` 主键的详细信息，请参考[聚簇索引](/clustered-indexes.md)。 - -以下是两张无主键情况下使用 `SHARD_ROW_ID_BITS` 打散热点后的流量图，第一张展示了打散前的情况，第二张展示了打散后的情况。 - -![Dashboard 示例5](/media/troubleshoot-hot-spot-issues-5.png) - -![Dashboard 示例6](/media/troubleshoot-hot-spot-issues-6.png) - -从流量图可见，设置 `SHARD_ROW_ID_BITS` 后，流量热点由之前的只在一个 Region 上变得很分散。 - -## 使用 AUTO_RANDOM 处理自增主键热点表 - -使用 `AUTO_RANDOM` 处理自增主键热点表，适用于代替自增主键，解决自增主键带来的写入热点。 - -使用该功能后，将由 TiDB 生成随机分布且空间耗尽前不重复的主键，达到离散写入、打散写入热点的目的。 - -注意 TiDB 生成的主键不再是自增的主键，可使用 `LAST_INSERT_ID()` 获取上次分配的主键值。 - -将建表语句中的 `AUTO_INCREMENT` 改为 `AUTO_RANDOM` 即可使用该功能，适用于主键只需要保证唯一，不包含业务意义的场景。示例如下： - -{{< copyable "sql" >}} - -```sql -CREATE TABLE t (a BIGINT PRIMARY KEY AUTO_RANDOM, b varchar(255)); -INSERT INTO t (b) VALUES ("foo"); -SELECT * FROM t; -``` - -```sql -+------------+---+ -| a | b | -+------------+---+ -| 1073741825 | b | -+------------+---+ -``` - -{{< copyable "sql" >}} - -```sql -SELECT LAST_INSERT_ID(); -``` - -```sql -+------------------+ -| LAST_INSERT_ID() | -+------------------+ -| 1073741825 | -+------------------+ -``` - -以下是将 `AUTO_INCREMENT` 表改为 `AUTO_RANDOM` 打散热点后的流量图，第一张是 `AUTO_INCREMENT`，第二张是 `AUTO_RANDOM`。 - -![Dashboard 示例7](/media/troubleshoot-hot-spot-issues-7.png) - -![Dashboard 示例8](/media/troubleshoot-hot-spot-issues-8.png) - -由流量图可见，使用 `AUTO_RANDOM` 代替 `AUTO_INCREMENT` 能很好地打散热点。 - -更详细的说明参见 [`AUTO_RANDOM`](/auto-random.md) 文档。 - -## 小表热点的优化 - -TiDB 的 Coprocessor Cache 功能支持下推计算结果缓存。开启该功能后，将在 TiDB 实例侧缓存下推给 TiKV 计算的结果，对于小表读热点能起到比较好的效果。 - -更详细的说明参见[下推计算结果缓存](/coprocessor-cache.md#配置)文档。 - -**其他相关资料**： - -+ [TiDB 高并发写入场景最佳实践](/best-practices/high-concurrency-best-practices.md) -+ [Split Region 使用文档](/sql-statements/sql-statement-split-region.md) - -## 打散读热点 - -在读热点场景中，热点 TiKV 无法及时处理读请求，导致读请求排队。但是，此时并非所有 TiKV 资源都已耗尽。为了降低延迟，TiDB v7.1.0 引入了负载自适应副本读取功能，允许从其他 TiKV 节点读取副本，而无需在热点 TiKV 节点排队等待。你可以通过 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-从-v700-版本开始引入) 系统变量控制读请求的排队长度。当 leader 节点的预估排队时间超过该阈值时，TiDB 会优先从 follower 节点读取数据。在读热点的情况下，与不打散读热点相比，该功能可提高读取吞吐量 70%～200%。 +--- +title: TiDB 热点问题处理 +aliases: ['/docs-cn/dev/troubleshoot-hot-spot-issues/'] +summary: TiDB 热点问题处理：介绍定位和解决读写热点问题，包括常见热点场景、确定存在热点问题的方法、使用 TiDB Dashboard 定位热点表、使用 SHARD_ROW_ID_BITS 处理热点表、使用 AUTO_RANDOM 处理自增主键热点表、小表热点的优化、打散读热点。 +--- + +# TiDB 热点问题处理 + +本文介绍如何定位和解决读写热点问题。 + +TiDB 作为分布式数据库，内建负载均衡机制，尽可能将业务负载均匀地分布到不同计算或存储节点上，更好地利用上整体系统资源。然而，机制不是万能的，在一些场景下仍会有部分业务负载不能被很好地分散，影响性能，形成单点的过高负载，也称为热点。 + +TiDB 提供了完整的方案用于排查、解决或规避这类热点。通过均衡负载热点，可以提升整体性能，包括提高 QPS 和降低延迟等。 + +## 常见热点场景 + +### TiDB 编码规则回顾 + +TiDB 对每个表分配一个 TableID，每一个索引都会分配一个 IndexID，每一行分配一个 RowID（默认情况下，如果表使用整数型的 Primary Key，那么会用 Primary Key 的值当做 RowID）。其中 TableID 在整个集群内唯一，IndexID/RowID 在表内唯一，这些 ID 都是 int64 类型。 + +每行数据按照如下规则进行编码成 Key-Value pair： + +```text +Key: tablePrefix{tableID}_recordPrefixSep{rowID} +Value: [col1, col2, col3, col4] +``` + +其中 Key 的 `tablePrefix` 和 `recordPrefixSep` 都是特定的字符串常量，用于在 KV 空间内区分其他数据。 + +对于 Index 数据，会按照如下规则编码成 Key-Value pair： + +```text +Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue +Value: rowID +``` + +Index 数据还需要考虑 Unique Index 和非 Unique Index 两种情况，对于 Unique Index，可以按照上述编码规则。但是对于非 Unique Index，通过这种编码并不能构造出唯一的 Key，因为同一个 Index 的 `tablePrefix{tableID}_indexPrefixSep{indexID}` 都一样，可能有多行数据的 `ColumnsValue` 是一样的，所以对于非 Unique Index 的编码做了一点调整： + +```text +Key: tablePrefix{tableID}_indexPrefixSep{indexID}_indexedColumnsValue_rowID +Value: null +``` + +### 表热点 + +从 TiDB 编码规则可知，同一个表的数据会在以表 ID 开头为前缀的一个 range 中，数据的顺序按照 RowID 的值顺序排列。在表 insert 的过程中如果 RowID 的值是递增的，则插入的行只能在末端追加。当 Region 达到一定的大小之后会进行分裂，分裂之后还是只能在 range 范围的末端追加，永远只能在一个 Region 上进行 insert 操作，形成热点。 + +常见的 increment 类型自增主键就是顺序递增的，默认情况下，在主键为整数型时，会用主键值当做 RowID，此时 RowID 为顺序递增，在大量 insert 时形成表的写入热点。 + +同时，TiDB 中 RowID 默认也按照自增的方式顺序递增，主键不为整数类型时，同样会遇到写入热点的问题。 + +此外，当写入或读取数据存在热点时，即出现新建表或分区的写入热点问题和只读场景下周期性读热点问题时，你可以使用表属性控制 Region 合并。具体的热点场景描述和解决方法可以查看[使用表属性控制 Region 合并的使用场景](/table-attributes.md#使用场景)。 + +### 索引热点 + +索引热点与表热点类似，常见的热点场景出现在时间顺序单调递增的字段，或者插入大量重复值的场景。 + +## 确定存在热点问题 + +性能问题不一定是热点造成的，也可能存在多个因素共同影响，在排查前需要先确认是否与热点相关。 + +- 判断写热点依据：打开监控面板 TiKV-Trouble-Shooting 中 Hot Write 面板，观察 Raftstore CPU 监控是否存在个别 TiKV 节点的指标明显高于其他节点的现象。 + +- 判断读热点依据：打开监控面板 TIKV-Details 中 Thread_CPU，查看 coprocessor cpu 有没有明显的某个 TiKV 特别高。 + +## 使用 TiDB Dashboard 定位热点表 + +[TiDB Dashboard](/dashboard/dashboard-intro.md) 中的[流量可视化](/dashboard/dashboard-key-visualizer.md)功能可帮助用户缩小热点排查范围到表级别。以下是流量可视化功能展示的一个热力图样例，该图横坐标是时间，纵坐标是各个表和索引，颜色越亮代表其流量越大。可在工具栏中切换显示读或写流量。 + +![Dashboard 示例1](/media/troubleshoot-hot-spot-issues-1.png) + +当图中写入流量图出现以下明亮斜线（斜向上或斜向下）时，由于写入只出现在末端，随着表 Region 数量变多，呈现出阶梯状。此时说明该表构成了写入热点： + +![Dashboard 示例2](/media/troubleshoot-hot-spot-issues-2.png) + +对于读热点，在热力图中一般表现为一条明亮的横线，通常是有大量访问的小表，如下图所示： + +![Dashboard 示例3](/media/troubleshoot-hot-spot-issues-3.png) + +将鼠标移到亮色块上，即可看到是什么表或索引具有大流量，如下图所示： + +![Dashboard 示例4](/media/troubleshoot-hot-spot-issues-4.png) + +## 使用 SHARD_ROW_ID_BITS 处理热点表 + +对于非聚簇索引主键或没有主键的表，TiDB 会使用一个隐式的自增 RowID，大量 `INSERT` 时会把数据集中写入单个 Region，造成写入热点。 + +通过设置 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)，可以把 RowID 打散写入多个不同的 Region，缓解写入热点问题。 + +``` +SHARD_ROW_ID_BITS = 4 表示 16 个分片 +SHARD_ROW_ID_BITS = 6 表示 64 个分片 +SHARD_ROW_ID_BITS = 0 表示默认值 1 个分片 +``` + +语句示例： + +```sql +CREATE TABLE：CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4; +ALTER TABLE：ALTER TABLE t SHARD_ROW_ID_BITS = 4; +``` + +`SHARD_ROW_ID_BITS` 的值可以动态修改，每次修改之后，只对新写入的数据生效。 + +对于含有 `CLUSTERED` 主键的表，TiDB 会使用表的主键作为 RowID，因为 `SHARD_ROW_ID_BITS` 会改变 RowID 生成规则，所以此时无法使用 `SHARD_ROW_ID_BITS` 选项。而对于使用 `NONCLUSTERED` 主键的表，TiDB 会使用自动分配的 64 位整数作为 RowID，此时也可以使用 `SHARD_ROW_ID_BITS` 特性。要了解关于 `CLUSTERED` 主键的详细信息，请参考[聚簇索引](/clustered-indexes.md)。 + +以下是两张无主键情况下使用 `SHARD_ROW_ID_BITS` 打散热点后的流量图，第一张展示了打散前的情况，第二张展示了打散后的情况。 + +![Dashboard 示例5](/media/troubleshoot-hot-spot-issues-5.png) + +![Dashboard 示例6](/media/troubleshoot-hot-spot-issues-6.png) + +从流量图可见，设置 `SHARD_ROW_ID_BITS` 后，流量热点由之前的只在一个 Region 上变得很分散。 + +## 使用 AUTO_RANDOM 处理自增主键热点表 + +使用 `AUTO_RANDOM` 处理自增主键热点表，适用于代替自增主键，解决自增主键带来的写入热点。 + +使用该功能后，将由 TiDB 生成随机分布且空间耗尽前不重复的主键，达到离散写入、打散写入热点的目的。 + +注意 TiDB 生成的主键不再是自增的主键，可使用 `LAST_INSERT_ID()` 获取上次分配的主键值。 + +将建表语句中的 `AUTO_INCREMENT` 改为 `AUTO_RANDOM` 即可使用该功能，适用于主键只需要保证唯一，不包含业务意义的场景。示例如下： + +{{< copyable "sql" >}} + +```sql +CREATE TABLE t (a BIGINT PRIMARY KEY AUTO_RANDOM, b varchar(255)); +INSERT INTO t (b) VALUES ("foo"); +SELECT * FROM t; +``` + +```sql ++------------+---+ +| a | b | ++------------+---+ +| 1073741825 | b | ++------------+---+ +``` + +{{< copyable "sql" >}} + +```sql +SELECT LAST_INSERT_ID(); +``` + +```sql ++------------------+ +| LAST_INSERT_ID() | ++------------------+ +| 1073741825 | ++------------------+ +``` + +以下是将 `AUTO_INCREMENT` 表改为 `AUTO_RANDOM` 打散热点后的流量图，第一张是 `AUTO_INCREMENT`，第二张是 `AUTO_RANDOM`。 + +![Dashboard 示例7](/media/troubleshoot-hot-spot-issues-7.png) + +![Dashboard 示例8](/media/troubleshoot-hot-spot-issues-8.png) + +由流量图可见，使用 `AUTO_RANDOM` 代替 `AUTO_INCREMENT` 能很好地打散热点。 + +更详细的说明参见 [`AUTO_RANDOM`](/auto-random.md) 文档。 + +## 小表热点的优化 + +TiDB 的 Coprocessor Cache 功能支持下推计算结果缓存。开启该功能后，将在 TiDB 实例侧缓存下推给 TiKV 计算的结果，对于小表读热点能起到比较好的效果。 + +更详细的说明参见[下推计算结果缓存](/coprocessor-cache.md#配置)文档。 + +**其他相关资料**： + ++ [TiDB 高并发写入场景最佳实践](/best-practices/high-concurrency-best-practices.md) ++ [Split Region 使用文档](/sql-statements/sql-statement-split-region.md) + +## 打散读热点 + +在读热点场景中，热点 TiKV 无法及时处理读请求，导致读请求排队。但是，此时并非所有 TiKV 资源都已耗尽。为了降低延迟，TiDB v7.1.0 引入了负载自适应副本读取功能，允许从其他 TiKV 节点读取副本，而无需在热点 TiKV 节点排队等待。你可以通过 [`tidb_load_based_replica_read_threshold`](/system-variables.md#tidb_load_based_replica_read_threshold-从-v700-版本开始引入) 系统变量控制读请求的排队长度。当 leader 节点的预估排队时间超过该阈值时，TiDB 会优先从 follower 节点读取数据。在读热点的情况下，与不打散读热点相比，该功能可提高读取吞吐量 70%～200%。