Skip to content

Commit 7ad73c4

Browse files
OreoxmtOreoxmt
authored
Remove duplicate white space between Chinese characters (#12082)
1 parent 8404a5b commit 7ad73c4

File tree

166 files changed

+323
-323
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

166 files changed

+323
-323
lines changed

‎alert-rules.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -382,7 +382,7 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/']
382382
* 处理方法：
383383

384384
* 确认是否需要扩容。
385-
* 排查是否有文件占用了大量磁盘空间，比如日志、快照或 core dump等文件。
385+
* 排查是否有文件占用了大量磁盘空间，比如日志、快照或 core dump 等文件。
386386

387387
#### `PD_system_time_slow`
388388

@@ -789,7 +789,7 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/']
789789

790790
## TiCDC 报警规则
791791

792-
关于TiCDC 报警规则的详细描述，参见 [TiCDC 集群监控报警](/ticdc/ticdc-alert-rules.md)。
792+
关于 TiCDC 报警规则的详细描述，参见 [TiCDC 集群监控报警](/ticdc/ticdc-alert-rules.md)。
793793

794794
## Node_exporter 主机报警规则
795795

‎analyze-slow-queries.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -41,7 +41,7 @@ summary: 学习如何定位和分析慢查询。
4141
- 慢日志记录了 SQL 从解析到返回，几乎所有阶段的耗时，较为全面（在 TiDB Dashboard 中可以直观地查询和分析慢日志）；
4242
- `explain analyze` 可以拿到 SQL 实际执行中每个执行算子的耗时，对执行耗时有更细分的统计；
4343

44-
总的来说，利用慢日志和 `explain analyze` 可以比较准确地定位查询的瓶颈点，帮助你判断这条 SQL 慢在哪个模块 (TiDB/TiKV) ，慢在哪个阶段，下面会有一些例子。
44+
总的来说，利用慢日志和 `explain analyze` 可以比较准确地定位查询的瓶颈点，帮助你判断这条 SQL 慢在哪个模块 (TiDB/TiKV)，慢在哪个阶段，下面会有一些例子。
4545

4646
另外在 4.0.3 之后，慢日志中的 `Plan` 字段也会包含 SQL 的执行信息，也就是 `explain analyze` 的结果，这样一来 SQL 的所有耗时信息都可以在慢日志中找到。
4747

@@ -112,7 +112,7 @@ summary: 学习如何定位和分析慢查询。
112112

113113
#### 取 TS 慢
114114

115-
可以对比慢日志中的 `Wait_TS` 和 `Query_time` ，因为 TS 有预取操作，通常来说 `Wait_TS` 应该很低。
115+
可以对比慢日志中的 `Wait_TS` 和 `Query_time`，因为 TS 有预取操作，通常来说 `Wait_TS` 应该很低。
116116

117117
```
118118
# Query_time: 0.0300000
@@ -131,7 +131,7 @@ TiDB 侧 Region 信息可能过期，此时 TiKV 可能返回 `regionMiss` 的
131131

132132
#### 子查询被提前执行
133133

134-
对于带有非关联子查询的语句，子查询部分可能被提前执行，如：`select * from t1 where a = (select max(a) from t2)` ，`select max(a) from t2` 部分可能在优化阶段被提前执行。这种查询用 `explain analyze` 看不到对应的耗时，如下：
134+
对于带有非关联子查询的语句，子查询部分可能被提前执行，如：`select * from t1 where a = (select max(a) from t2)`，`select max(a) from t2` 部分可能在优化阶段被提前执行。这种查询用 `explain analyze` 看不到对应的耗时，如下：
135135

136136
```sql
137137
mysql> explain analyze select count(*) from t where a=(select max(t1.a) from t t1, t t2 where t1.a=t2.a);

‎backup-and-restore-using-dumpling-lightning.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -84,7 +84,7 @@ SELECT table_name,table_schema,SUM(data_length)/1024/1024 AS data_length,SUM(ind
8484
8585
[tikv-importer]
8686
# "local"：默认使用该模式，适用于 TB 级以上大数据量，但导入期间下游 TiDB 无法对外提供服务。
87-
# "tidb"：TB 级以下数据量也可以采用`tidb`后端模式，下游 TiDB 可正常提供服务。 关于后端模式更多信息请参阅：https://docs.pingcap.com/tidb/stable/tidb-lightning-backends
87+
# "tidb"：TB 级以下数据量也可以采用`tidb`后端模式，下游 TiDB 可正常提供服务。关于后端模式更多信息请参阅：https://docs.pingcap.com/tidb/stable/tidb-lightning-backends
8888
backend = "local"
8989
# 设置排序的键值对的临时存放地址，目标路径必须是一个空目录，目录空间须大于待导入数据集的大小。建议设为与 `data-source-dir` 不同的磁盘目录并使用闪存介质，独占 IO 会获得更好的导入性能
9090
sorted-kv-dir = "${sorted-kv-dir}"

‎benchmark/benchmark-tidb-using-tpcc.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ tiup install bench
3737

3838
关于 TiUP Bench 组件的详细用法可参考 [TiUP Bench](/tiup/tiup-bench.md)。
3939

40-
假设已部署 TiDB 集群，其中 TiDB 节点部署在 172.16.5.140、 172.16.5.141 实例上，端口都为 4000 ，可按如下步骤进行 TPC-C 测试。
40+
假设已部署 TiDB 集群，其中 TiDB 节点部署在 172.16.5.140、 172.16.5.141 实例上，端口都为 4000，可按如下步骤进行 TPC-C 测试。
4141

4242
## 导入数据
4343

‎best-practices/tidb-best-practices.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -79,7 +79,7 @@ TiDB 支持完整的二级索引，并且是全局索引，很多查询可以通
7979
- 区分度比较大的列，通过索引能显著地减少过滤后的行数
8080
- 有多个查询条件时，可以选择组合索引，注意需要把等值条件的列放在组合索引的前面
8181

82-
这里举一个例子，假设常用的查询是 `select * from t where c1 = 10 and c2 = 100 and c3 > 10`, 那么可以考虑建立组合索引 `Index cidx (c1, c2, c3)`，这样可以用查询条件构造出一个索引前缀进行 Scan。
82+
这里举一个例子，假设常用的查询是 `select * from t where c1 = 10 and c2 = 100 and c3 > 10`，那么可以考虑建立组合索引 `Index cidx (c1, c2, c3)`，这样可以用查询条件构造出一个索引前缀进行 Scan。
8383

8484
+ 通过索引查询和直接扫描 Table 的区别
8585

‎br/backup-and-restore-storages.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -130,7 +130,7 @@ TiDB 支持 Amazon S3、Google Cloud Storage (GCS)、Azure Blob Storage 和 NFS
130130
- 备份时 TiKV 和 br 命令行工具需要的访问备份数据目录的最小权限：`s3:ListBucket`、`s3:PutObject` 和 `s3:AbortMultipartUpload`。
131131
- 恢复时 TiKV 和 br 命令行工具需要的访问备份数据目录的最小权限：`s3:ListBucket` 和 `s3:GetObject`。
132132

133-
如果你还没有创建备份数据保存目录，可以参考 [创建存储桶](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-bucket.html)在指定的区域中创建一个 S3 存储桶。如果需要使用文件夹，可以参考 [使用文件夹在 Amazon S3 控制台中组织对象](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-folder.html)在存储桶中创建一个文件夹。
133+
如果你还没有创建备份数据保存目录，可以参考[创建存储桶](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-bucket.html)在指定的区域中创建一个 S3 存储桶。如果需要使用文件夹，可以参考[使用文件夹在 Amazon S3 控制台中组织对象](https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/user-guide/create-folder.html)在存储桶中创建一个文件夹。
134134

135135
配置访问 Amazon S3 的账户可以通过以下两种方式：
136136

‎br/backup-and-restore-use-cases.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -44,13 +44,13 @@ aliases: ['/docs-cn/dev/br/backup-and-restore-use-cases/','/docs-cn/dev/referenc
4444
- 安装：
4545

4646
```shell
47-
`tiup install br:v6.5.0`
47+
tiup install br:v6.5.0
4848
```
4949

5050
- 升级：
5151

5252
```shell
53-
`tiup update br:v6.5.0`
53+
tiup update br:v6.5.0
5454
```
5555

5656
## 配置备份存储 (Amazon S3)

‎br/br-pitr-guide.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ aliases: ['/zh/tidb/dev/pitr-usage/']
88

99
全量备份包含集群某个时间点的全量数据，但是不包含其他时间点的更新数据，而 TiDB 日志备份能够将业务写入 TiDB 的数据记录及时备份到指定存储中。如果你需要灵活的选择恢复的时间点，即实现 Point-in-time recovery (PITR)，可以开启[日志备份](#开启日志备份)，并[定期执行快照（全量）备份](#定期执行全量备份)。
1010

11-
使用 br 命令行工具备份与恢复数据前，请先[安装 br 命令行工具](/br/br-use-overview.md#部署和使用-br) 。
11+
使用 br 命令行工具备份与恢复数据前，请先[安装 br 命令行工具](/br/br-use-overview.md#部署和使用-br)。
1212

1313
## 对集群进行备份
1414

@@ -102,7 +102,7 @@ Restore KV Files <--------------------------------------------------------------
102102

103103
### 能力指标
104104

105-
- PITR 恢复速度，平均到单台 TiKV 节点：全量恢复为 280 GB/h ，日志恢复为 30 GB/h
105+
- PITR 恢复速度，平均到单台 TiKV 节点：全量恢复为 280 GB/h，日志恢复为 30 GB/h
106106
- 使用 `br log truncate` 清理过期的日志备份数据速度为 600 GB/h
107107

108108
> **注意：**

‎br/br-snapshot-guide.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ aliases: ['/zh/tidb/dev/br-usage-backup/','/zh/tidb/dev/br-usage-restore/','/zh/
66

77
# TiDB 快照备份与恢复使用指南
88

9-
本文介绍如何使用 br 命令行工具进行 TiDB 快照备份和恢复。使用前，请先[安装 br 命令行工具](/br/br-use-overview.md#部署和使用-br) 。
9+
本文介绍如何使用 br 命令行工具进行 TiDB 快照备份和恢复。使用前，请先[安装 br 命令行工具](/br/br-use-overview.md#部署和使用-br)。
1010

1111
快照备份是集群全量备份的一种实现。它基于 TiDB 的[多版本并发控制 (MVCC)](/tidb-storage.md#mvcc) 实现，将指定快照包含的所有数据备份到目标存储中。备份下来的数据大小约等于集群（压缩后的）单副本数据大小。备份完成之后，你可以在一个空集群或不存在数据冲突（相同 schema 或 table）的集群执行快照备份恢复，将集群恢复到快照备份时的数据状态，同时恢复功能会依据集群副本设置恢复出多副本。
1212

‎br/external-storage.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ summary: 了解 BR、TiDB Lightning 和 Dumpling 中所用外部存储服务的
77

88
# 外部存储
99

10-
Backup & Restore (BR)、TiDB Lightning 和 Dumpling 都支持在本地文件系统和 Amazon S3 上读写数据；另外 BR 还支持 Google Cloud Storage、Azure Blob Storage (Azblob)。通过传入不同 URL scheme 到 br 工具 的 `--storage` (`-s`) 参数、TiDB Lightning 的 `-d` 参数及 Dumpling 中的 `--output` (`-o`) 参数，可以区分不同的存储方式。
10+
Backup & Restore (BR)、TiDB Lightning 和 Dumpling 都支持在本地文件系统和 Amazon S3 上读写数据；另外 BR 还支持 Google Cloud Storage、Azure Blob Storage (Azblob)。通过传入不同 URL scheme 到 br 工具的 `--storage` (`-s`) 参数、TiDB Lightning 的 `-d` 参数及 Dumpling 中的 `--output` (`-o`) 参数，可以区分不同的存储方式。
1111

1212
## Scheme
1313

‎character-set-gbk.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -59,7 +59,7 @@ SHOW COLLATION WHERE CHARSET = 'gbk';
5959
### 非法字符兼容性
6060

6161
* 在系统变量 [`character_set_client`](/system-variables.md#character_set_client) 和 [`character_set_connection`](/system-variables.md#character_set_connection) 不同时设置为 `gbk` 的情况下，TiDB 处理非法字符的方式与 MySQL 一致。
62-
* 在 `character_set_client` 和 `character_set_connection` 同时为 `gbk` 的情况下， TiDB 处理非法字符的方式与 MySQL 有所区别。
62+
* 在 `character_set_client` 和 `character_set_connection` 同时为 `gbk` 的情况下，TiDB 处理非法字符的方式与 MySQL 有所区别。
6363

6464
- MySQL 处理非法 GBK 字符集时，对读和写操作的处理方式不同。
6565
- TiDB 处理非法 GBK 字符集时，对读和写操作的处理方式相同。TiDB 在严格模式下读写非法 GBK 字符都会报错，在非严格模式下，读写非法 GBK 字符都会用 `?` 替换。
@@ -77,7 +77,7 @@ SHOW COLLATION WHERE CHARSET = 'gbk';
7777

7878
* 目前 TiDB 不支持通过 `ALTER TABLE` 语句将其它字符集类型改成 `gbk` 或者从 `gbk` 转成其它字符集类型。
7979

80-
* TiDB 不支持使用 `_gbk`， 比如：
80+
* TiDB 不支持使用 `_gbk`，比如：
8181

8282
```sql
8383
CREATE TABLE t(a CHAR(10) CHARSET BINARY);

‎check-before-deployment.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -196,7 +196,7 @@ TiDB 是一套分布式数据库系统，需要节点间保证时间的同步，
196196
Active: active (running) since Mon 2021-04-05 09:55:29 EDT; 3 days ago
197197
```
198198

199-
若发现系统既没有配置 `chronyd` 也没有配置 `ntpd` ，则表示系统尚未安装任一服务。此时，应先安装其中一个服务，并保证它可以自动启动，默认使用 `ntpd`。
199+
若发现系统既没有配置 `chronyd` 也没有配置 `ntpd`，则表示系统尚未安装任一服务。此时，应先安装其中一个服务，并保证它可以自动启动，默认使用 `ntpd`。
200200

201201
如果你使用的系统配置是 `chronyd`，请直接执行步骤 3。
202202

‎clinic/clinic-user-guide-for-tiup.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ summary: 详细介绍在使用 TiUP 部署的 TiDB 集群或 DM 集群上如何
99

1010
> **注意：**
1111
>
12-
> - 本文档**仅**适用于使用 TiUP 部署的集群。如需查看适用于使用 Operator 部署的集群，请参阅 [在 TiDB Operator 部署环境使用 PingCAP Clinic](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/clinic-user-guide)。
12+
> - 本文档**仅**适用于使用 TiUP 部署的集群。如需查看适用于使用 Operator 部署的集群，请参阅[在 TiDB Operator 部署环境使用 PingCAP Clinic](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/clinic-user-guide)。
1313
>
1414
> - PingCAP Clinic 暂时**不支持**对使用 TiDB Ansible 部署的集群进行数据采集。
1515

‎clinic/quick-start-with-clinic.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ PingCAP Clinic 由 Diag 诊断客户端（以下简称为 Diag）和 Clinic Serv
1616

1717
> **注意：**
1818
>
19-
> - 本文档提供的采集和上传数据的方式**仅**适用于使用 [TiUP 部署](/production-deployment-using-tiup.md)的集群。如需查看适用于使用 Operator 部署的集群，请参阅 [在 TiDB Operator 部署环境使用 PingCAP Clinic](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/clinic-user-guide)。
19+
> - 本文档提供的采集和上传数据的方式**仅**适用于使用 [TiUP 部署](/production-deployment-using-tiup.md)的集群。如需查看适用于使用 Operator 部署的集群，请参阅[在 TiDB Operator 部署环境使用 PingCAP Clinic](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/clinic-user-guide)。
2020
> - 通过 PingCAP Clinic 采集和上传的数据**仅**用于定位和诊断集群问题。
2121
2222
## 准备工作

‎command-line-flags-for-pd-configuration.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -48,7 +48,7 @@ PD 可以通过命令行参数或环境变量配置。
4848

4949
+ 初始化 PD 集群配置。
5050
+ 默认：`"{name}=http://{advertise-peer-url}"`
51-
+ 例如，如果 name 是 "pd", 并且 `advertise-peer-urls` 是 `http://192.168.100.113:2380`，那么 `initial-cluster` 就是 `pd=http://192.168.100.113:2380`。
51+
+ 例如，如果 name 是 "pd"，并且 `advertise-peer-urls` 是 `http://192.168.100.113:2380`，那么 `initial-cluster` 就是 `pd=http://192.168.100.113:2380`。
5252
+ 如果你需要启动三台 PD，那么 `initial-cluster` 可能就是 `pd1=http://192.168.100.113:2380, pd2=http://192.168.100.114:2380, pd3=192.168.100.115:2380`。
5353

5454
## `--join`

‎configure-load-base-split.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ Load Base Split 是 TiKV 在 4.0 版本引入的特性，旨在解决 Region 访
2525

2626
Load Base Split 会基于统计信息自动拆分 Region。通过统计信息识别出读流量或 CPU 使用率在 10s 内持续超过阈值的 Region，并在合适的位置将这些 Region 拆分。在选择拆分的位置时，会尽可能平衡拆分后两个 Region 的访问量，并尽量避免跨 Region 的访问。
2727

28-
Load Base Split 后的 Region 不会被迅速 Merge。一方面，PD 的 `MergeChecker` 会跳过 hot Region ，另一方面 PD 也会针对心跳信息中的 `QPS`去进行判断，避免 Merge 两个 `QPS` 很高的 Region。
28+
Load Base Split 后的 Region 不会被迅速 Merge。一方面，PD 的 `MergeChecker` 会跳过 hot Region，另一方面 PD 也会针对心跳信息中的 `QPS`去进行判断，避免 Merge 两个 `QPS` 很高的 Region。
2929

3030
## 使用方法
3131

‎dashboard/continuous-profiling.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -55,7 +55,7 @@ summary: 了解如何持续地收集 TiDB、TiKV、PD 各个实例的性能数
5555
你可以通过以下步骤启用该功能：
5656

5757
1. 访问[持续性能分析页面](#访问页面)。
58-
2. 点击**打开设置** (Open Settings)。在右侧**设置** (Settings) 页面，将**启用特性** (Enable Feature) 下方的开关打开。设置**保留时间** (Retention Period)， 默认值为 3 天。
58+
2. 点击**打开设置** (Open Settings)。在右侧**设置** (Settings) 页面，将**启用特性** (Enable Feature) 下方的开关打开。设置**保留时间** (Retention Period)，默认值为 3 天。
5959
3. 点击**保存** (Save)。
6060

6161
![启用功能](/media/dashboard/dashboard-conprof-start.png)

‎dashboard/dashboard-diagnostics-usage.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,7 @@ aliases: ['/docs-cn/dev/dashboard/dashboard-diagnostics-usage/']
3333
上面诊断结果显示，在诊断的时间内可能有大查询，下面的每一行的含义是：
3434

3535
* `tidb_qps`：QPS 下降 0.93 倍。
36-
* `tidb_query_duration`：P999的查询延迟上升 1.54 倍。
36+
* `tidb_query_duration`：P999 的查询延迟上升 1.54 倍。
3737
* `tidb_cop_duration`：P999 的 COP 请求的处理延迟上升 2.48 倍。
3838
* `tidb_kv_write_num`：P999 的 tidb 的事务写入 kv 数量上升 7.61 倍。
3939
* `tikv_cop_scan_keys_total_nun`：TiKV 的 coprocessor 扫描 key/value 的数量分别在 3 台 TiKV 上有很大的提升。
@@ -60,7 +60,7 @@ digest | 24bd6d8a9b238086c9b8c3d240ad4ef32f79ce94cf5a468c0b8fe1eb5f8
6060

6161
可以发现，从 13:24:30 开始有一个批量删除的大写入，一共执行了 196 次，每次删除 5000 行数据，总共耗时 46.8 秒。
6262

63-
#### 示例2
63+
#### 示例 2
6464

6565
如果大查询一直没执行完，就不会记录慢日志，但仍可以进行诊断，示例如下：
6666

@@ -98,7 +98,7 @@ MESSAGE | [expensivequery.go:167] [expensive_query] [cost_time=60.085949605s] [
9898

9999
上图中，也是在跑 go-ycsb 的压测，可以发现，在 `2020-05-22 22:14:00` 时，QPS 突然开始下降，大概在持续 3 分钟后恢复。
100100

101-
生成以下2个时间范围的对比报告：
101+
生成以下 2 个时间范围的对比报告：
102102

103103
- t1: 2020-05-22 22:11:00 - 2020-05-22 22:14:00，正常时间段。
104104
- t2: 2020-05-22 22:14:00 - 2020-05-22 22:17:00，QPS 开始下降的异常时间段。

‎dashboard/dashboard-ops-reverse-proxy.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -66,7 +66,7 @@ http://192.168.0.123:2379/dashboard/
6666
6767
2. 重启 HAProxy，以使配置生效。
6868
69-
3. 测试反向代理是否生效：访问 HAProxy 所在机器的 8033 端口下 `/dashboard/` 地址，如 <http://example.com:8033/dashboard/> ，即可访问 TiDB Dashboard。
69+
3. 测试反向代理是否生效：访问 HAProxy 所在机器的 8033 端口下 `/dashboard/` 地址，如 <http://example.com:8033/dashboard/>，即可访问 TiDB Dashboard。
7070
7171
</details>
7272
@@ -98,7 +98,7 @@ http://192.168.0.123:2379/dashboard/
9898
sudo nginx -s reload
9999
```
100100
101-
3. 测试反向代理是否生效：访问 NGINX 所在机器的 8033 端口下 `/dashboard/` 地址，如 `http://example.com:8033/dashboard/` ，即可访问 TiDB Dashboard。
101+
3. 测试反向代理是否生效：访问 NGINX 所在机器的 8033 端口下 `/dashboard/` 地址，如 `http://example.com:8033/dashboard/`，即可访问 TiDB Dashboard。
102102
103103
</details>
104104

‎dashboard/dashboard-ops-security.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -29,7 +29,7 @@ TiDB Dashboard 的账号体系与 TiDB SQL 用户一致，并基于 TiDB SQL 用
2929

3030
> **注意：**
3131
>
32-
> TiDB v6.5.0 且 TiDB Operator v1.4.0之后，在 Kubernetes 上支持将 TiDB Dashboard 作为独立的 Pod 部署。在 TiDB Operator 环境，可直接访问该 Pod 的 IP 来打开 TiDB Dashboard，该端口不与其他 PD 内部特权接口关联，对外提供该端口不需要额外的防火墙操作。具体信息，参考 [TiDB Operator 部署独立的 TiDB Dashboard](https://docs.pingcap.com/zh/tidb-in-kubernetes/dev/get-started#部署独立的-tidb-dashboard)。
32+
> TiDB v6.5.0 且 TiDB Operator v1.4.0 之后，在 Kubernetes 上支持将 TiDB Dashboard 作为独立的 Pod 部署。在 TiDB Operator 环境，可直接访问该 Pod 的 IP 来打开 TiDB Dashboard，该端口不与其他 PD 内部特权接口关联，对外提供该端口不需要额外的防火墙操作。具体信息，参考 [TiDB Operator 部署独立的 TiDB Dashboard](https://docs.pingcap.com/zh/tidb-in-kubernetes/dev/get-started#部署独立的-tidb-dashboard)。
3333
3434
TiDB Dashboard 通过 PD Client 端口提供服务，默认为 <http://IP:2379/dashboard/>。尽管 TiDB Dashboard 需要验证身份，但 PD Client 端口上承载的其他 PD 内部特权接口不需要验证身份，且能进行特权操作，例如 <http://IP:2379/pd/api/v1/members>。因此，将 PD Client 端口直接暴露给外部网络具有极大的风险。
3535

‎dashboard/dashboard-session-sso.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -210,7 +210,7 @@ TiDB Dashboard 支持基于 [OIDC](https://openid.net/connect/) 协议的单点
210210
211211
![Settings](/media/dashboard/dashboard-session-sso-casdoor-settings-1.png)
212212
213-
4. 填写**名称**和**显示名称**，比如：**TiDB Dashboard** 。
213+
4. 填写**名称**和**显示名称**，比如：**TiDB Dashboard**。
214214
215215
5. 在**回调 URLs** 中添加如下内容：
216216

0 commit comments

Comments
 (0)