Merge pull request pingcap#805 from lilin90/metadata-title

*: update metadata of docs-cn files
lilin90 · Jul 13, 2018 · b185ab3 · b185ab3
2 parents 397cf17 + 9058c86
commit b185ab3
Show file tree

Hide file tree

Showing 45 changed files with 120 additions and 111 deletions.
diff --git a/QUICKSTART.md b/QUICKSTART.md
@@ -1,5 +1,5 @@
 ---
-title: 快速入门指南
+title: TiDB 快速入门指南
 category: deployment
 ---
 

diff --git a/ROADMAP.md b/ROADMAP.md
@@ -1,3 +1,8 @@
+---
+title: TiDB 路线图
+category: Roadmap
+---
+
 # TiDB 路线图
 
 ## TiDB：

diff --git a/benchmark/sysbench-v2.md b/benchmark/sysbench-v2.md
@@ -1,37 +1,36 @@
 ---
 title: TiDB Sysbench 性能对比测试报告 - v2.0.0 对比 v1.0.0
-category: benchmark 
---- 
+category: benchmark
+---
 
 # TiDB Sysbench 性能对比测试报告 - v2.0.0 对比 v1.0.0
 
 ## 测试目的
 
 对比 TiDB 2.0 版本和 1.0 版本在 OLTP 场景下的性能。
 
-## 测试版本、时间、地点 
+## 测试版本、时间、地点
 
-TiDB 版本：v1.0.8 Vs v2.0.0-rc6 
+TiDB 版本：v1.0.8 Vs v2.0.0-rc6
 
 时间：2018 年 4 月
 
-地点：北京      
+地点：北京
 
 ## 测试环境
- 
-IDC 机器       
- 
+
+IDC 机器
+
 | 类别 | 名称 |  
-| :--------: | :---------: | 
-| OS | Linux (CentOS 7.3.1611) |   
+| :--------: | :---------: |
+| OS | Linux (CentOS 7.3.1611) |
 | CPU | 40 vCPUs, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz |
-| RAM | 128GB | 
+| RAM | 128GB |
 | DISK | Optane 500GB SSD * 1 |  
 
 Sysbench 测试脚本：
 https://github.com/pingcap/tidb-bench/tree/master/sysbench   
 
-
 ## 测试方案
 
 ### TiDB 版本信息

diff --git a/benchmark/sysbench.md b/benchmark/sysbench.md
@@ -1,38 +1,38 @@
 ---
 title: TiDB Sysbench 性能测试报告 - v1.0.0
-category: benchmark 
+category: benchmark
 draft: true
---- 
+---
 
 # TiDB Sysbench 性能测试报告 - v1.0.0
 
 ## 测试目的
+
 测试 TiDB 在 OLTP 场景下的性能以及水平扩展能力。
 
 > **注意**: 不同的测试环境可能使测试结果发生改变。
 
-## 测试版本、时间、地点 
+## 测试版本、时间、地点
 
 TiDB 版本：v1.0.0 
 时间：2017 年 10 月 20 日
-地点：北京      
+地点：北京
 
 ## 测试环境
- 
- IDC机器       
- 
+
+IDC 机器
+
 | 类别       |  名称       |  
 | :--------: | :---------: | 
 | OS       | linux (CentOS 7.3.1611)       |   
 | CPU | 40 vCPUs, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz |
 | RAM | 128GB | 
 | DISK | 1.5T SSD * 2  + Optane SSD * 1 |  
 
-Sysbench 版本: 1.0.6   
+Sysbench 版本: 1.0.6
 
 测试脚本: https://github.com/pingcap/tidb-bench/tree/cwen/not_prepared_statement/sysbench
 
-
 ## 测试方案
 
 ### 场景一：sysbench 标准性能测试

diff --git a/benchmark/tpch.md b/benchmark/tpch.md
@@ -1,5 +1,5 @@
 ---
-title: TiDB TPC-H 50G 性能测试报告 - v2.0
+title: TiDB TPC-H 50G 性能测试报告
 category: benchmark
 ---
 

diff --git a/op-guide/ansible-deployment-scale.md b/op-guide/ansible-deployment-scale.md
@@ -5,7 +5,7 @@ category: deployment
 
 # 使用 TiDB Ansible 扩容缩容 TiDB 集群
 
