test0308: v2 #8
Open
test0308: v2 #8
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
|
||
| ### end-point-memory-quota <span class="version-mark">从 v8.2.0 版本开始引入</span> | ||
|
|
||
| * TiKV Coproccessor 请求可以使用的内存上限，超过该值后后续的 Coprocessor 请求将被拒绝并报错（server is busy）。 |
There was a problem hiding this comment.
该句描述不够清晰，建议明确说明 end-point-memory-quota 的具体作用和使用场景，以便用户更好地理解其功能。
Suggested change
| * TiKV Coproccessor 请求可以使用的内存上限，超过该值后后续的 Coprocessor 请求将被拒绝并报错（server is busy）。 | |
| * TiKV Coprocessor 请求可以使用的内存上限，超过该值后，后续的 Coprocessor 请求将被拒绝并返回 `server is busy` 错误。该配置项用于控制 Coprocessor 请求的内存使用，避免因内存占用过高而影响系统稳定性。 |
| ## txn-status-cache-capacity <span class="version-mark">从 v7.6.0 版本开始引入</span> | ||
|
|
||
| + 设置 TiKV 内的事务状态 cache 的容量。不建议用户随意修改。 |
There was a problem hiding this comment.
该句表述不够清晰，建议明确说明 txn-status-cache-capacity 的作用和影响，以便用户理解为什么不建议随意修改。
Suggested change
| + 设置 TiKV 内的事务状态 cache 的容量。不建议用户随意修改。 | |
| + 设置 TiKV 内的事务状态缓存（Transaction Status Cache）的容量。该缓存用于加速事务状态的查询，修改此值可能会影响 TiKV 的性能和内存使用，因此不建议用户随意修改。 |
|
|
||
| ### follower-read-max-log-gap <span class="version-mark">从 v7.4.0 版本开始引入</span> | ||
|
|
||
| + follower 处理读请求时允许的最大日志落后数目，超出则拒绝读请求。 |
There was a problem hiding this comment.
该描述不够清晰，建议明确说明“日志落后数目”是指 Raft 日志的落后数目，并补充其影响。
Suggested change
| + follower 处理读请求时允许的最大日志落后数目，超出则拒绝读请求。 | |
| + follower 处理读请求时允许的最大 Raft 日志落后数目，超出则拒绝读请求。该配置用于控制 follower 读请求的延迟容忍度。 |
|
|
||
| ### inspect-cpu-util-thd <span class="version-mark">从 v7.6.0 版本开始引入</span> | ||
|
|
||
| + TiKV 进行慢节点检测时判定节点 CPU 是否处于繁忙状态的阈值。范围 [0%, 100%]。 |
There was a problem hiding this comment.
建议补充说明“慢节点检测”的具体含义，以及该配置项的作用场景。
Suggested change
| + TiKV 进行慢节点检测时判定节点 CPU 是否处于繁忙状态的阈值。范围 [0%, 100%]。 | |
| + TiKV 进行慢节点检测时判定节点 CPU 是否处于繁忙状态的阈值。范围 [0%, 100%]。当节点 CPU 使用率超过该阈值时，TiKV 会将其标记为慢节点。 |
|
|
||
| ### inspect-kvdb-interval <span class="version-mark">从 v8.1.2 版本开始引入</span> | ||
|
|
||
| + TiKV 进行慢节点检测时检查 KV 盘的间隔和超时时间。如果 KVDB 和 RaftDB 使用相同的挂载路径，该值将被覆盖为 0（不检测）。 |
There was a problem hiding this comment.
该描述中“KV 盘”的表述不够准确，建议改为“KVDB 存储设备”。
Suggested change
| + TiKV 进行慢节点检测时检查 KV 盘的间隔和超时时间。如果 KVDB 和 RaftDB 使用相同的挂载路径，该值将被覆盖为 0（不检测）。 | |
| + TiKV 进行慢节点检测时检查 KVDB 存储设备的间隔和超时时间。如果 KVDB 和 RaftDB 使用相同的挂载路径，该值将被覆盖为 0（不检测）。 |
|
|
||
| ### slow-trend-unsensitive-result <span class="version-mark">从 v6.6.0 版本开始引入</span> | ||
|
|
||
| + TiKV 采用 SlowStrend 检测算法时，QPS 侧检测的敏感性。值越高表示敏感度越低。 |
There was a problem hiding this comment.
该描述中的“SlowStrend”存在拼写错误，应为“SlowTrend”。
Suggested change
| + TiKV 采用 SlowStrend 检测算法时，QPS 侧检测的敏感性。值越高表示敏感度越低。 | |
| + TiKV 采用 SlowTrend 检测算法时，QPS 侧检测的敏感度。值越高表示敏感度越低。 |
| ### enable-multi-batch-write <span class="version-mark">从 v6.2.0 版本开始引入</span> | ||
|
|
||
| + 开启 RocksDB 写入优化，将 WriteBatch 中的内容并发写入到 memtable 中，缩短写入耗时。 | ||
| + 默认值：无，但在默认情况下会自动开启，除非手动设置成 false 或者开启 `rocksdb.enable-pipelined-write` 或 `rocksdb.enable-unordered-write`。 |
There was a problem hiding this comment.
默认值的描述不够清晰，容易引起误解。建议明确说明默认行为，并解释与其他配置项的关系。
Suggested change
| + 默认值：无，但在默认情况下会自动开启，除非手动设置成 false 或者开启 `rocksdb.enable-pipelined-write` 或 `rocksdb.enable-unordered-write`。 | |
| + 默认值：无，但在默认情况下会自动开启，除非手动设置成 `false` 或者同时开启了 `rocksdb.enable-pipelined-write` 或 `rocksdb.enable-unordered-write`。 |
| ## rocksdb.defaultcf | rocksdb.writecf | rocksdb.lockcf | ||
| ## rocksdb.defaultcf | rocksdb.writecf | rocksdb.lockcf | rocksdb.raftcf | ||
|
|
||
| rocksdb defaultcf、rocksdb writecf 和 rocksdb lockcf 相关的配置项。 |
There was a problem hiding this comment.
该行描述中未提及 rocksdb.raftcf，与新增的配置项不一致，建议补充说明。
Suggested change
| rocksdb defaultcf、rocksdb writecf 和 rocksdb lockcf 相关的配置项。 | |
| rocksdb defaultcf、rocksdb writecf、rocksdb lockcf 和 rocksdb raftcf 相关的配置项。 |
|
|
||
| ### `max-compactions` <span class="version-mark">从 v6.6.0 版本开始引入</span> | ||
|
|
||
| + 最大 compaction 任务并发数。0 表示不限制。 |
There was a problem hiding this comment.
该描述不够清晰，建议明确说明 max-compactions 的具体作用范围或场景，以便用户更好地理解其用途。
Suggested change
| + 最大 compaction 任务并发数。0 表示不限制。 | |
| + 最大 compaction 任务并发数。0 表示不限制。该配置项适用于所有 RocksDB 实例的 compaction 任务。 |
|
|
||
| ### `compression-level` <span class="version-mark">从 v7.4.0 版本开始引入</span> | ||
|
|
||
| + 设置 raft-engine 在写 raft log 文件时所采用的 lz4 压缩算法的压缩效率，范围 [1, 16]，越低压缩速率越高，但压缩率越低。 |
There was a problem hiding this comment.
该句描述不够清晰，建议明确说明压缩效率和压缩率的关系，并补充对默认值的解释。
Suggested change
| + 设置 raft-engine 在写 raft log 文件时所采用的 lz4 压缩算法的压缩效率，范围 [1, 16]，越低压缩速率越高，但压缩率越低。 | |
| + 设置 raft-engine 在写 raft log 文件时所采用的 lz4 压缩算法的压缩效率，范围 [1, 16]。数值越低，压缩速率越高，但压缩率越低；数值越高，压缩速率越低，但压缩率越高。默认值 `1` 表示优先考虑压缩速率。 |
|
|
||
| ## TiDB DDL 是否支持 DDL 语句间并行？具体的一些运行特征是怎样的？ | ||
|
|
||
| 在 TiDB v6.2 之后，TiDB 提供并发 DDL（concurrent DDL） 执行的能力。 并发 DDL 主要是提供 DDL 语句间的并发执行支持。这里和以前的 DDL 执行将会发生如下变化： |
There was a problem hiding this comment.
该句中的“并发 DDL（concurrent DDL）”表述不够清晰，建议明确说明并发 DDL 的具体含义。
Suggested change
| 在 TiDB v6.2 之后，TiDB 提供并发 DDL（concurrent DDL） 执行的能力。 并发 DDL 主要是提供 DDL 语句间的并发执行支持。这里和以前的 DDL 执行将会发生如下变化： | |
| 在 TiDB v6.2 之后，TiDB 提供了并发 DDL（concurrent DDL）执行的能力，即允许多个 DDL 语句在没有依赖关系的情况下并行执行。 |
|
|
||
| 在 TiDB v6.2 之后，TiDB 提供并发 DDL（concurrent DDL） 执行的能力。 并发 DDL 主要是提供 DDL 语句间的并发执行支持。这里和以前的 DDL 执行将会发生如下变化： | ||
|
|
||
| 1. 需要判断 DDL 语句间是否有相关性，如果有相关性的 DDL 语句将会按照进入 TiDB 的顺序执行，没有相关性的 DDL 语句可以并发执行。并发判断规则： |
There was a problem hiding this comment.
该句中的“相关性”表述不够明确，建议进一步解释什么是 DDL 语句间的相关性。
Suggested change
| 1. 需要判断 DDL 语句间是否有相关性，如果有相关性的 DDL 语句将会按照进入 TiDB 的顺序执行，没有相关性的 DDL 语句可以并发执行。并发判断规则： | |
| 1. 需要判断 DDL 语句间是否有依赖关系（例如，是否操作相同的表或 Schema），如果有依赖关系的 DDL 语句将会按照进入 TiDB 的顺序执行，没有依赖关系的 DDL 语句可以并发执行。并发判断规则： |
|
|
||
| 1. 需要判断 DDL 语句间是否有相关性，如果有相关性的 DDL 语句将会按照进入 TiDB 的顺序执行，没有相关性的 DDL 语句可以并发执行。并发判断规则： | ||
| 1. 相同表上的 DDL 语句之间具有相关性，需要按照进入 TiDB 的顺序执行； | ||
| 2. 对于 Schema 上的操作，可能会对于 schema 中的表上的 DDL 语句建立相关性，目前 Drop Schema 会对于其包含 Schema 上的 DDL 产生相关性；也需要顺序执行； |
There was a problem hiding this comment.
该句中的“建立相关性”表述不够清晰，建议明确说明 Drop Schema 操作如何影响其他 DDL 语句的执行顺序。
Suggested change
| 2. 对于 Schema 上的操作，可能会对于 schema 中的表上的 DDL 语句建立相关性，目前 Drop Schema 会对于其包含 Schema 上的 DDL 产生相关性；也需要顺序执行； | |
| 2. 对于 Schema 上的操作，可能会影响 Schema 中表上的 DDL 语句的执行顺序。例如，Drop Schema 操作会对其包含的表上的 DDL 语句产生依赖关系，因此需要顺序执行。 |
| 1. 相同表上的 DDL 语句之间具有相关性，需要按照进入 TiDB 的顺序执行； | ||
| 2. 对于 Schema 上的操作，可能会对于 schema 中的表上的 DDL 语句建立相关性，目前 Drop Schema 会对于其包含 Schema 上的 DDL 产生相关性；也需要顺序执行； | ||
| 2. 是否所有的 DDL 语句都会并发执行？ | ||
| 当前，答案是否定的，在 TiDB 中 DDL 语句被分为两类， |
There was a problem hiding this comment.
该句中的“当前，答案是否定的”表述不够正式，建议修改为更专业的表达方式。
Suggested change
| 当前，答案是否定的，在 TiDB 中 DDL 语句被分为两类， | |
| 当前，并非所有 DDL 语句都支持并发执行。 |
| 2. 是否所有的 DDL 语句都会并发执行？ | ||
| 当前，答案是否定的，在 TiDB 中 DDL 语句被分为两类， | ||
| 1. 普通（general）DDL 语句，这类 DDL 语句的执行只需要修改对象的元数据，不需要操作 schema 存储的数据，通常在秒级完成；需要的计算资源相对少； | ||
| 2. 需要重组（reorg）DDL 语句， 这类 DDL 语句的执行不仅需要修改对象的元数据，也需要对于 schema 存储的数据进行处理，例如：加索引，需要扫描全表数据，来创建索引，需要比较多的计算资源与较长的执行时间； |
There was a problem hiding this comment.
该句中的“需要重组（reorg）DDL 语句”表述不够清晰，建议进一步解释什么是“重组 DDL 语句”。
Suggested change
| 2. 需要重组（reorg）DDL 语句， 这类 DDL 语句的执行不仅需要修改对象的元数据，也需要对于 schema 存储的数据进行处理，例如：加索引，需要扫描全表数据，来创建索引，需要比较多的计算资源与较长的执行时间； | |
| 2. 需要重组（reorg）DDL 语句，这类 DDL 语句不仅需要修改对象的元数据，还需要对 Schema 存储的数据进行处理。例如，加索引操作需要扫描全表数据来创建索引，因此需要较多的计算资源和较长的执行时间。 |
| 从 TiDB v6.3 开始，我们为 TiDB 用户提供了 快速加索引的模式，可以相对于 v6.1 提升 10倍的速度。我们在 TiDB v6.5 快速加索引模式已经 GA。 | ||
| 这里说明一下从低版本升级上来，的一些检查事项： | ||
| **TiDB 配置参数**： | ||
| - [`temp-dir`](/tidb-configuration-file#temp-dir-new-in-v630) 这个参数用来指定快速加索引模式执行本地磁盘路径。 |
There was a problem hiding this comment.
该句中的“On Premises 用户”表述不够清晰，建议明确说明“On Premises”的含义。
Suggested change
| - [`temp-dir`](/tidb-configuration-file#temp-dir-new-in-v630) 这个参数用来指定快速加索引模式执行本地磁盘路径。 | |
| - 对于本地部署（On Premises）用户，需要用户提前挂载好 SSD 磁盘，配置好相应路径，然后进行升级操作，重启后检查 TiDB。 |
| 3 rows in set (0.52 sec) | ||
| ``` | ||
| **注意：** 这个是一个配置参数，需要重启 TiDB 节点，上面 `Value` 字段查询出来值应该和用户设置的值应该一致。 | ||
| - 对于 Cloud 用户，我们对于能够使用快速加索引功能的使用有一些限制： |
There was a problem hiding this comment.
该句中的“Cloud 用户”表述不够清晰，建议明确说明“Cloud 用户”的具体含义。
Suggested change
| - 对于 Cloud 用户，我们对于能够使用快速加索引功能的使用有一些限制： | |
| - 对于云服务（Cloud）用户，我们对于能够使用快速加索引功能的使用有一些限制： |
| **注意：** 这个是一个配置参数，需要重启 TiDB 节点，上面 `Value` 字段查询出来值应该和用户设置的值应该一致。 | ||
| - 对于 Cloud 用户，我们对于能够使用快速加索引功能的使用有一些限制： | ||
|
|
||
| | 描述 | 供应商 | TiDB CPU 规格 | 是否支持快速索引模式 | 备注 | |
There was a problem hiding this comment.
表格中的“供应商”列表述不够清晰，建议明确说明“供应商”指的是云服务提供商。
Suggested change
| | 描述 | 供应商 | TiDB CPU 规格 | 是否支持快速索引模式 | 备注 | | |
| | 描述 | 云服务提供商 | TiDB CPU 规格 | 是否支持快速索引模式 | 备注 | |
| | | GCP | ALL | 不支持 | | | ||
|
|
||
| TiDB 系统变量设置 | ||
| - [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-从-v630-版本开始引入) |
There was a problem hiding this comment.
该句中的“默认打开”表述不够正式，建议修改为更专业的表达方式。
Suggested change
| - [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-从-v630-版本开始引入) | |
| 这个系统变量在 TiDB v6.5 中默认启用。 |
| - [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-从-v630-版本开始引入) | ||
| 这个系统变量在 TiDB v6.5 默认打开。 | ||
| - [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-从-v630-版本开始引入) | ||
| 这个系统变量用来控制快速加索引方式本地磁盘能够使用的限额，对于 on Premises 用户来说可以根据实际情况增加这个值。 No newline at end of file |
There was a problem hiding this comment.
该句中的“on Premises 用户”表述不够清晰，建议明确说明“on Premises”的含义。
Suggested change
| 这个系统变量用来控制快速加索引方式本地磁盘能够使用的限额，对于 on Premises 用户来说可以根据实际情况增加这个值。 | |
| 这个系统变量用来控制快速加索引方式本地磁盘能够使用的限额，对于本地部署（on Premises）用户来说，可以根据实际情况增加这个值。 |
|
|
||
| ## TiDB DDL 是否支持 DDL 语句间并行？具体的一些运行特征是怎样的？ | ||
|
|
||
| 在 TiDB v6.2 之后，TiDB 提供并发 DDL（concurrent DDL） 执行的能力。 并发 DDL 主要是提供 DDL 语句间的并发执行支持。这里和以前的 DDL 执行将会发生如下变化： |
There was a problem hiding this comment.
句子结构不够清晰，建议拆分并明确说明并发 DDL 的执行条件。
Suggested change
| 在 TiDB v6.2 之后，TiDB 提供并发 DDL（concurrent DDL） 执行的能力。 并发 DDL 主要是提供 DDL 语句间的并发执行支持。这里和以前的 DDL 执行将会发生如下变化： | |
| 在 TiDB v6.2 之后，TiDB 提供了并发 DDL（concurrent DDL）执行的能力。并发 DDL 主要支持 DDL 语句间的并发执行。与之前的 DDL 执行相比，主要变化如下： |
|
|
||
| 在 TiDB v6.2 之后，TiDB 提供并发 DDL（concurrent DDL） 执行的能力。 并发 DDL 主要是提供 DDL 语句间的并发执行支持。这里和以前的 DDL 执行将会发生如下变化： | ||
|
|
||
| 1. 需要判断 DDL 语句间是否有相关性，如果有相关性的 DDL 语句将会按照进入 TiDB 的顺序执行，没有相关性的 DDL 语句可以并发执行。并发判断规则： |
There was a problem hiding this comment.
句子结构复杂，建议简化并明确相关性判断规则。
Suggested change
| 1. 需要判断 DDL 语句间是否有相关性，如果有相关性的 DDL 语句将会按照进入 TiDB 的顺序执行，没有相关性的 DDL 语句可以并发执行。并发判断规则： | |
| 1. 需要判断 DDL 语句间是否有相关性。如果有相关性，DDL 语句将按照进入 TiDB 的顺序执行；如果没有相关性，则可以并发执行。相关性判断规则如下： |
| 2. 对于 Schema 上的操作，可能会对于 schema 中的表上的 DDL 语句建立相关性，目前 Drop Schema 会对于其包含 Schema 上的 DDL 产生相关性；也需要顺序执行； | ||
| 2. 是否所有的 DDL 语句都会并发执行？ | ||
| 当前，答案是否定的，在 TiDB 中 DDL 语句被分为两类， | ||
| 1. 普通（general）DDL 语句，这类 DDL 语句的执行只需要修改对象的元数据，不需要操作 schema 存储的数据，通常在秒级完成；需要的计算资源相对少； |
There was a problem hiding this comment.
句子结构不够清晰，建议拆分并明确 DDL 分类。
Suggested change
| 1. 普通（general）DDL 语句，这类 DDL 语句的执行只需要修改对象的元数据，不需要操作 schema 存储的数据，通常在秒级完成；需要的计算资源相对少； | |
| 当前，TiDB 中的 DDL 语句分为两类： |
| 1. 普通（general）DDL 语句，这类 DDL 语句的执行只需要修改对象的元数据，不需要操作 schema 存储的数据，通常在秒级完成；需要的计算资源相对少； | ||
| 2. 需要重组（reorg）DDL 语句， 这类 DDL 语句的执行不仅需要修改对象的元数据，也需要对于 schema 存储的数据进行处理，例如：加索引，需要扫描全表数据，来创建索引，需要比较多的计算资源与较长的执行时间； | ||
| 当前我们仅对于需要重组的 DDL 语句启动了并发执行支持。 | ||
| 3. 对于启动了并发 DDL 语句支持的 TiDB 集群，DDL 语句间的并发度是如何确定的？ |
There was a problem hiding this comment.
句子结构不够清晰，建议明确并发度的确定方式。
Suggested change
| 3. 对于启动了并发 DDL 语句支持的 TiDB 集群，DDL 语句间的并发度是如何确定的？ | |
| 对于启用了并发 DDL 的 TiDB 集群，DDL 语句的并发度确定方式如下： |
| TiDB DDL owner 节点容器能够使用的 CPU 资源数量的 1/4 与 1 之间的最大值，例如 8C 规格的 TiDB DDL owner 节点，并发度将会是 2。 | ||
|
|
||
| ## TiDB DDL 的优先级如何定义? | ||
| 由于 DDL 语句，特别是需要重组的 DDL 语句在执行的过程中可能会占用较多计算或者存储引擎资源，从而导致对于前端用户业务的影响。通过对 DDL 任务设置 |
There was a problem hiding this comment.
句子结构不够清晰，建议明确优先级设置的目的。
Suggested change
| 由于 DDL 语句，特别是需要重组的 DDL 语句在执行的过程中可能会占用较多计算或者存储引擎资源，从而导致对于前端用户业务的影响。通过对 DDL 任务设置 | |
| 由于 DDL 语句，特别是需要重组的 DDL 语句，可能会占用较多的计算或存储引擎资源，从而影响前端用户业务。因此，可以通过设置 DDL 任务的优先级来减少对集群资源的争抢。 |
| - [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) | ||
|
|
||
| ## 快速加索引方式的启动常见问题： | ||
| 从 TiDB v6.3 开始，我们为 TiDB 用户提供了 快速加索引的模式，可以相对于 v6.1 提升 10倍的速度。我们在 TiDB v6.5 快速加索引模式已经 GA。 |
There was a problem hiding this comment.
句子结构不够清晰，建议明确快速加索引模式的版本支持。
Suggested change
| 从 TiDB v6.3 开始，我们为 TiDB 用户提供了 快速加索引的模式，可以相对于 v6.1 提升 10倍的速度。我们在 TiDB v6.5 快速加索引模式已经 GA。 | |
| 从 TiDB v6.3 开始，TiDB 提供了快速加索引模式，相较于 v6.1，速度提升了 10 倍。在 TiDB v6.5 中，快速加索引模式已经 GA。 |
|
|
||
| ## 快速加索引方式的启动常见问题： | ||
| 从 TiDB v6.3 开始，我们为 TiDB 用户提供了 快速加索引的模式，可以相对于 v6.1 提升 10倍的速度。我们在 TiDB v6.5 快速加索引模式已经 GA。 | ||
| 这里说明一下从低版本升级上来，的一些检查事项： |
There was a problem hiding this comment.
句子结构不够清晰，建议明确升级时的检查事项。
Suggested change
| 这里说明一下从低版本升级上来，的一些检查事项： | |
| 以下是从低版本升级时需要注意的检查事项： |
| 3 rows in set (0.52 sec) | ||
| ``` | ||
| **注意：** 这个是一个配置参数，需要重启 TiDB 节点，上面 `Value` 字段查询出来值应该和用户设置的值应该一致。 | ||
| - 对于 Cloud 用户，我们对于能够使用快速加索引功能的使用有一些限制： |
There was a problem hiding this comment.
句子结构不够清晰，建议明确 Cloud 用户的限制条件。
Suggested change
| - 对于 Cloud 用户，我们对于能够使用快速加索引功能的使用有一些限制： | |
| 对于 Cloud 用户，使用快速加索引功能有以下限制： |
|
|
||
| ## TiDB DDL 是否支持 DDL 语句间并行？具体的一些运行特征是怎样的？ | ||
|
|
||
| 在 TiDB v6.2 之后，TiDB 提供并发 DDL（concurrent DDL） 执行的能力。 并发 DDL 主要是提供 DDL 语句间的并发执行支持。这里和以前的 DDL 执行将会发生如下变化： |
There was a problem hiding this comment.
句子结构不够清晰，建议明确说明并发 DDL 的执行条件及其变化。
Suggested change
| 在 TiDB v6.2 之后，TiDB 提供并发 DDL（concurrent DDL） 执行的能力。 并发 DDL 主要是提供 DDL 语句间的并发执行支持。这里和以前的 DDL 执行将会发生如下变化： | |
| 在 TiDB v6.2 之后，TiDB 提供了并发 DDL（concurrent DDL）执行的能力，支持 DDL 语句间的并发执行。与之前的 DDL 执行相比，主要变化如下： |
|
|
||
| 在 TiDB v6.2 之后，TiDB 提供并发 DDL（concurrent DDL） 执行的能力。 并发 DDL 主要是提供 DDL 语句间的并发执行支持。这里和以前的 DDL 执行将会发生如下变化： | ||
|
|
||
| 1. 需要判断 DDL 语句间是否有相关性，如果有相关性的 DDL 语句将会按照进入 TiDB 的顺序执行，没有相关性的 DDL 语句可以并发执行。并发判断规则： |
There was a problem hiding this comment.
相关性判断的描述不够简洁，建议简化并明确相关性规则。
Suggested change
| 1. 需要判断 DDL 语句间是否有相关性，如果有相关性的 DDL 语句将会按照进入 TiDB 的顺序执行，没有相关性的 DDL 语句可以并发执行。并发判断规则： | |
| 1. 判断 DDL 语句间是否存在相关性：如果存在相关性，DDL 语句将按照进入 TiDB 的顺序执行；如果没有相关性，则可以并发执行。相关性判断规则如下： |
| 当前我们仅对于需要重组的 DDL 语句启动了并发执行支持。 | ||
| 3. 对于启动了并发 DDL 语句支持的 TiDB 集群，DDL 语句间的并发度是如何确定的？ | ||
| 目前因为 DDL 等后台任务的执行可能会占用相当的资源，因此我们采取了一个相对保守的策略来确定 DDL 语句执行的并发度 | ||
| 1. 对于普通 DDL（general DDL） 语句，我们当前语句并发度为 1（后续将会提供并发执行支持）； |
There was a problem hiding this comment.
并发度的描述不够清晰，建议明确说明并发度的计算方式及其限制。
Suggested change
| 1. 对于普通 DDL（general DDL） 语句，我们当前语句并发度为 1（后续将会提供并发执行支持）； | |
| 1. 对于普通 DDL（general DDL）语句，当前并发度为 1（后续将支持并发执行）； |
| 目前因为 DDL 等后台任务的执行可能会占用相当的资源，因此我们采取了一个相对保守的策略来确定 DDL 语句执行的并发度 | ||
| 1. 对于普通 DDL（general DDL） 语句，我们当前语句并发度为 1（后续将会提供并发执行支持）； | ||
| 2. 对于需要重组的 DDL（Reorg DDL）语句，我们的并发度设置规则如下（并发度不允许用户自己设置）： | ||
| TiDB DDL owner 节点容器能够使用的 CPU 资源数量的 1/4 与 1 之间的最大值，例如 8C 规格的 TiDB DDL owner 节点，并发度将会是 2。 |
There was a problem hiding this comment.
并发度计算规则的描述不够直观，建议简化并明确计算公式。
Suggested change
| TiDB DDL owner 节点容器能够使用的 CPU 资源数量的 1/4 与 1 之间的最大值，例如 8C 规格的 TiDB DDL owner 节点，并发度将会是 2。 | |
| 2. 对于需要重组的 DDL（Reorg DDL）语句，并发度设置为 TiDB DDL owner 节点容器可用 CPU 资源的 1/4 与 1 之间的最大值。例如，8C 规格的 TiDB DDL owner 节点，并发度为 2。 |
| TiDB DDL owner 节点容器能够使用的 CPU 资源数量的 1/4 与 1 之间的最大值，例如 8C 规格的 TiDB DDL owner 节点，并发度将会是 2。 | ||
|
|
||
| ## TiDB DDL 的优先级如何定义? | ||
| 由于 DDL 语句，特别是需要重组的 DDL 语句在执行的过程中可能会占用较多计算或者存储引擎资源，从而导致对于前端用户业务的影响。通过对 DDL 任务设置 |
There was a problem hiding this comment.
句子结构不够清晰，建议明确说明 DDL 优先级的作用及其设置方式。
Suggested change
| 由于 DDL 语句，特别是需要重组的 DDL 语句在执行的过程中可能会占用较多计算或者存储引擎资源，从而导致对于前端用户业务的影响。通过对 DDL 任务设置 | |
| 由于 DDL 语句（特别是需要重组的 DDL 语句）可能会占用大量计算或存储资源，从而影响前端用户业务。可以通过以下系统变量设置 DDL 任务的优先级： |
| - [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) | ||
|
|
||
| ## 快速加索引方式的启动常见问题： | ||
| 从 TiDB v6.3 开始，我们为 TiDB 用户提供了 快速加索引的模式，可以相对于 v6.1 提升 10倍的速度。我们在 TiDB v6.5 快速加索引模式已经 GA。 |
There was a problem hiding this comment.
快速加索引的描述不够简洁，建议简化并明确其优势。
Suggested change
| 从 TiDB v6.3 开始，我们为 TiDB 用户提供了 快速加索引的模式，可以相对于 v6.1 提升 10倍的速度。我们在 TiDB v6.5 快速加索引模式已经 GA。 | |
| 从 TiDB v6.3 开始，TiDB 提供了快速加索引模式，相较于 v6.1，速度提升了 10 倍。在 TiDB v6.5 中，快速加索引模式已正式发布（GA）。 |
|
|
||
| ## 快速加索引方式的启动常见问题： | ||
| 从 TiDB v6.3 开始，我们为 TiDB 用户提供了 快速加索引的模式，可以相对于 v6.1 提升 10倍的速度。我们在 TiDB v6.5 快速加索引模式已经 GA。 | ||
| 这里说明一下从低版本升级上来，的一些检查事项： |
There was a problem hiding this comment.
升级检查事项的描述不够清晰，建议明确说明升级前后的注意事项。
Suggested change
| 这里说明一下从低版本升级上来，的一些检查事项： | |
| 从低版本升级时，需注意以下检查事项： |
| 3 rows in set (0.52 sec) | ||
| ``` | ||
| **注意：** 这个是一个配置参数，需要重启 TiDB 节点，上面 `Value` 字段查询出来值应该和用户设置的值应该一致。 | ||
| - 对于 Cloud 用户，我们对于能够使用快速加索引功能的使用有一些限制： |
There was a problem hiding this comment.
Cloud 用户限制的描述不够清晰，建议明确说明支持的规格及其限制原因。
Suggested change
| - 对于 Cloud 用户，我们对于能够使用快速加索引功能的使用有一些限制： | |
| 对于 Cloud 用户，快速加索引功能的使用有以下限制： |
| ## TiCDC 占用多少 PD 的存储空间？ | ||
|
|
||
| TiCDC 使用 PD 内部的 etcd 来存储元数据并定期更新。因为 etcd 的多版本并发控制 (MVCC) 以及 PD 默认的 compaction 间隔是 1 小时，TiCDC 占用的 PD 存储空间与 1 小时内元数据的版本数量成正比。在 v4.0.5、v4.0.6、v4.0.7 三个版本中 TiCDC 存在元数据写入频繁的问题，如果 1 小时内有 1000 张表创建或调度，就会用尽 etcd 的存储空间，出现 `etcdserver: mvcc: database space exceeded` 错误。出现这种错误后需要清理 etcd 存储空间，参考 [etcd maintenance space-quota](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota)。如果你的 TiCDC 版本为 v4.0.5、v4.0.6 或 v4.0.7，建议升级到 v4.0.9 及以后版本。 | ||
| 在使用 TiCDC 的过程中，可能会遇到 `etcdserver: mvcc: database space exceeded` 错误，这主要与 TiCDC 使用 PD 内部的 etcd 来存储元数据的机制相关。 |
There was a problem hiding this comment.
第一句描述不够清晰，建议明确说明 TiCDC 使用 PD 的 etcd 存储元数据的机制，并补充对问题的背景解释。
Suggested change
| 在使用 TiCDC 的过程中，可能会遇到 `etcdserver: mvcc: database space exceeded` 错误，这主要与 TiCDC 使用 PD 内部的 etcd 来存储元数据的机制相关。 | |
| TiCDC 使用 PD 内部的 etcd 来存储元数据并定期更新。由于 etcd 的多版本并发控制 (MVCC) 机制以及 PD 默认的 compaction 间隔为 1 小时，TiCDC 占用的 PD 存储空间与 1 小时内元数据的版本数量成正比。 |
|
|
||
| etcd 采用多版本并发控制（MVCC）机制存储数据，且 PD 默认的 compaction 间隔为 1 小时。这意味着在 1 小时内，etcd 会保留所有数据的多个版本，直至进行压缩操作。 | ||
|
|
||
| **v6.0.0 之前版本的问题** |
There was a problem hiding this comment.
建议将 'v6.0.0 之前版本的问题' 改为 'v6.0.0 之前版本的存储机制'，以更准确地描述问题。
Suggested change
| **v6.0.0 之前版本的问题** | |
| **v6.0.0 之前版本的存储机制** |
|
|
||
| 出现这种错误后需要清理 etcd 存储空间，参考 [etcd maintenance space-quota](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota)。 | ||
|
|
||
| **v6.0.0 及以后版本的优化** |
There was a problem hiding this comment.
建议将 'v6.0.0 及以后版本的优化' 改为 'v6.0.0 及以后版本的改进'，以更准确地描述优化内容。
Suggested change
| **v6.0.0 及以后版本的优化** | |
| **v6.0.0 及以后版本的改进** |
| > | ||
| > 当同步存储生成列到 Kafka 或存储服务后，再将其写回 MySQL 时，可能会遇到 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed` 错误。为避免该错误，你可以使用 [Open Protocol](/ticdc/ticdc-open-protocol.md) 进行同步。该协议的输出包含[列的 flag 值](/ticdc/ticdc-open-protocol.md#列标志位)，可以区分是否为生成列。 | ||
|
|
||
| ## 当频繁出现 `ErrMySQLDuplicateEntry` 错误时，如何解决？ |
There was a problem hiding this comment.
标题中的错误代码 ErrMySQLDuplicateEntry 与下文中的 CDC:ErrMySQLDuplicateEntryCDC 不一致，建议统一使用 CDC:ErrMySQLDuplicateEntryCDC 以避免混淆。
Suggested change
| ## 当频繁出现 `ErrMySQLDuplicateEntry` 错误时，如何解决？ | |
| ## 当频繁出现 `CDC:ErrMySQLDuplicateEntryCDC` 错误时，如何解决？ |
|
|
||
| 使用 TiCDC 将数据同步到 TiDB 或 MySQL 时，如果上游以特定模式执行 SQL ，可能会遇到如下错误： | ||
|
|
||
| `CDC:ErrMySQLDuplicateEntryCDC` |
There was a problem hiding this comment.
错误代码 CDC:ErrMySQLDuplicateEntryCDC 的格式不够规范，建议使用标准的错误代码格式，例如 CDC:ErrMySQLDuplicateEntry。
Suggested change
| `CDC:ErrMySQLDuplicateEntryCDC` | |
| `CDC:ErrMySQLDuplicateEntry` |
|
|
||
| 如果在执行第二个更新时，表中仍然存在`v1`，会破坏唯一键约束，从而导致 `ErrMySQLDuplicateEntry` 错误。 | ||
|
|
||
| 为防止此问题，可以通过在 `sink-uri` 配置中设置 `safe-mode=true` 参数，在TiCDC中启用安全模式。这样，TiCDC 就会把 UPDATE 操作拆分为 `DELETE + INSERT` 进行执行，这样就能避免错误。 |
There was a problem hiding this comment.
建议明确说明 safe-mode=true 的具体作用，以便用户更好地理解其功能。
Suggested change
| 为防止此问题，可以通过在 `sink-uri` 配置中设置 `safe-mode=true` 参数，在TiCDC中启用安全模式。这样，TiCDC 就会把 UPDATE 操作拆分为 `DELETE + INSERT` 进行执行，这样就能避免错误。 | |
| 为防止此问题，可以通过在 `sink-uri` 配置中设置 `safe-mode=true` 参数，在 TiCDC 中启用安全模式。安全模式下，TiCDC 会将 UPDATE 操作拆分为 `DELETE + INSERT` 进行执行，从而避免唯一键冲突错误。 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
temperature: 0.2
Which TiDB version(s) do your changes apply to? (Required)
Tips for choosing the affected version(s):
By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.
For details, see tips for choosing the affected versions (in Chinese).
What is the related PR or file link(s)?
Do your changes match any of the following descriptions?