diff --git a/basic-features.md b/basic-features.md index f60bf7426c2b..8a0f22497c89 100644 --- a/basic-features.md +++ b/basic-features.md @@ -174,7 +174,6 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0 | [扩展统计信息](/extended-statistics.md) | E | E | E | E | E | E | E | E | E | | 统计反馈 | N | N | N | N | 已废弃 | 已废弃 | E | E | E | | [统计信息自动更新](/statistics.md#自动更新) | Y | Y | Y | Y | Y | Y | Y | Y | Y | -| [快速分析](/system-variables.md#tidb_enable_fast_analyze) | 已废弃 | 已废弃 | E | E | E | E | E | E | E | | [动态裁剪](/partitioned-table.md#动态裁剪模式) | Y | Y | Y | Y | Y | E | E | E | E | | [收集部分列的统计信息](/statistics.md#收集部分列的统计信息) | E | E | E | E | E | E | N | N | N | | [限制统计信息的内存使用量](/statistics.md#统计信息收集的内存限制) | E | E | E | E | E | N | N | N | N | diff --git a/best-practices/uuid.md b/best-practices/uuid.md index 4606f8515d63..ab4bd2e15984 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -7,17 +7,17 @@ summary: 了解在 TiDB 中使用 UUID 的最佳实践和策略。 ## UUID 概述 -通用唯一标识符（UUID）用作主键而不是 `AUTO_INCREMENT` 整数值时，可以提供以下好处： +通用唯一标识符 (UUID) 用作主键而不是 [`AUTO_INCREMENT`](/auto-increment.md) 整数值时，可以提供以下好处： - UUID 可以在多个系统生成，而不会产生冲突。某些情况下可以减少到 TiDB 的网络往返次数，从而提高性能。 - 绝大多数编程语言和数据库系统都支持 UUID。 -- 用在 URL 中时，UUID 不容易被枚举攻击。相比之下，使用 `auto_increment` 数字，则很容易让发票 ID 或用户 ID 被猜出。 +- 用在 URL 中时，UUID 不容易被枚举攻击。相比之下，使用 `AUTO_INCREMENT` 数字，则很容易让发票 ID 或用户 ID 被猜出。 ## 最佳实践 ### 二进制存储 -UUID 文本是一个包含 36 字符的字符串，如 `ab06f63e-8fe7-11ec-a514-5405db7aad56`。使用 `UUID_TO_BIN()` 可将 UUID 文本格式转换为 16 字节的二进制格式。这样，你可以将文本存储在 `BINARY(16)` 列中。检索 UUID 时，可以使用 `BIN_TO_UUID()` 函数再将其转换回文本格式。 +UUID 文本是一个包含 36 字符的字符串，如 `ab06f63e-8fe7-11ec-a514-5405db7aad56`。使用 [`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin) 可将 UUID 文本格式转换为 16 字节的二进制格式。这样，你可以将文本存储在 [`BINARY(16)`](/data-type-string.md#binary-类型) 列中。检索 UUID 时，可以使用 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid) 函数再将其转换回文本格式。 ### UUID 格式二进制顺序和聚簇主键 diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md index 7ad31379a4c6..db50479c2241 100644 --- a/br/br-incremental-guide.md +++ b/br/br-incremental-guide.md @@ -11,6 +11,12 @@ TiDB 集群增量数据包含在某个时间段的起始和结束两个快照的 > > 当前该功能已经停止开发迭代，推荐你选择[日志备份与恢复功能](/br/br-pitr-guide.md)代替。 +## 使用限制 + +由于增量备份的恢复依赖于备份时间点的库表快照来过滤增量 DDL，因此对于增量备份过程中删除的表，在恢复后可能仍然存在，需要手动删除。 + +增量备份尚不支持批量重命名表的操作。如果在增量备份过程中发生了批量重命名表的操作，则有可能造成恢复失败。建议在批量重命名表后进行一次全量备份，并在恢复时使用最新的全量备份替代增量数据。 + ## 对集群进行增量备份 使用 `tiup br backup` 进行增量备份只需要指定**上一次的备份时间戳** `--lastbackupts`，br 命令行工具会判定需要备份 `lastbackupts` 和当前时间之间增量数据。使用 `validate` 指令获取上一次备份的时间戳，示例如下： diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md index 1ab2321c4d4c..0c3f3d4c0ec6 100644 --- a/br/br-snapshot-guide.md +++ b/br/br-snapshot-guide.md @@ -175,13 +175,11 @@ tiup br restore full \ +-----------------------------------------------------+ ``` -当恢复系统权限相关数据的时候，请注意： +当恢复系统权限相关数据的时候，请注意：在恢复数据前 BR 会检查目标集群的系统表是否跟备份数据中的系统表兼容。这里的兼容是指满足以下所有条件： -- 在 v7.6.0 之前版本中，BR 无法恢复 `user` 为 `cloud_admin` 并且 `host` 为 `'%'` 的用户数据，该用户是 TiDB Cloud 预留用户。从 v7.6.0 开始，BR 默认支持恢复包括 `cloud_admin` 在内的所有用户数据。 -- 在恢复数据前 BR 会检查目标集群的系统表是否跟备份数据中的系统表兼容。这里的兼容是指满足以下所有条件： - - 目标集群需要存在备份中的系统权限表。 - - 目标集群系统权限表**列数**需要与备份数据中一致，列的顺序可以有差异。 - - 目标集群系统权限表的列需要与备份数据兼容。如果为带长度类型（包括整型、字符串等类型），前者长度需大于或等于后者，如果为 `ENUM` 类型，则应该为后者超集。 +- 目标集群需要存在备份中的系统权限表。 +- 目标集群系统权限表**列数**需要与备份数据中一致，列的顺序可以有差异。 +- 目标集群系统权限表的列需要与备份数据兼容。如果为带长度类型（包括整型、字符串等类型），前者长度需大于或等于后者，如果为 `ENUM` 类型，则应该为后者超集。 ## 性能与影响 diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index d5148d1e567c..279e546f07d4 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -312,12 +312,14 @@ select tidb_decode_sql_digests(@digests, 10); SET GLOBAL tidb_enable_row_level_checksum = ON; ``` +上述配置仅对新创建的会话生效，因此需要重新连接 TiDB。 + 创建表 `t` 并插入数据： ```sql USE test; -CREATE TABLE t (id INT PRIMARY KEY, k INT, c int); -INSERT INTO TABLE t values (1, 10, a); +CREATE TABLE t (id INT PRIMARY KEY, k INT, c CHAR(1)); +INSERT INTO t values (1, 10, 'a'); ``` 查询表 `t` 中 `id = 1` 的行数据的 Checksum 值： diff --git a/hardware-and-software-requirements.md b/hardware-and-software-requirements.md index 63b29fd58987..f0ed73a0df33 100644 --- a/hardware-and-software-requirements.md +++ b/hardware-and-software-requirements.md @@ -23,6 +23,7 @@ TiDB 作为一款开源一栈式实时 HTAP 数据库，可以很好地部署和 | Red Hat Enterprise Linux 8.4 及以上的 8.x 版本 | | | | | | Amazon Linux 2 | | +| Amazon Linux 2023 | | | Rocky Linux 9.1 及以上的版本 | | | 麒麟欧拉版 V10 SP1/SP2 | | | 统信操作系统 (UOS) V20 | | diff --git a/information-schema/information-schema-tikv-region-status.md b/information-schema/information-schema-tikv-region-status.md index de90c4f34a74..5ff6300d5396 100644 --- a/information-schema/information-schema-tikv-region-status.md +++ b/information-schema/information-schema-tikv-region-status.md @@ -8,13 +8,13 @@ aliases: ['/docs-cn/dev/information-schema/information-schema-tikv-region-status `TIKV_REGION_STATUS` 表通过 PD 的 API 展示 TiKV Region 的基本信息，比如 Region ID、开始和结束键值以及读写流量。 -{{< copyable "sql" >}} - ```sql -USE information_schema; -DESC tikv_region_status; +USE INFORMATION_SCHEMA; +DESC TIKV_REGION_STATUS; ``` +输出结果如下： + ```sql +---------------------------+-------------+------+------+---------+-------+ | Field | Type | Null | Key | Default | Extra | @@ -28,6 +28,9 @@ DESC tikv_region_status; | IS_INDEX | tinyint(1) | NO | | 0 | | | INDEX_ID | bigint(21) | YES | | NULL | | | INDEX_NAME | varchar(64) | YES | | NULL | | +| IS_PARTITION | tinyint(1) | NO | | 0 | | +| PARTITION_ID | bigint(21) | YES | | NULL | | +| PARTITION_NAME | varchar(64) | YES | | NULL | | | EPOCH_CONF_VER | bigint(21) | YES | | NULL | | | EPOCH_VERSION | bigint(21) | YES | | NULL | | | WRITTEN_BYTES | bigint(21) | YES | | NULL | | @@ -37,7 +40,7 @@ DESC tikv_region_status; | REPLICATIONSTATUS_STATE | varchar(64) | YES | | NULL | | | REPLICATIONSTATUS_STATEID | bigint(21) | YES | | NULL | | +---------------------------+-------------+------+------+---------+-------+ -17 rows in set (0.00 sec) +20 rows in set (0.00 sec) ``` `TIKV_REGION_STATUS` 表中列的含义如下： @@ -51,6 +54,9 @@ DESC tikv_region_status; * `IS_INDEX`：Region 数据是否是索引，0 代表不是索引，1 代表是索引。如果当前 Region 同时包含表数据和索引数据，会有多行记录，`IS_INDEX` 分别是 0 和 1。 * `INDEX_ID`：Region 所属的索引的 ID。如果 `IS_INDEX` 为 0，这一列的值就为 NULL。 * `INDEX_NAME`：Region 所属的索引的名称。如果 `IS_INDEX` 为 0，这一列的值就为 NULL。 +* `IS_PARTITION`：Region 所属的表是否为分区表。 +* `PARTITION_ID`：如果 Region 所属的表为分区表，显示 Region 所属的分区的 ID。 +* `PARTITION_NAME`：如果 Region 所属的表为分区表，显示 Region 所属的分区的名字。 * `EPOCH_CONF_VER`：Region 的配置的版本号，在增加或减少 peer 时版本号会递增。 * `EPOCH_VERSION`：Region 的当前版本号，在分裂或合并时版本号会递增。 * `WRITTEN_BYTES`：已经往 Region 写入的数据量 (bytes)。 diff --git a/migrate-from-csv-files-to-tidb.md b/migrate-from-csv-files-to-tidb.md index 806bd9497ee5..84ee85a669a5 100644 --- a/migrate-from-csv-files-to-tidb.md +++ b/migrate-from-csv-files-to-tidb.md @@ -61,6 +61,8 @@ data-source-dir = "${data-path}" # 本地或 S3 路径，例如：'s3://my-bucke separator = ',' # 引用定界符，可以为零或多个字符。 delimiter = '"' +# 行结束符。默认将 \r、\n、\r\n 都作为行结束符处理。 +# terminator = "\r\n" # CSV 文件是否包含表头。 # 如果为 true，则 lightning 会使用首行内容解析字段的对应关系。 header = true @@ -102,6 +104,8 @@ pd-addr = "${ip}:${port}" # 集群 PD 的地址，Lightning 通过 PD 获取 - delimiter 为空； - 每个字段不包含 CR (\\r）或 LF（\\n）。 +严格格式 `strict-format` 的 CSV 文件需要显式指定行结束符 `terminator`。 + 如果你确认满足条件，可按如下配置开启 `strict-format` 模式以加快导入速度。 ```toml diff --git a/optimizer-hints.md b/optimizer-hints.md index f1598470b39b..44d6388d941f 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -134,6 +134,10 @@ SELECT /*+ NO_MERGE_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; ### INL_JOIN(t1_name [, tl_name ...]) +> **注意：** +> +> 部分情况下 `INL_JOIN` Hint 可能无法生效，详情请参阅 [`INL_JOIN` Hint 不生效](#inl_join-hint-不生效)。 + `INL_JOIN(t1_name [, tl_name ...])` 提示优化器对指定表使用 Index Nested Loop Join 算法。这个算法可能会在某些场景更快，消耗更少系统资源，有的场景会更慢，消耗更多系统资源。对于外表经过 WHERE 条件过滤后结果集较小（小于 1 万行）的场景，可以尝试使用。例如： {{< copyable "sql" >}} @@ -939,7 +943,74 @@ Warning 信息如下： 在上面的示例中，你需要将 Hint 直接放在 `SELECT` 关键字之后。具体的语法规则参见 [Hint 语法](#语法)部分。 -### 排序规则不兼容导致 `INL_JOIN` Hint 不生效 +### `INL_JOIN` Hint 不生效 + +#### 关联表的列上使用内置函数导致 `INL_JOIN` Hint 不生效 + +在某些情况下，如果在关联表的列上使用了内置函数，优化器可能无法选择 `IndexJoin` 计划，导致 `INL_JOIN` Hint 也无法生效。 + +例如，以下查询在关联表的列 `tname` 上使用了内置函数 `substr`： + +```sql +CREATE TABLE t1 (id varchar(10) primary key, tname varchar(10)); +CREATE TABLE t2 (id varchar(10) primary key, tname varchar(10)); +EXPLAIN SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id=t2.id and SUBSTR(t1.tname,1,2)=SUBSTR(t2.tname,1,2); +``` + +查询计划输出结果如下： + +```sql ++------------------------------+----------+-----------+---------------+-----------------------------------------------------------------------+ +| id | estRows | task | access object | operator info | ++------------------------------+----------+-----------+---------------+-----------------------------------------------------------------------+ +| HashJoin_12 | 12500.00 | root | | inner join, equal:[eq(test.t1.id, test.t2.id) eq(Column#5, Column#6)] | +| ├─Projection_17(Build) | 10000.00 | root | | test.t2.id, test.t2.tname, substr(test.t2.tname, 1, 2)->Column#6 | +| │ └─TableReader_19 | 10000.00 | root | | data:TableFullScan_18 | +| │ └─TableFullScan_18 | 10000.00 | cop[tikv] | table:t2 | keep order:false, stats:pseudo | +| └─Projection_14(Probe) | 10000.00 | root | | test.t1.id, test.t1.tname, substr(test.t1.tname, 1, 2)->Column#5 | +| └─TableReader_16 | 10000.00 | root | | data:TableFullScan_15 | +| └─TableFullScan_15 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo | ++------------------------------+----------+-----------+---------------+-----------------------------------------------------------------------+ +7 rows in set, 1 warning (0.01 sec) +``` + +```sql +SHOW WARNINGS; +``` + +``` ++---------+------+------------------------------------------------------------------------------------+ +| Level | Code | Message | ++---------+------+------------------------------------------------------------------------------------+ +| Warning | 1815 | Optimizer Hint /*+ INL_JOIN(t1, t2) */ or /*+ TIDB_INLJ(t1, t2) */ is inapplicable | ++---------+------+------------------------------------------------------------------------------------+ +1 row in set (0.00 sec) +``` + +从该示例中可以看到，`INL_JOIN` Hint 没有生效。该问题的根本原因是优化器限制导致无法使用 `Projection` 或者 `Selection` 算子作为 `IndexJoin` 的探测 (Probe) 端。 + +从 TiDB v8.0.0 起，你通过设置 [`tidb_enable_inl_join_inner_multi_pattern`](/system-variables.md#tidb_enable_inl_join_inner_multi_pattern-从-v700-版本开始引入) 为 `ON` 来避免该问题。 + +```sql +SET @@tidb_enable_inl_join_inner_multi_pattern=ON; +Query OK, 0 rows affected (0.00 sec) + +EXPLAIN SELECT /*+ INL_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id=t2.id AND SUBSTR(t1.tname,1,2)=SUBSTR(t2.tname,1,2); ++------------------------------+--------------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------+ +| id | estRows | task | access object | operator info | ++------------------------------+--------------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------+ +| IndexJoin_18 | 12500.00 | root | | inner join, inner:Projection_14, outer key:test.t1.id, inner key:test.t2.id, equal cond:eq(Column#5, Column#6), eq(test.t1.id, test.t2.id) | +| ├─Projection_32(Build) | 10000.00 | root | | test.t1.id, test.t1.tname, substr(test.t1.tname, 1, 2)->Column#5 | +| │ └─TableReader_34 | 10000.00 | root | | data:TableFullScan_33 | +| │ └─TableFullScan_33 | 10000.00 | cop[tikv] | table:t1 | keep order:false, stats:pseudo | +| └─Projection_14(Probe) | 100000000.00 | root | | test.t2.id, test.t2.tname, substr(test.t2.tname, 1, 2)->Column#6 | +| └─TableReader_13 | 10000.00 | root | | data:TableRangeScan_12 | +| └─TableRangeScan_12 | 10000.00 | cop[tikv] | table:t2 | range: decided by [eq(test.t2.id, test.t1.id)], keep order:false, stats:pseudo | ++------------------------------+--------------+-----------+---------------+--------------------------------------------------------------------------------------------------------------------------------------------+ +7 rows in set (0.00 sec) +``` + +#### 排序规则不兼容导致 `INL_JOIN` Hint 不生效 如果两个表的 Join key 的排序规则不能兼容，将无法使用 IndexJoin 来执行查询。此时 [`INL_JOIN` Hint](#inl_joint1_name--tl_name-) 将无法生效。例如： @@ -976,7 +1047,7 @@ SHOW WARNINGS; 1 row in set (0.00 sec) ``` -### 连接顺序导致 `INL_JOIN` Hint 不生效 +#### 连接顺序导致 `INL_JOIN` Hint 不生效 [`INL_JOIN(t1, t2)`](#inl_joint1_name--tl_name-) 或 `TIDB_INLJ(t1, t2)` 的语义是让 `t1` 和 `t2` 作为 `IndexJoin` 的内表与其他表进行连接，而不是直接将 `t1` 和 `t2` 进行 `IndexJoin` 连接。例如： diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md index 99f38d01c03c..0e171c7184d1 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -43,6 +43,10 @@ TiDB 版本：7.5.1 - 允许多个快速加索引 DDL 任务排队执行，而非回退为普通加索引任务 [#47758](https://github.com/pingcap/tidb/issues/47758) @[tangenta](https://github.com/tangenta) - 提升空表加索引的速度 [#49682](https://github.com/pingcap/tidb/issues/49682) @[zimulala](https://github.com/zimulala) ++ TiKV + + - 改善慢节点检测的判定算法，提升算法检测的灵敏度，同时降低了算法对于热读写场景下的误判率 [#15909](https://github.com/tikv/tikv/issues/15909) @[LykxSassinator](https://github.com/LykxSassinator) + + TiFlash - 改进 [RU (Request Unit)](/tidb-resource-control.md#什么是-request-unit-ru) 计算方法，以提高 RU 值的稳定性 [#8391](https://github.com/pingcap/tiflash/issues/8391) @[guo-shaoge](https://github.com/guo-shaoge) @@ -159,6 +163,7 @@ TiDB 版本：7.5.1 - 修复扩容时可能导致 DR Auto-Sync 的 joint state 超时问题 [#15817](https://github.com/tikv/tikv/issues/15817) @[Connor1996](https://github.com/Connor1996) - 修复 Resolved TS 可能被阻塞两小时的问题 [#11847](https://github.com/tikv/tikv/issues/11847) [#15520](https://github.com/tikv/tikv/issues/15520) [#39130](https://github.com/pingcap/tidb/issues/39130) @[overvenus](https://github.com/overvenus) - 修复 `cast_duration_as_time` 可能返回错误结果的问题 [#16211](https://github.com/tikv/tikv/issues/16211) @[gengliqi](https://github.com/gengliqi) + - 修复在某些异常场景下（如阻塞在 Disk I/O 操作上）TiKV 假死而影响可用性的问题 [#16368](https://github.com/tikv/tikv/issues/16368) @[LykxSassinator](https://github.com/LykxSassinator) + PD diff --git a/releases/release-7.6.0.md b/releases/release-7.6.0.md index d3fe2c81c7bb..582dc5529e75 100644 --- a/releases/release-7.6.0.md +++ b/releases/release-7.6.0.md @@ -208,7 +208,7 @@ TiDB 版本：7.6.0 从 `br` v5.1.0 开始，快照备份时默认自动备份 **mysql schema** 下的系统表数据，但恢复数据时默认不恢复系统表数据。在 v6.2.0 中，`br` 增加恢复参数 `--with-sys-table` 支持恢复数据的同时恢复部分系统表相关数据，提供更多的操作灵活性。 - 为了进一步降低用户的管理成本，并提供更直观的默认行为。从 v7.6.0 开始，`br` 默认开启恢复参数 `--with-sys-table`，并支持恢复 `user` 为 `cloud_admin` 的用户数据。这意味着 `br` 默认支持恢复数据的同时恢复部分系统表相关数据，特别是用户账号和表的统计信息数据。这一改进旨在使备份恢复操作更加直观，减轻手动配置的负担，从而提升整体的操作体验。 + 为了进一步降低用户的管理成本，并提供更直观的默认行为。从 v7.6.0 开始，`br` 默认开启恢复参数 `--with-sys-table`。这意味着 `br` 默认支持恢复数据的同时恢复部分系统表相关数据，特别是用户账号和表的统计信息数据。这一改进旨在使备份恢复操作更加直观，减轻手动配置的负担，从而提升整体的操作体验。 更多信息，请参考[用户文档](/br/br-snapshot-guide.md)。 diff --git a/sql-statements/sql-statement-import-into.md b/sql-statements/sql-statement-import-into.md index a9e6f6a4ec06..827943e41f7d 100644 --- a/sql-statements/sql-statement-import-into.md +++ b/sql-statements/sql-statement-import-into.md @@ -141,7 +141,7 @@ SET 表达式左侧只能引用 `ColumnNameOrUserVarList` 中没有的列名。 | `FIELDS_DEFINED_NULL_BY=''` | CSV | 指定字段为何值时将会被解析为 NULL，默认为 `\N`。 | | `LINES_TERMINATED_BY=''` | CSV | 指定行分隔符，默认 `IMPORT INTO` 会自动识别分隔符为 `\n`、`\r` 或 `\r\n`，如果行分隔符为以上三种，无须显式指定该选项。 | | `SKIP_ROWS=` | CSV | 指定需要跳过的行数，默认为 `0`。可通过该参数跳过 CSV 中的 header，如果是通过通配符来指定所需导入的源文件，该参数会对 fileLocation 中通配符匹配的所有源文件生效。 | -| `SPLIT_FILE` | CSV | 将单个 CSV 文件拆分为多个 256 MiB 左右的小文件块进行并行处理，以提高导入效率。该参数仅对**非**压缩的 CSV 文件生效，且该参数和 TiDB Lightning 的 [`strict-format`](/tidb-lightning/tidb-lightning-data-source.md#启用严格格式) 有相同的使用限制。 | +| `SPLIT_FILE` | CSV | 将单个 CSV 文件拆分为多个 256 MiB 左右的小文件块进行并行处理，以提高导入效率。该参数仅对**非**压缩的 CSV 文件生效，且该参数和 TiDB Lightning 的 [`strict-format`](/tidb-lightning/tidb-lightning-data-source.md#启用严格格式) 有相同的使用限制。注意，你需要为该选项显式指定 `LINES_TERMINATED_BY`。| | `DISK_QUOTA=''` | 所有文件格式 | 指定数据排序期间可使用的磁盘空间阈值。默认值为 TiDB [临时目录](/tidb-configuration-file.md#temp-dir-从-v630-版本开始引入)所在磁盘空间的 80%。如果无法获取磁盘总大小，默认值为 50 GiB。当显式指定 `DISK_QUOTA` 时，该值同样不能超过 TiDB [临时目录](/tidb-configuration-file.md#temp-dir-从-v630-版本开始引入)所在磁盘空间的 80%。 | | `DISABLE_TIKV_IMPORT_MODE` | 所有文件格式 | 指定是否禁止导入期间将 TiKV 切换到导入模式。默认不禁止。如果当前集群存在正在运行的读写业务，为避免导入过程对这部分业务造成影响，可开启该参数。 | | `THREAD=` | 所有文件格式、`SELECT` 语句的查询结果 | 指定导入的并发度。对于 `IMPORT INTO ... FROM FILE`，`THREAD` 默认值为 TiDB 节点的 CPU 核数的 50%，最小值为 `1`，最大值为 CPU 核数；对于 `IMPORT INTO ... FROM SELECT`，`THREAD` 默认值为 `2`，最小值为 `1`，最大值为 TiDB 节点的 CPU 核数的 2 倍。如需导入数据到一个空集群，建议可以适当调大该值，以提升导入性能。如果目标集群已经用于生产环境，请根据业务要求按需调整该参数值。 | diff --git a/statistics.md b/statistics.md index f74d47fd28ec..a20b322ed487 100644 --- a/statistics.md +++ b/statistics.md @@ -115,7 +115,7 @@ ANALYZE TABLE TableNameList [WITH NUM BUCKETS|TOPN|CMSKETCH DEPTH|CMSKETCH WIDTH > > 目前采样率基于自适应算法进行计算。当你通过 [`SHOW STATS_META`](/sql-statements/sql-statement-show-stats-meta.md) 可以观察到一个表的行数时，可通过这个行数去计算采集 10 万行所对应的采样率。如果你观察不到这个值，可通过表 [`SHOW TABLE REGIONS`](/sql-statements/sql-statement-show-table-regions.md) 结果中所有 `APPROXIMATE_KEYS` 列值的总和作为另一个参考来计算采样率。 > -> 通常情况下，`STATS_META` 相对 `APPROXIMATE_KEYS` 更可信，但是通过 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 等方式导入数据结束后，`STATS_META` 结果是 `0`。为了处理这个情况，你可以在 `STATS_META` 的结果远小于 `APPROXIMATE_KEYS` 的结果时，使用 `APPROXIMATE_KEYS` 计算采样率。 +> 通常情况下，`STATS_META` 相对 `APPROXIMATE_KEYS` 更可信，但当 `STATS_META` 的结果远小于 `APPROXIMATE_KEYS` 的结果时，推荐使用 `APPROXIMATE_KEYS` 计算采样率。 #### 收集部分列的统计信息 diff --git a/system-variables.md b/system-variables.md index 1ec85c40097b..37bb1ee1a3ab 100644 --- a/system-variables.md +++ b/system-variables.md @@ -520,7 +520,7 @@ mysql> SELECT * FROM t1; - 作用域：NONE - 是否受 Hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value) 控制：否 - 默认值：（系统主机名） -- 这个变量一个只读变量，表示 TiDB server 的主机名。 +- 这个变量为只读变量，表示 TiDB server 的主机名。 ### `identity` 从 v5.3.0 版本开始引入 @@ -2440,6 +2440,7 @@ Query OK, 0 rows affected (0.09 sec) - 类型：布尔型 - 默认值：`OFF` - 这个变量用于控制是否开启 [TiCDC 单行数据正确性校验](/ticdc/ticdc-integrity-check.md)功能。 +- 你可以使用 [`TIDB_ROW_CHECKSUM()`](/functions-and-operators/tidb-functions.md#tidb_row_checksum) 函数查询行数据的 Checksum 值。 ### `tidb_enforce_mpp` 从 v5.1 版本开始引入 diff --git a/ticdc/ticdc-alert-rules.md b/ticdc/ticdc-alert-rules.md index 0578a531102e..d7a3275cf4fd 100644 --- a/ticdc/ticdc-alert-rules.md +++ b/ticdc/ticdc-alert-rules.md @@ -15,7 +15,7 @@ summary: 了解 TiCDC 集群监控报警规则以及处理方法。 * 报警规则： - (time() - ticdc_owner_checkpoint_ts / 1000) > 600 + `ticdc_owner_checkpoint_ts_lag > 600` * 规则描述： @@ -29,7 +29,7 @@ summary: 了解 TiCDC 集群监控报警规则以及处理方法。 * 报警规则： - (time() - ticdc_owner_resolved_ts / 1000) > 300 + `ticdc_owner_resolved_ts_lag > 300` * 规则描述： diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index dc3ae2136b03..a71ad627dbe6 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -119,7 +119,7 @@ Update t1 set b = 4 where b = 2; TiCDC 将根据数据变更信息重新生成 SQL 语句，向下游写以下两条 SQL 语句： ```sql -INSERT INTO `test.t1` (`A`,`B`) VALUES (1,1),(2,2),(3,3); +INSERT INTO `test.t1` (`A`,`B`) VALUES (1,2),(2,2),(3,3); UPDATE `test`.`t1` SET `A` = CASE WHEN `A` = 1 THEN 1 @@ -131,7 +131,7 @@ END WHERE `A` = 1 OR `A` = 2; ``` -### 暂不支持的场景 +## 暂不支持的场景 目前 TiCDC 暂不支持的场景如下： diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index 07593f7b556d..8a0817566241 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -36,9 +36,17 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092/topic-name?protocol=canal-json&kafka-v Sink URI 用于指定 TiCDC 目标系统的连接信息，遵循以下格式： ```shell -[scheme]://[userinfo@][host]:[port][/path]?[query_parameters] +[scheme]://[host]:[port][/path]?[query_parameters] ``` +> **Tip:** +> +> 如果下游 Kafka 有多个主机或端口，可以在 Sink URI 中配置多个 `[host]:[port]`。例如： +> +> ```shell +> [scheme]://[host]:[port],[host]:[port],[host]:[port][/path]?[query_parameters] +> ``` + 一个通用的配置样例如下所示： ```shell diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 7c047313646c..ea8f26339d5a 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -1039,6 +1039,7 @@ raftstore 相关的配置项。 + 设置 TiKV 启动周期性全量数据整理 (Compaction) 的时间。你可以在数组中指定一个或多个时间计划。例如： + `periodic-full-compact-start-times = ["03:00", "23:00"]` 表示 TiKV 基于 TiKV 节点的本地时区，在每天凌晨 3 点和晚上 11 点进行全量数据整理。 + `periodic-full-compact-start-times = ["03:00 +0000", "23:00 +0000"]` 表示 TiKV 在每天 UTC 时间的凌晨 3 点和晚上 11 点进行全量数据整理。 + + `periodic-full-compact-start-times = ["03:00 +0800", "23:00 +0800"]` 表示 TiKV 在每天 UTC+08:00 时间的凌晨 3 点和晚上 11 点进行全量数据整理。 + 默认值：`[]`，表示默认情况下禁用周期性全量数据整理。 ### `periodic-full-compact-start-max-cpu` 从 v7.6.0 版本开始引入 @@ -1270,6 +1271,10 @@ RocksDB 相关的配置项。 ### `info-log-max-size` +> **警告：** +> +> 自 v5.4.0 起，RocksDB 的日志改为由 TiKV 的日志模块进行管理，因此该配置项被废弃，其功能由配置参数 [`log.file.max-size`](#max-size-从-v540-版本开始引入) 代替。 + + Info 日志的最大大小。 + 默认值：1GiB + 最小值：0 @@ -1277,11 +1282,19 @@ RocksDB 相关的配置项。 ### `info-log-roll-time` +> **警告：** +> +> 自 v5.4.0 起，RocksDB 的日志改为由 TiKV 的日志模块进行管理，因此该配置项被废弃。TiKV 不再支持按照时间自动切分日志，请使用配置参数 [`log.file.max-size`](#max-size-从-v540-版本开始引入) 配置按照文件大小自动切分日志的阈值。 + + 日志截断间隔时间，如果为 0s 则不截断。 + 默认值：0s ### `info-log-keep-log-file-num` +> **警告：** +> +> 自 v5.4.0 起，RocksDB 的日志改为由 TiKV 的日志模块进行管理，因此该配置项被废弃，其功能由配置参数 [`log.file.max-backups`](#max-backups-从-v540-版本开始引入) 代替。 + + 保留日志文件最大个数。 + 默认值：10 + 最小值：0 @@ -1293,6 +1306,10 @@ RocksDB 相关的配置项。 ### `info-log-level` +> **警告：** +> +> 自 v5.4.0 起，RocksDB 的日志改为由 TiKV 的日志模块进行管理，因此该配置项被废弃，其功能由配置参数 [`log.level`](#level-从-v540-版本开始引入) 代替。 + + RocksDB 的日志级别。 + 默认值：`"info"` @@ -1322,7 +1339,7 @@ RocksDB 相关的配置项。 + 单位：KiB|MiB|GiB -### `track-and-verify-wals-in-manifest` 从 v6.5.9、v7.1.5、v8.0.0 版本开始引入 +### `track-and-verify-wals-in-manifest` 从 v6.5.9、v7.1.5、v7.5.2、v8.0.0 版本开始引入 + 控制是否在 RocksDB 的 MANIFEST 文件中记录 WAL (Write Ahead Log) 文件的信息，以及在启动时是否验证 WAL 文件的完整性。详情请参考 RocksDB [Track WAL in MANIFEST](https://github.com/facebook/rocksdb/wiki/Track-WAL-in-MANIFEST)。 + 默认值：`true` @@ -1846,6 +1863,10 @@ raftdb 相关配置项。 ### `info-log-max-size` +> **警告：** +> +> 自 v5.4.0 起，RocksDB 的日志改为由 TiKV 的日志模块进行管理，因此该配置项被废弃，其功能由配置参数 [`log.file.max-size`](#max-size-从-v540-版本开始引入) 代替。 + + Info 日志的最大大小。 + 默认值：`"1GiB"` + 最小值：`0` @@ -1853,11 +1874,19 @@ raftdb 相关配置项。 ### `info-log-roll-time` +> **警告：** +> +> 自 v5.4.0 起，RocksDB 的日志改为由 TiKV 的日志模块进行管理，因此该配置项被废弃。TiKV 不再支持按照时间自动切分日志，请使用配置参数 [`log.file.max-size`](#max-size-从-v540-版本开始引入) 配置按照文件大小自动切分日志的阈值。 + + Info 日志截断间隔时间，如果为 `"0s"` 则不截断。 + 默认值：`"0s"` ### `info-log-keep-log-file-num` +> **警告：** +> +> 自 v5.4.0 起，RocksDB 的日志改为由 TiKV 的日志模块进行管理，因此该配置项被废弃，其功能由配置参数 [`log.file.max-backups`](#max-backups-从-v540-版本开始引入) 代替。 + + RaftDB 中保存的 Info 日志文件的最大数量。 + 默认值：`10` + 最小值：`0` @@ -1869,6 +1898,10 @@ raftdb 相关配置项。 ### `info-log-level` +> **警告：** +> +> 自 v5.4.0 起，RocksDB 的日志改为由 TiKV 的日志模块进行管理，因此该配置项被废弃，其功能由配置参数 [`log.level`](#level-从-v540-版本开始引入) 代替。 + + RaftDB 的日志级别。 + 默认值：`"info"` diff --git a/time-to-live.md b/time-to-live.md index 4e33b8753d28..e41f27fb3d72 100644 --- a/time-to-live.md +++ b/time-to-live.md @@ -244,7 +244,6 @@ TTL 功能能够与 TiDB 的迁移、备份、恢复工具一同使用。 * 具有 TTL 属性的表不支持作为外键约束的主表被其他表引用。 * 不保证所有过期数据立即被删除，过期数据被删除的时间取决于后台清理任务的调度周期和调度窗口。 * 对于使用[聚簇索引](/clustered-indexes.md)的表，如果主键的类型不是整数类型或二进制字符串类型，TTL 任务将无法被拆分成多个子任务。这将导致 TTL 任务只能在一个 TiDB 节点上按顺序执行。如果表中的数据量较大，TTL 任务的执行可能会变得缓慢。 -* TTL 无法在 [TiDB Serverless](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-serverless-beta) 集群上使用。 ## 常见问题 diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index 7e35e1911be8..dc0d0907b6ad 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -91,7 +91,7 @@ HTTP 网关的配置。 #### `addr` -+ 默认值：`0.0.0.0:3090` ++ 默认值：`0.0.0.0:3080` + 支持热加载：否 + API 网关地址。格式为 `:`。