*: fix all markdown format under pdf

README.md

@@ -37,10 +37,10 @@
   - [读取历史版本数据](op-guide/history-read.md)
   - [故障诊断](trouble-shooting.md)
 - [TiSpark 用户指南](op-guide/tispark_user_guide.md)
+- [常见问题与解答](FAQ.md)
 + 更多资源
   - [常用工具](https://github.com/pingcap/tidb-tools)
   - [PingCAP 团队技术博客](https://pingcap.com/bloglist-zh.html)
-- [常见问题与解答](FAQ.md)
 
 ## TiDB 简介
 

op-guide/ansible-deployment.md

@@ -287,7 +287,8 @@ pd_servers
 
 > TiDB 服务数据迁移、性能调优等更多高级功能请参考 [https://github.com/pingcap/docs-cn](https://github.com/pingcap/docs-cn)
 
-## FAQ
+## 常见部署问题
+
 ### TiDB 各版本下载链接
 
 -   Master 版本:
@@ -300,7 +301,8 @@ pd_servers
 
 ### 如何下载安装 RC4 版本 TiDB
 
-> inventory.ini 文件中指定的 TiDB 默认版本为 master 版本 `tidb_version = latest`, 如需安装 TiDB rc4 版本，先下载 TiDB-Ansible rc4 分支，确认 inventory.ini 文件中 `tidb_version = rc4`。安装步骤同上。
+`inventory.ini` 文件中指定的 TiDB 默认版本为 master 版本 `tidb_version = latest`, 如需安装 TiDB rc4 版本，
+需要先下载 TiDB-Ansible rc4 分支，确认 inventory.ini 文件中 `tidb_version = rc4`。安装步骤同上。
 
 从 github 下载 TiDB-Ansile rc4 分支
 

op-guide/binary-deployment.md

@@ -157,7 +157,7 @@ cd tidb-latest-linux-amd64-centos6
     ```
 
 > 注意：在生产环境中启动 TiKV 时，建议使用 [\-\-config](configuration.md#-c---config) 参数指定配置文件路径，如果不设置这个参数，TiKV 不会读取配置文件。同样，在生产环境中部署 PD 时，也建议使用 [\-\-config](configuration.md#--config) 参数指定配置文件路径。
->
+
 > 注意：如果使用 `nohup` 在生产环境中启动集群，需要将启动命令放到一个脚本文件里面执行，否则会出现因为 Shell 退出导致 `nohup` 启动的进程也收到异常信号退出的问题，具体参考[进程异常退出](../trouble-shooting.md#tidbtikvpd-进程异常退出)。
 
 ## 功能性测试部署

op-guide/dashboard-overview-info.md

@@ -5,44 +5,87 @@ category: monitoring
 
 # 重要监控指标详解
 
-> 使用 ansible 部署 tidb 集群时，一键部署监控系统 (prometheus/grafana)，监控架构请看 [TiDB 监控框架概述](../op-guide/monitor-overview.md)  
-> 目前 grafana dashboard 整体分为四个dashboard，node_export，PD，TIDB，TIKV。 内容较多，主要在于尽快让 TIDB 开发确认问题。  
-> 对于日常运维，我们单独挑选出重要的 metrics 放在 overview 页面，方便日常运维人员观察集群组件(PD,TIDB,TIKV)使用状态以及集群使用状态 。  
-> 以下为 overview dashboard 说明。  
+使用 ansible 部署 tidb 集群时，一键部署监控系统 (prometheus/grafana)，监控架构请看 [TiDB 监控框架概述](../op-guide/monitor-overview.md)
 
+目前 grafana dashboard 整体分为四个 dashboard，node_export，PD，TIDB，TIKV。 内容较多，主要在于尽快让 TIDB 开发确认问题。
 
+对于日常运维，我们单独挑选出重要的 metrics 放在 overview 页面，方便日常运维人员观察集群组件(PD, TIDB, TIKV)使用状态以及集群使用状态 。
+
+以下为 overview dashboard 说明：
 
 ## 说明
 
-服务	|	panel name	|	说明	|	正常范围
----	|	---	|	---	|	---
-PD	|	Storage Capacity	|	tidb 集群总可用数据库空间大小	|	
-PD	|	Current Storage Size	|	tidb 集群目前已用数据库空间大小	|	
-PD	|	Store Status  -- up store	|	tikv 正常节点数量	|	
-PD	|	Store Status  -- down store	|	tikv 异常节点数量	|	如果大于0，证明有节点不正常
-PD	|	Store Status  -- offline store	|	手动执行下线操作tikv节点数量	|	
-PD	|	Store Status  -- Tombstone store	|	下线成功的tikv节点数量	|	
-PD	|	Current storage usage	|	tikv 集群存储空间占用率	|	超过 80% 应考虑添加 tikv 节点
-PD	|	99% completed_cmds_duration_seconds	|	99% pd-server 请求完成时间	|	小于 5ms
-PD	|	average completed_cmds_duration_seconds	|	pd-server 请求平均完成时间	|	小于 50ms
-PD	|	leader balance ratio	|	leader ratio 最大的节点与最小的节点的差	|	均衡状况下一般小于 5%，节点重启时会比较大
-PD	|	region balance ratio	|	region ratio 最大的节点与最小的节点的差	|	均衡状况下一般小于 5%，新增/下线节点时会比较大		
-TiDB	|	handle_requests_duration_seconds	|	请求PD获取TSO响应时间	|	小于100ms
-TiDB	|	tidb server QPS	|	集群的请求量	|	这个和业务相关
-TiDB	|	connection count	|	从业务服务器连接到数据库的连接数	|	和业务相关。但是如果连接数发生跳变，需要查明原因。比如突然掉为0，可以检查网络是否中断；如果突然上涨，需要检查业务。
-TiDB	|	statement count	|	单位时间内不同类型语句执行的数目	|	这个和业务相关
-TiDB	|	Query Duration 99th percentile	|	99% 的query时间	|	
-TiKV	|	99%  & 99.99%  scheduler command duration	|	99% & 99.99% 命令执行的时间	|	99% 小于 50ms；99.99% 小于100ms
-TiKV	|	95%  & 99% storage async_request duration	|	95%  & 99% Raft 命令执行时间	|	95% 小于 50ms；99% 小于100ms
-TiKV	|	server report failure message	|	发送失败或者收到了错误的 message	|	如果出现了大量的 unreachadble 的消息，表明系统网络出现了问题。如果有 store not match 这样的错误，表明收到了不属于这个集群发过来的消息
-TiKV	|	Vote	|	Raft vote 的频率	|	通常这个值只会在发生 split 的时候有变动，如果长时间出现了 vote 偏高的情况，证明系统出现了严重的问题，有一些节点无法工作了
-TiKV	|	95% & 99% coprocessor request duration	|	95% & 99%  coprocessor 执行时间	|	和业务相关，但通常不会出现持续高位的值
-TiKV	|	Pending task	|	累积的任务数量	|	除了 pd worker，其他任何偏高都属于异常
-TiKV	|	stall	|	RocksDB Stall 时间	|	大于 0，表明 RocksDB 忙不过来，需要注意 IO 和 CPU 了
-TiKV	|	channel full	|	channel 满了，表明线程太忙无法处理	|	如果大于 0，表明线程已经没法处理了
-TiKV	|	95% send_message_duration_seconds	|	95% 发送消息的时间	|	小于50ms
-TiKV	|	leader/region	|	每个tikv的leader/region数量	|	和业务相关
+-   PD
+    - 	Storage Capacity	 : 	tidb 集群总可用数据库空间大小
+    - 	Current Storage Size	 : 	tidb 集群目前已用数据库空间大小
+    - 	Store Status  -- up store	 : 	tikv 正常节点数量
+    - 	Store Status  -- down store	 : 	tikv 异常节点数量
+
+        如果大于0，证明有节点不正常
+    - 	Store Status  -- offline store	 : 	手动执行下线操作tikv节点数量
+    - 	Store Status  -- Tombstone store	 : 	下线成功的tikv节点数量
+    - 	Current storage usage	 : 	tikv 集群存储空间占用率
+
+        超过 80% 应考虑添加 tikv 节点
+    - 	99% completed_cmds_duration_seconds	 : 	99% pd-server 请求完成时间
+
+        小于 5ms
+    - 	average completed_cmds_duration_seconds	 : 	pd-server 请求平均完成时间
+
+        小于 50ms
+    - 	leader balance ratio	 : 	leader ratio 最大的节点与最小的节点的差
+
+        均衡状况下一般小于 5%，节点重启时会比较大
+    - 	region balance ratio	 : 	region ratio 最大的节点与最小的节点的差
+
+        均衡状况下一般小于 5%，新增/下线节点时会比较大
+
+-   TiDB
+    - 	handle_requests_duration_seconds	 : 	请求PD获取TSO响应时间
+
+        小于100ms
+    - 	tidb server QPS	 : 	集群的请求量
+
+        和业务相关
+    - 	connection count	 : 	从业务服务器连接到数据库的连接数
+
+        和业务相关。但是如果连接数发生跳变，需要查明原因。比如突然掉为0，可以检查网络是否中断；如果突然上涨，需要检查业务。
+    - 	statement count	 : 	单位时间内不同类型语句执行的数目
+
+        这个和业务相关
+    - 	Query Duration 99th percentile	 : 	99% 的query时间
+
+-   TiKV
+    - 	99%  & 99.99%  scheduler command duration	 : 	99% & 99.99% 命令执行的时间
+
+        99% 小于 50ms；99.99% 小于100ms
+    - 	95%  & 99% storage async_request duration	 : 	95%  & 99% Raft 命令执行时间
+
+        95% 小于 50ms；99% 小于100ms
+    - 	server report failure message	 : 	发送失败或者收到了错误的 message
+
+        如果出现了大量的 unreachadble 的消息，表明系统网络出现了问题。如果有 store not match 这样的错误，表明收到了不属于这个集群发过来的消息
+    - 	Vote	 : 	Raft vote 的频率
+
+        通常这个值只会在发生 split 的时候有变动，如果长时间出现了 vote 偏高的情况，证明系统出现了严重的问题，有一些节点无法工作了
+    - 	95% & 99% coprocessor request duration	 : 	95% & 99%  coprocessor 执行时间
+
+        和业务相关，但通常不会出现持续高位的值
+    - 	Pending task	 : 	累积的任务数量
+
+        除了 pd worker，其他任何偏高都属于异常
+    - 	stall	 : 	RocksDB Stall 时间
+
+        大于 0，表明 RocksDB 忙不过来，需要注意 IO 和 CPU 了
+    - 	channel full	 : 	channel 满了，表明线程太忙无法处理
+
+        如果大于 0，表明线程已经没法处理了
+    - 	95% send_message_duration_seconds	 : 	95% 发送消息的时间
+
+        小于50ms
+    - 	leader/region	 : 	每个tikv的leader/region数量
 
+        和业务相关
 
 ## 图例
 

op-guide/horizontal-scale.md

@@ -95,6 +95,7 @@ TiDB 集群可以在不影响线上服务的情况下动态进行扩容和缩容
 ```
 
 我们可以通过这个 store 的 state 来确定这个 store 的状态：
+
 - `state=0`: 这个 store 正常服务
 - `state=1`: 这个 store 正在下线，此时 store 仍在服务中
 - `state=2`: 这个 store 已经完成下线，此时 store 上已经没有数据，可以关闭实例

op-guide/json-functions-generated-column.md

@@ -5,36 +5,48 @@ category: compatibility
 
 # JSON 函数及 Generated Column
 
-### 概述
+## 概述
+
 为了在功能上与最新版的MySQL（版本 5.7 及以上）保持同步，同时更好地支持文档存储类业务，我们在最新版本的 TiDB 中加入了 JSON 的支持。用户可以在 TiDB 的表中使用 JSON 类型的字段，同时以生成列（generated column）的方式为 JSON 文档内部的字段建立索引。基于此，用户可以很灵活地处理那些 schema 不确定地业务，同时不必受限于传统文档数据库糟糕的读性能及匮乏的事务支持。
 
-### JSON功能介绍
+## JSON功能介绍
+
 TiDB的 JSON 主要参考了 MySQL 5.7 的用户接口。例如，可以创建一个表，包含一个JSON字段来存储那些复杂的信息：
+
 ```sql
 CREATE TABLE person （
     id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
     name VARCHAR(255) NOT NULL,
     address_info JSON
 ）
 ```
+
 当我们向表中插入数据时，便可以这样处理那些模式不确定的数据了：
+
 ```sql
 INSERT INTO person (name, address_info) VALUES ("John", '{"city": "Beijing"}');
 ```
+
 就这么简单！直接在 JSON 字段对应的位置上，放一个合法的 JSON 字符串，就可以向表中插入 JSON 了。TiDB 会解析这个文本，然后以一种更加紧凑、易于访问的二进制形式来保存。
 
 当然，你也可以将其他类型的数据用 CAST 转换为 JSON：
+
 ```sql
 INSERT INTO person (name, address_info) VALUES ("John", CAST('{"city": "Beijing"}' AS JSON));
 INSERT INTO person (name, address_info) VALUES ("John", CAST('123' AS JSON));
 INSERT INTO person (name, address_info) VALUES ("John", CAST(123 AS JSON));
 ```
 
 现在，我们想查询表中所有居住在北京的用户，该怎么做呢？需要把数据全拉回来，然后在业务层进行过滤吗？不需要，和 MongoDB 等老牌文档数据库相同，我们有在服务端支持用户各种复杂组合查询条件的能力。你可以这样写SQL：
+
 ```sql
 SELECT id, name FROM person WHERE JSON_EXTRACT(address_info, '$.city') = 'Beijing');
 ```
-**JSON_EXTRACT** 是TiDB支持的一个函数，熟悉 MySQL 5.7 的 JSON 功能的朋友应当很熟悉，它们的用法完全相同。这个函数的意思就是，从 *address_info* 这个文档中取出名为city这个字段。它的第二个参数是一个“路径表达式”， 我们由此可以指定到底要取出哪个字段。关于路径表达式的完整语法描述比较复杂，我们还是看几个简单的例子来了解它大致的使用吧：
+
+`JSON_EXTRACT` 是TiDB支持的一个函数，熟悉 MySQL 5.7 的 JSON 功能的朋友应当很熟悉，它们的用法完全相同。
+这个函数的意思就是，从 `address_info` 这个文档中取出名为city这个字段。它的第二个参数是一个“路径表达式”，
+我们由此可以指定到底要取出哪个字段。关于路径表达式的完整语法描述比较复杂，我们还是看几个简单的例子来了解它大致的使用吧：
+
 ```sql
 SET @person = '{"name":"John","friends":[{"name":"Forest","age":16},{"name":"Zhang San","gender":"male"}]}';
 
@@ -45,6 +57,7 @@ SELECT JSON_EXTRACT(@person,  '$.friends[2].name'); -- gets NULL
 ```
 
 除了插入、查询外，对 JSON 的修改也是支持的。总的来说，目前我们支持的 MySQL 5.7 的 JSON 函数如下表所示：
+
 * [JSON_EXTRACT](https://dev.mysql.com/doc/refman/5.7/en/json-search-functions.html#function_json-extract)
 * [JSON_ARRAY](https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-array)
 * [JSON_OBJECT](https://dev.mysql.com/doc/refman/5.7/en/json-creation-functions.html#function_json-object)
@@ -59,10 +72,12 @@ SELECT JSON_EXTRACT(@person,  '$.friends[2].name'); -- gets NULL
 
 熟悉 MySQL 5.7 的用户会发现，TiDB 尚未完全支持所有 MySQL 5.7 中的 JSON 函数。这是因为我们在实现的时候，一期目标是能够提供完备的 **MySQL X Plugin** 支持即可，而这已经涵盖大部分常用的JSON增删改查的功能了。更多的函数功能，只要社区有需求，我们会继续全力支持的。
 
-### 使用生成列对JSON建索引
-在有了上述的知识铺垫后，数据库的老司机们一定会发现，我们在查询 JSON 中的一个字段时，走的是全表扫描啊，不开心！的确，使用 TiDB 的 **EXPLAIN** 语句时，一个比 MySQL 完备得多的结果会告诉我们，确实是全表扫描了。那么，我们能否对 JSON 字段进行索引呢？
+## 使用生成列对JSON建索引
+
+在有了上述的知识铺垫后，数据库的老司机们一定会发现，我们在查询 JSON 中的一个字段时，走的是全表扫描啊，不开心！的确，使用 TiDB 的 ``EXPLAIN`` 语句时，一个比 MySQL 完备得多的结果会告诉我们，确实是全表扫描了。那么，我们能否对 JSON 字段进行索引呢？
 
 首先，这种索引姿势是错误的：
+
 ```sql
 CREATE TABLE person （
     id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
@@ -71,7 +86,9 @@ CREATE TABLE person （
     KEY (address_info)
 ）
 ```
+
 这并非是因为技术上无法支持，而是因为对 JSON 的直接比较，本身就是没有意义的——尽管我们可以人为地约定一些比较规则，比如 ARRAY 比所有的 OBJECT 都大——但是这并没有什么用处。因此，正如 MySQL 5.7 所做的那样，我们禁止了直接在 JSON 字段上创建索引，而是通过生成列的方式，支持了对 JSON 文档内的某一字段建立索引：
+
 ```sql
 CREATE TABLE person （
     id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
@@ -81,16 +98,21 @@ CREATE TABLE person （
     KEY (city)
 ）
 ```
-这个表中，`city` 列就是一个 **生成列**。顾名思义，该列由表中其他的列生成，而不能显式地在插入或更新时为它赋一个值。对于生成列，用户还可以指定其为 *VIRTUAL* 来避免它被显式地保存在记录中，而是在需要地时候再由其他列来生成，这对于列比较宽且需要节约存储空间地情况尤为有用。有了这个生成列，我们就可以在它上面建立索引了，在用户看来与常规的列便没什么两样，是不是很简单呢？而查询的时候，我们可以：
+
+这个表中，`city` 列就是一个 **生成列**。顾名思义，该列由表中其他的列生成，而不能显式地在插入或更新时为它赋一个值。对于生成列，用户还可以指定其为 ``VIRTUAL`` 来避免它被显式地保存在记录中，而是在需要地时候再由其他列来生成，这对于列比较宽且需要节约存储空间地情况尤为有用。有了这个生成列，我们就可以在它上面建立索引了，在用户看来与常规的列便没什么两样，是不是很简单呢？而查询的时候，我们可以：
+
 ```sql
 SELECT name, id FROM person WHERE city = 'Beijing'
 ```
+
 这样，便可以走索引了！
 
 另外，需要注意的是，如果 JSON 文档中指定路径下的字段不存在，那么 JSON_EXTRACT 的结果会是 NULL ，这时，带有索引的生成列的值也就为 NULL 了。因此，如果这是用户不希望看到的，那也可以在生成列上增加 NOT NULL 约束，这样，当插入新的纪录算出来的 city 字段为 NULL 时，便可以检查出来了。
 
-### 目前的一些限制
+## 目前的一些限制
+
 目前 JSON 及生成列仍然有一些限制：
+
 * 不能 ALTER TABLE 增加 STORED 存储方式的生成列；
 * 不能 ALTER TABLE 在生成列上增加索引；
 

op-guide/location-awareness.md

@@ -25,7 +25,7 @@ tikv-server --labels zone=<zone>,rack=<rack>,host=<host>
 
 配置文件：
 
-``` toml
+```toml
 [server]
 labels = "zone=<zone>,rack=<rack>,host=<host>"
 ```
@@ -34,7 +34,7 @@ labels = "zone=<zone>,rack=<rack>,host=<host>"
 
 可以通过 PD 的配置文件让 PD 理解 TiKV 集群的拓扑结构。
 
-``` toml
+```toml
 [replication]
 max-replicas = 3
 location-labels = ["zone", "rack", "host"]
@@ -82,7 +82,7 @@ tikv-server --labels zone=z4,rack=r2,host=h2
 
 在这种拓扑结构下，PD 会优先把每一份数据的不同副本调度到不同的数据中心。
 这时候如果其中一个数据中心挂了，不会影响正常服务。
-如果这个数据中心一段时间内恢复不了，PD 会把这个数据中心的副本迁出去。
+如果这个数据中心一段时间内恢复不了，PD 会把这个数据中心的副本迁移出去。
 
 总的来说，PD 能够根据当前的拓扑结构使得集群容灾能力最大化，所以如果我们希望达到某个级别的容灾能力，
 就需要根据拓扑机构在不同的地理位置提供多于备份数 (`max-replicas`) 的机器。

op-guide/migration.md

@@ -103,7 +103,7 @@ cd tidb-enterprise-tools-latest-linux-amd64
 
 ```sql
 CREATE TABLE t_error ( a INT NOT NULL, PRIMARY KEY (a))
-ENGINE=InnoDB TABLESPACE ts1                          
+ENGINE=InnoDB TABLESPACE ts1
 PARTITION BY RANGE (a) PARTITIONS 3 (
 PARTITION P1 VALUES LESS THAN (2),
 PARTITION P2 VALUES LESS THAN (4) TABLESPACE ts2,
@@ -147,17 +147,18 @@ github.com/pingcap/tidb/parser/yy_parser.go:109:
 ### `mydumper`/`loader` 全量导入数据最佳实践
 为了快速的迁移数据 (特别是数据量巨大的库), 可以参考下面建议
 
-* 使用 mydumper 导出来的数据文件尽可能的小, 最好不要超过 64M, 可以设置参数 -F 64 
+* 使用 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
-     - TIDB * 4 
-     - PD * 3
- - mydumper -F 设置为 16, loader -t 参数 64
-
+
+- mydumper 导出后总数据量 214G，单表 8 列，20 亿行数据
+- 集群拓扑
+    - TIKV * 12
+    - TIDB * 4
+    - PD * 3
+- mydumper -F 设置为 16, loader -t 参数 64
+
 结果：导入时间 11 小时左右，19.4 G/小时
 
 ### 从 MySQL 导出数据