-TiDB  集群可以在不影响线上服务的情况下进行扩容和缩容。以下缩容示例中，被移除的节点没有混合部署其他服务；如果混合部署了其他服务，不能按如下操作。
+TiDB 集群可以在不影响线上服务的情况下进行扩容和缩容。以下缩容示例中，被移除的节点没有混合部署其他服务；如果混合部署了其他服务，不能按如下操作。
 
 假设拓扑结构如下所示：
 

diff --git a/op-guide/backup-restore.md b/op-guide/backup-restore.md
@@ -7,7 +7,6 @@ category: advanced
 
 ## 概述
 
-
 该文档详细介绍了如何对 TiDB 进行备份恢复。本文档暂时只考虑全量备份与恢复。
 
 这里我们假定 TiDB 服务信息如下：
@@ -16,13 +15,11 @@ category: advanced
 |----|-------|----|----|--------|
 |TiDB|127.0.0.1|4000|root|*|
 
-
-在这个备份恢复过程中，我们会用到下面的工具:
+在这个备份恢复过程中，我们会用到下面的工具：
 
 - mydumper 从 TiDB 导出数据
 - loader 导入数据到 TiDB
 
-
 ### 下载 TiDB 工具集 (Linux)
 
 ```bash
@@ -37,22 +34,23 @@ tar -xzf tidb-enterprise-tools-latest-linux-amd64.tar.gz
 cd tidb-enterprise-tools-latest-linux-amd64
 ```
 
-
 ## 使用 `mydumper`/`loader` 全量备份恢复数据
 
 `mydumper` 是一个强大的数据备份工具，具体可以参考 [https://github.com/maxbube/mydumper](https://github.com/maxbube/mydumper)。
 
 我们使用 `mydumper` 从 TiDB 导出数据进行备份，然后用 `loader` 将其导入到 TiDB 里面进行恢复。
 
-> 注意：虽然 TiDB 也支持使用 MySQL 官方的 `mysqldump` 工具来进行数据的备份恢复工作，但相比于 `mydumper` / `loader`，性能会慢很多，大量数据的备份恢复会花费很多时间，这里我们并不推荐。
+> **注意**：虽然 TiDB 也支持使用 MySQL 官方的 `mysqldump` 工具来进行数据的备份恢复工作，但相比于 `mydumper` / `loader`，性能会慢很多，大量数据的备份恢复会花费很多时间，这里我们并不推荐。
 
 ### `mydumper`/`loader` 全量备份恢复最佳实践
+
 为了快速的备份恢复数据 (特别是数据量巨大的库), 可以参考下面建议
 
 * 使用 mydumper 导出来的数据文件尽可能的小, 最好不要超过 64M, 可以设置参数 -F 64 
 * loader的 `-t` 参数可以根据 tikv 的实例个数以及负载进行评估调整，例如 3个 tikv 的场景， 此值可以设为 `3 *(1 ～ n)`；当 tikv 负载过高，loader 以及 tidb 日志中出现大量 `backoffer.maxSleep 15000ms is exceeded` 可以适当调小该值，当 tikv 负载不是太高的时候，可以适当调大该值。
 
 #### 某次数据恢复示例，以及相关的配置
+
  - mydumper 导出后总数据量 214G，单表 8 列，20 亿行数据
  - 集群拓扑
      - TIKV * 12
@@ -76,8 +74,6 @@ cd tidb-enterprise-tools-latest-linux-amd64
 
 `--skip-tz-utc` 添加这个参数忽略掉 TiDB 与导数据的机器之间时区设置不一致的情况，禁止自动转换。
 
-
-
 ### 向 TiDB 恢复数据
 
 我们使用 `loader` 将之前导出的数据导入到 TiDB，完成恢复操作。Loader 的下载和具体的使用方法见 [Loader 使用文档](../tools/loader.md)
@@ -86,7 +82,7 @@ cd tidb-enterprise-tools-latest-linux-amd64
 ./bin/loader -h 127.0.0.1 -u root -P 4000 -t 32 -d ./var/test
 ```
 
-导入成功之后，我们可以用 MySQL 官方客户端进入 TiDB，查看:
+导入成功之后，我们可以用 MySQL 官方客户端进入 TiDB，查看：
 
 ```sql
 mysql -h127.0.0.1 -P4000 -uroot

diff --git a/op-guide/docker-compose.md b/op-guide/docker-compose.md
@@ -1,5 +1,5 @@
 ---
-title: 使用 Docker Compose 构建集群
+title: 使用 Docker Compose 快速构建集群
 category: deployment
 ---
 

diff --git a/op-guide/generate-self-signed-certificates.md b/op-guide/generate-self-signed-certificates.md
@@ -20,8 +20,6 @@ category: deployment
 | node5 | 172.16.10.5 | TiKV2      |
 | node6 | 172.16.10.6 | TiKV3      |
 
-
-
 ## 下载 cfssl
 
 假设使用 x86_64 Linux 主机：
@@ -34,11 +32,9 @@ chmod +x ~/bin/{cfssl,cfssljson}
 export PATH=$PATH:~/bin
 ```
 
-
-
 ## 初始化证书颁发机构
 
-生成 cfssl 的默认配置，以便于之后修改： 
+生成 cfssl 的默认配置，以便于之后修改：
 
 ```bash
 mkdir ~/cfssl
@@ -47,8 +43,6 @@ cfssl print-defaults config > ca-config.json
 cfssl print-defaults csr > ca-csr.json
 ```
 
-
-
 ## 生成证书
 
 #### 证书介绍
@@ -60,7 +54,7 @@ cfssl print-defaults csr > ca-csr.json
 
 #### 配置 CA 选项
 
-根据实际需求修改 `ca-config.json` ：  
+根据实际需求修改 `ca-config.json`：  
 
 ```json
 {

diff --git a/op-guide/history-read.md b/op-guide/history-read.md
@@ -19,9 +19,9 @@ TiDB 实现了通过标准 SQL 接口读取历史数据功能，无需特殊的
 “2016-10-08 16:45:26.999”，一般来说可以只写到秒，比如”2016-10-08 16:45:26”。
 当这个变量被设置时，TiDB 会用这个时间戳建立 Snapshot（没有开销，只是创建数据结构），随后所有的 Select 操作都会在这个 Snapshot 上读取数据。
 
-> 注意 TiDB 的事务是通过 PD 进行全局授时，所以存储的数据版本也是以 PD 所授时间戳作为版本号。在生成 Snapshot ·时，是以 tidb_snapshot 变量的值作为版本号，如果 TiDB Server 所在机器和 PD Server 所在机器的本地时间相差较大，需要以 PD 的时间为准。
+> **注意**：TiDB 的事务是通过 PD 进行全局授时，所以存储的数据版本也是以 PD 所授时间戳作为版本号。在生成 Snapshot 时，是以 tidb_snapshot 变量的值作为版本号，如果 TiDB Server 所在机器和 PD Server 所在机器的本地时间相差较大，需要以 PD 的时间为准。
 
-当读取历史版本操作结束后，可以结束当前 Session 或者是通过 Set 语句将 tidb_snapshot 变量的值设为 ”“，即可读取最新版本的数据。
+当读取历史版本操作结束后，可以结束当前 Session 或者是通过 Set 语句将 tidb_snapshot 变量的值设为 ""，即可读取最新版本的数据。
 
 ## 历史数据保留策略
 

diff --git a/op-guide/horizontal-scale.md b/op-guide/horizontal-scale.md
@@ -9,7 +9,7 @@ category: deployment
 
 TiDB 集群可以在不影响线上服务的情况下动态进行扩容和缩容。
 
-> 如果使用 Ansible 部署 TiDB 集群，请参考[使用 Ansible 扩容缩容](ansible-deployment-scale.md)。
+> **注**：如果使用 Ansible 部署 TiDB 集群，请参考[使用 Ansible 扩容缩容](ansible-deployment-scale.md)。
 
 下面分别介绍如何增加或者删除 PD，TiKV 以及 TiDB 的节点。
 

diff --git a/op-guide/migration.md b/op-guide/migration.md
@@ -9,17 +9,17 @@ category: advanced
 
 `mydumper` 是一个更强大的数据迁移工具，具体可以参考 [https://github.com/maxbube/mydumper](https://github.com/maxbube/mydumper)。
 
-我们使用 `mydumper` 从 MySQL 导出数据，然后用 `loader` 将其导入到 TiDB 里面。
+你可以使用 `mydumper` 从 MySQL 导出数据，然后用 `loader` 将其导入到 TiDB 里面。
 
-> 注意：虽然 TiDB 也支持使用 MySQL 官方的 `mysqldump` 工具来进行数据的迁移工作，但相比于 `mydumper` / `loader`，性能会慢很多，大量数据的迁移会花费很多时间，这里我们并不推荐。
+> **注意**：虽然 TiDB 也支持使用 MySQL 官方的 `mysqldump` 工具来进行数据的迁移工作，但相比于 `mydumper` / `loader`，性能会慢很多，大量数据的迁移会花费很多时间，这里我们并不推荐。
 
 ### `mydumper`/`loader` 全量导入数据最佳实践
 
-为了快速的迁移数据 (特别是数据量巨大的库), 可以参考下面建议
+为了快速的迁移数据 (特别是数据量巨大的库)，可以参考下面建议
 
-* mydumper 导出数据至少要拥有 `SELECT` , `RELOAD` , `LOCK TABLES` 权限
-* 使用 mydumper 导出来的数据文件尽可能的小, 最好不要超过 64M, 可以设置参数 -F 64
-* loader的 -t 参数可以根据 tikv 的实例个数以及负载进行评估调整，例如 3个 tikv 的场景， 此值可以设为 3 *（1 ～ n)；当 tikv 负载过高，loader 以及 tidb 日志中出现大量 `backoffer.maxSleep 15000ms is exceeded` 可以适当调小该值，当 tikv 负载不是太高的时候，可以适当调大该值。
+* mydumper 导出数据至少要拥有 `SELECT`，`RELOAD`，`LOCK TABLES` 权限
+* 使用 mydumper 导出来的数据文件尽可能的小，最好不要超过 64M，可以设置参数 -F 64
+* loader的 -t 参数可以根据 tikv 的实例个数以及负载进行评估调整，例如 3个 tikv 的场景，此值可以设为 3 *（1 ～ n)；当 tikv 负载过高，loader 以及 tidb 日志中出现大量 `backoffer.maxSleep 15000ms is exceeded` 可以适当调小该值，当 tikv 负载不是太高的时候，可以适当调大该值。
 
 #### 某次导入示例，以及相关的配置
 

diff --git a/op-guide/monitor.md b/op-guide/monitor.md
@@ -12,6 +12,7 @@ TiDB 集群状态监控目前有两种接口，第一种是通过 HTTP 接口对
 这类接口可以获取组件的一些基本信息，并且可以作为 keepalive 监测接口。另外 PD 的接口可以看到整个 TiKV 集群的详细信息。
 
 ### TiDB Server
+
 TiDB 对外暴露的 HTTP 接口是 http://host:port/status ，默认的端口号是 10080 （可以通过 --status 参数设置），可以通过访问这个接口获取当前 TiDB Server 的状态，以及判断是否存活。返回结果是 **Json** 格式：
 
 ```bash

diff --git a/op-guide/offline-ansible-deployment.md b/op-guide/offline-ansible-deployment.md
@@ -7,12 +7,12 @@ category: deployment
 
 ## 准备机器
 
-1.  下载机一台
+1. 下载机一台
 
     - 该机器需开放外网访问，用于下载 TiDB-Ansible、TiDB 及相关软件安装包。
     - 推荐安装 CentOS 7.3 及以上版本 Linux 操作系统。
 
-2.  部署目标机器若干及部署中控机一台
+2. 部署目标机器若干及部署中控机一台
 
     - 系统要求及配置参考[准备机器](ansible-deployment.md#准备机器)。
     - 可以无法访问外网。

diff --git a/op-guide/recommendation.md b/op-guide/recommendation.md
@@ -1,5 +1,5 @@
 ---
-title: 软件和硬件环境要求
+title: TiDB 软件和硬件环境要求
 category: deployment
 ---
 

diff --git a/op-guide/security.md b/op-guide/security.md
@@ -14,8 +14,6 @@ category: deployment
 
 MySQL Client 与 TiDB 之间使用一套证书，TiDB 集群组件之间使用另外一套证书。
 
-
-
 ## TiDB 集群组件间开启 TLS（双向认证）
 
 ### 准备证书

diff --git a/op-guide/tidb-config-file.md b/op-guide/tidb-config-file.md
@@ -1,9 +1,9 @@
 ---
-title: TiDB 配置文件解释
+title: TiDB 配置项解释
 category: deployment
 ---
 
-# TiDB 配置文件
+# TiDB 配置项解释
 
 TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/config.toml.example](https://github.com/pingcap/tidb/blob/master/config/config.toml.example) 找到默认的配置文件，重命名为 config.toml 即可。
 

diff --git a/op-guide/try-tidb.md b/op-guide/try-tidb.md
@@ -5,7 +5,6 @@ category: quick start
 
 # Try TiDB
 
-
 TiDB 支持 `SQL92` 标准并兼容 MySQL 语法，目前已经实现了大多数常用的 MySQL 语法。用户可以直接使用现有的 MySQL 客户端连接。如果现有的业务已经基于 MySQL 开发，大多数情况不需要修改代码即可直接替换单机的 MySQL。
 
 

diff --git a/sql/admin.md b/sql/admin.md
@@ -3,6 +3,8 @@ title: 数据库管理语句
 category: user guide
 ---
 
+# 数据库管理语句
+
 TiDB 可以通过一些语句对数据库进行管理，包括设置权限、修改系统变量、查询数据库状态。
 
 ## 权限管理

diff --git a/sql/bit-functions-and-operators.md b/sql/bit-functions-and-operators.md
@@ -1,5 +1,5 @@
 ---
-title: TiDB 用户文档
+title: 位函数和操作符
 category: user guide
 ---
 

diff --git a/sql/cast-functions-and-operators.md b/sql/cast-functions-and-operators.md
@@ -1,15 +1,13 @@
 ---
-title: TiDB 用户文档
+title: Cast 函数和操作符
 category: user guide
 ---
 
-
-
 # Cast 函数和操作符
 
 Cast 函数和操作符用于将某种数据类型的值转换为另一种数据类型。TiDB 中该函数和操作符的使用方法与 MySQL基本一致，详情参见: [Cast Functions and Operators](https://dev.mysql.com/doc/refman/5.7/en/cast-functions.html).
 
-**Cast 函数和操作符表**
+## Cast 函数和操作符表
 
 | 函数和操作符名 | 功能描述 |
 | --------------- | ----------------------------------- |

diff --git a/sql/character-set-configuration.md b/sql/character-set-configuration.md
@@ -7,4 +7,4 @@ category: user guide
 
 目前 TiDB 还没有相应的配置来设置字符集，默认为 utf8。
 
-更多[细节](https://dev.mysql.com/doc/refman/5.7/en/charset-configuration.html)
+更多[细节](https://dev.mysql.com/doc/refman/5.7/en/charset-configuration.html)。
-Original file line number
+Diff line change
@@ Expand Up @@
     这类接口可以获取组件的一些基本信息，并且可以作为 keepalive 监测接口。另外 PD 的接口可以看到整个 TiKV 集群的详细信息。
     ### TiDB Server
     TiDB 对外暴露的 HTTP 接口是 http://host:port/status ，默认的端口号是 10080 （可以通过 --status 参数设置），可以通过访问这个接口获取当前 TiDB Server 的状态，以及判断是否存活。返回结果是 **Json** 格式：
     ```bash
@@ Expand Down @@
Original file line number	Diff line number	Diff line change
Expand Up		@@ -14,8 +14,6 @@ category: deployment

		MySQL Client 与 TiDB 之间使用一套证书，TiDB 集群组件之间使用另外一套证书。



		## TiDB 集群组件间开启 TLS（双向认证）

		### 准备证书
Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -5,7 +5,6 @@ category: quick start

		# Try TiDB


		TiDB 支持 `SQL92` 标准并兼容 MySQL 语法，目前已经实现了大多数常用的 MySQL 语法。用户可以直接使用现有的 MySQL 客户端连接。如果现有的业务已经基于 MySQL 开发，大多数情况不需要修改代码即可直接替换单机的 MySQL。


Expand Down
Original file line number	Diff line number	Diff line change
Expand Up		@@ -7,4 +7,4 @@ category: user guide

		目前 TiDB 还没有相应的配置来设置字符集，默认为 utf8。

		更多[细节](https://dev.mysql.com/doc/refman/5.7/en/charset-configuration.html)
		更多[细节](https://dev.mysql.com/doc/refman/5.7/en/charset-configuration.html)。