tools/binlog: fix and update format

tools/binlog/binlog-slave-client.md

@@ -7,7 +7,7 @@ category: tools
 
 目前 Drainer 提供了多种输出方式，包括 MySQL、TiDB、file 等。但是用户往往有一些自定义的需求，比如输出到 Elasticsearch、Hive 等，这些需求 Drainer 现在还没有实现，因此 Drainer 增加了输出到 Kafka 的功能，将 binlog 数据解析后按一定的格式再输出到 Kafka 中，用户编写代码从 Kafka 中读出数据再进行处理。
 
-## 配置 Kafka Drainer 
+## 配置 Kafka Drainer
 
 修改 Drainer 的配置文件，设置输出为 Kafka，相关配置如下：
 

tools/binlog/deploy.md

@@ -3,7 +3,6 @@ title: TiDB-Binlog 集群部署
 category: tools
 ---
 
-
 # TiDB-Binlog 集群部署
 
 ## 使用 TiDB-Ansible 部署 TiDB-Binlog
@@ -124,9 +123,8 @@ category: tools
     INFO[0000] pump: {NodeID: ip-172-16-10-73:8250, Addr: 172.16.10.73:8250, State: online, MaxCommitTS: 403051525703991299, UpdateTime: 2018-12-25 14:23:36 +0800 CST}
     INFO[0000] pump: {NodeID: ip-172-16-10-74:8250, Addr: 172.16.10.74:8250, State: online, MaxCommitTS: 403051525717360643, UpdateTime: 2018-12-25 14:23:35 +0800 CST}
     ```
-### 第 3 步：部署 Drainer
-<a href="#第 3 步：部署 Drainer"></a>
 
+### 第 3 步：部署 Drainer
 
 1. 获取 initial_commit_ts
 
@@ -247,7 +245,9 @@ wget https://download.pingcap.org/tidb-binlog-latest-linux-amd64.sha256
 # 检查文件完整性，返回 ok 则正确
 sha256sum -c tidb-binlog-latest-linux-amd64.sha256
 ```
+
 ### 使用样例
+
 假设有三个 PD，一个 TiDB，另外有两台机器用于部署 Pump，一台机器用于部署 Drainer。各个节点信息如下：
 
 ```
@@ -482,8 +482,9 @@ Drainer="192.168.0.13"
 
         如果命令行参数与配置文件中的参数重合，则使用命令行设置的参数的值。
 
-## 注意
-* 在运行 TiDB 时，需要保证至少一个 Pump 正常运行。
-* 通过给 TiDB 增加启动参数 `enable-binlog` 来开启 binlog 服务。尽量保证同一集群的所有 TiDB 都开启了 binlog 服务，否则在同步数据时可能会导致上下游数据不一致。如果要临时运行一个不开启 binlog 服务的 TiDB 实例，需要在 TiDB 的配置文件中设置 `run_ddl= false`。
-* Drainer 不支持对 ignore schemas（在过滤列表中的 schemas）的 table 进行 rename DDL 操作。
-* 在已有的 TiDB 集群中启动 Drainer，一般需要全量备份并且获取 savepoint，然后导入全量备份，最后启动 Drainer 从 savepoint 开始同步增量数据。
+> **注意：**
+>
+> - 在运行 TiDB 时，需要保证至少一个 Pump 正常运行。
+> - 通过给 TiDB 增加启动参数 `enable-binlog` 来开启 binlog 服务。尽量保证同一集群的所有 TiDB 都开启了 binlog 服务，否则在同步数据时可能会导致上下游数据不一致。如果要临时运行一个不开启 binlog 服务的 TiDB 实例，需要在 TiDB 的配置文件中设置 `run_ddl= false`。
+> - Drainer 不支持对 ignore schemas（在过滤列表中的 schemas）的 table 进行 rename DDL 操作。
+> - 在已有的 TiDB 集群中启动 Drainer，一般需要全量备份并且获取 savepoint，然后导入全量备份，最后启动 Drainer 从 savepoint 开始同步增量数据。

tools/binlog/monitor.md

@@ -22,7 +22,6 @@ category: tools
 | Pump Storage Error By Type | Pump 遇到的 error 数量，按照 error 的类型进行统计 |
 | Query TiKV | Pump 通过 TiKV 查询事务状态的次数 |
 
-
 ### Drainer
 
 | metric 名称 | 说明 |
@@ -36,8 +35,6 @@ category: tools
 | 95% Binlog Size | Drainer 从各个 Pump 获取到 binlog 数据的大小 |
 | DL Job Count | Drainer 处理的 DDL 的数量|
 
-
-
 ## 监控告警规则
 
 ### Emergency
@@ -59,12 +56,12 @@ category: tools
     - 判断从 Pump 获取数据是否太慢：
 
         监控 Pump handle tso 可以看每个 Pump 最近一条消息的时间，是不是有延迟特别大的 Pump，确认对应 Pump 正常运行
-        
+
     - 根据 Drainer event 和 Drainer execute latency 来判断是否下游同步太慢：
-        
+
         - 如果 Drainer execute time 过大，则检查到目标库网络带宽和延迟，以及目标库状态
         - 如果 Drainer execute time 不大，Drainer event 过小，则增加 work count 和 batch 进行重试
-            
+
     - 上面都不满足或者操作后没有改观，则报备开发 [email protected] 进行处理
 
 ### Warning

tools/binlog/operation.md

@@ -26,6 +26,7 @@ Pump/Drainer 中状态的定义：
 关于 Pump/Drainer 暂停、下线、状态查询、状态修改等具体的操作方法，参考如下 binlogctl 工具的使用方法介绍。
 
 ## binlogctl 工具
+
 * 获取 TiDB 集群当前的 TSO
 * 查看 Pump/Drainer 状态
 * 修改 Pump/Drainer 状态
@@ -83,6 +84,7 @@ Usage of binlogctl:
 -time-zone string
     如果设置时区，在 "generate_meta" 模式下会打印出获取到的 tso 对应的时间。例如"Asia/Shanghai" 为 CST 时区，"Local" 为本地时区
 ```
+
 命令示例：
 
 - 查询所有的 Pump/Drainer 的状态：
@@ -104,7 +106,7 @@ Usage of binlogctl:
     ```
 
     这条命令会修改 Pump/Drainer 保存在 PD 中的状态。
- 
+
 - 暂停/下线 Pump/Drainer
 
     分别设置 `cmd` 为 `pause-pump`、`pause-drainer`、`offline-pump`、`offline-drainer` 来暂停 Pump、暂停 Drainer、下线 Pump、下线 Drainer。例如：
@@ -127,5 +129,3 @@ Usage of binlogctl:
     ```
 
     该命令会生成一个文件 `{data-dir}/savepoint`，该文件中保存了 Drainer 初次启动需要的 tso 信息。
-
-

tools/binlog/overview.md

@@ -10,10 +10,10 @@ TiDB-Binlog 是一个用于收集 TiDB 的 Binlog，并提供实时备份和同
 
 TiDB-Binlog 支持以下功能场景：
 
-* **数据同步**：同步 TiDB 集群数据到其他数据库
-* **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复
+- **数据同步**：同步 TiDB 集群数据到其他数据库
+- **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复
 
-## TiDB-Binlog 的整体架构
+## TiDB-Binlog 整体架构
 
 ![TiDB-Binlog 架构](/media/tidb_binlog_cluster_architecture.png)
 
@@ -36,7 +36,6 @@ Drainer 从各个 Pump 中收集 Binlog 进行归并，再将 Binlog 转化成 S
 * 修改 Pump/Drainer 状态
 * 暂停/下线 Pump/Drainer
 
-
 ## 主要特性
 
 * 多个 Pump 形成一个集群，可以水平扩容。
@@ -53,10 +52,9 @@ Pump 和 Drainer 都支持部署和运行在 Intel x86-64 架构的 64 位通用
 | Pump | 3 | 8核+   | SSD, 200 GB+ | 16G |
 | Drainer | 1 | 8核+ | SAS, 100 GB+ （如果输出为本地文件，则使用 SSD，并增加磁盘大小） | 16G |
 
-## 注意
+## 注意事项
 
 * 需要使用 TiDB v2.0.8-binlog、v2.1.0-rc.5 及以上版本，否则不兼容该版本的 TiDB-Binlog。
 * Drainer 支持将 Binlog 同步到 MySQL、TiDB、Kafka 或者本地文件。如果需要将 Binlog 同步到其他 Drainer 不支持的类型的系统中，可以设置 Drainer 将 Binlog 同步到 Kafka，然后根据 binlog slave protocol 进行定制处理，参考 [binlog slave client 用户文档](/tools/binlog/binlog-slave-client.md)。
 * 如果 TiDB-Binlog 用于增量恢复，可以设置配置项 `db-type="file"`，Drainer 会将 binlog 转化为指定的 [proto buffer 格式](https://github.com/pingcap/tidb-binlog/blob/master/proto/binlog.proto)的数据，再写入到本地文件中。这样就可以使用 [Reparo](/tools/binlog/reparo.md) 恢复增量数据。
 * 如果下游为 MySQL/TiDB，数据同步后可以使用 [sync-diff-inspector](/tools/sync-diff-inspector.md) 进行数据校验。
-

tools/binlog/reparo.md

@@ -9,7 +9,6 @@ Reparo 是 TiDB-Binlog 的一个配套工具，用于增量的恢复。使用 Ti
 
 下载链接：[tidb-binlog-cluster-latest-linux-amd64.tar.gz](http://download.pingcap.org/tidb-binlog-cluster-latest-linux-amd64.tar.gz)
 
-
 ## Reparo 使用
 
 ### 命令行参数说明
@@ -84,11 +83,11 @@ password = ""
 ./bin/reparo -config reparo.toml
 ```
 
-### 注意
-
-* data-dir 用于指定 Drainer 输出的 binlog 文件目录。
-* start-datatime 和 start-tso 效果一样，只是时间格式上的区别，用于指定开始恢复的时间点；如果不指定，则默认在第一个 binlog 文件开始恢复。
-* stop-datetime 和 stop-tso 效果一样，只是时间格式上的区别，用于指定结束恢复的时间点；如果不指定，则恢复到最后一个 binlog 文件的结尾。
-* dest-type 指定目标类型，取值为 ｀mysql｀, ｀print｀。 当值为 ｀mysql｀ 时，可以恢复到 MySQL/TiDB 等使用或兼容 MySQL 协议的数据库，需要在配置下面的 [dest-db] 填写数据库信息；当取值为 ｀print｀ 的时候，只是打印 binlog 信息，通常用于 debug，以及查看 binlog 的内容，此时不需要填写 [dest-db] 。
-* replicate-do-db 用于指定恢复的库，不指定的话，则全部都恢复。
-* replicate-do-table 用于指定要恢复的表，不指定的话，则全部都恢复。
+> **注意：**
+>
+> - data-dir 用于指定 Drainer 输出的 binlog 文件目录。
+> - start-datatime 和 start-tso 效果一样，只是时间格式上的区别，用于指定开始恢复的时间点；如果不指定，则默认在第一个 binlog 文件开始恢复。
+> - stop-datetime 和 stop-tso 效果一样，只是时间格式上的区别，用于指定结束恢复的时间点；如果不指定，则恢复到最后一个 binlog 文件的结尾。
+> - dest-type 指定目标类型，取值为 `mysql`、`print`。 当值为 `mysql` 时，可以恢复到 MySQL/TiDB 等使用或兼容 MySQL 协议的数据库，需要在配置下面的 [dest-db] 填写数据库信息；当取值为 `print` 的时候，只是打印 binlog 信息，通常用于 debug，以及查看 binlog 的内容，此时不需要填写 `[dest-db]`。
+> - replicate-do-db 用于指定恢复的库，不指定的话，则全部都恢复。
+> - replicate-do-table 用于指定要恢复的表，不指定的话，则全部都恢复。

tools/binlog/tidb-binlog-kafka.md

@@ -9,12 +9,12 @@ category: tools
 
 ## TiDB-Binlog 简介
 
-TiDB-Binlog 是一个用于收集 TiDB 的 Binlog 并提供实时备份和同步功能的商业工具。
+TiDB-Binlog 是用于收集 TiDB 的 Binlog，并提供实时备份和同步功能的商业工具。
 
 TiDB-Binlog 支持以下功能场景:
 
-* **数据同步**：同步 TiDB 集群数据到其他数据库
-* **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复
+- **数据同步**：同步 TiDB 集群数据到其他数据库
+- **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复
 
 ## TiDB-Binlog Kafka 架构
 
@@ -36,16 +36,17 @@ Drainer 从 Kafka 中收集 Binlog，并按照 TiDB 中事务的提交顺序转
 
 Kafka 集群用来存储由 Pump 写入的 Binlog 数据，并提供给 Drainer 进行读取。
 
-> **注**：local 版本将 Binlog 存储在文件中，Kafka 版本则使用 Kafka 存储。
+> **注意：**
+>
+> Local 版本将 Binlog 存储在文件中，Kafka 版本则使用 Kafka 存储。
 
 ## TiDB-Binlog 安装
 
 以下为 TiDB-Ansible 分支与 TiDB 版本的对应关系，版本选择可咨询官方 [email protected]。
 
-| TiDB-Ansible 分支 | TiDB 版本 | 备注 | 
+| TiDB-Ansible 分支 | TiDB 版本 | 备注 |
 |:----|:----|:----|
 | release-2.0 | 2.0 版本 | 最新 2.0 稳定版本，可用于生产环境。 |
-
 
 ### 下载官方 Binary
 
@@ -66,7 +67,7 @@ cd tidb-binlog-kafka-linux-amd64
 
 ### TiDB-Binlog 部署
 
-#### 注意
+#### 注意事项
 
 * 需要为一个 TiDB 集群中的每台 TiDB server 部署一个 Pump，目前 TiDB server 只支持以 unix socket 的方式输出 Binlog。
 
@@ -414,7 +415,7 @@ PbReader 使用示例
 + 进入 Grafana Web 界面（默认地址: `http://localhost:3000`，默认账号：admin，密码：admin）
 
     点击 Grafana Logo -> 点击 Data Sources -> 点击 Add data source -> 填写 data source 信息
-    
+
     > **注意：**
     >
     > Type 选 Prometheus，URL 为 Prometheus 地址，根据实际情况添加/填写。

tools/binlog/upgrade.md

@@ -3,12 +3,12 @@ title: TiDB-Binlog Cluster 版本升级方法
 category: tools
 ---
 
-# TiDB-Binlog Cluster 版本升级方法
+# TiDB-Binlog Cluster 版本升级方法s
 
 新版本的 TiDB（v2.0.8-binlog、v2.1.0-rc.5 及以上版本）不兼容 [Kafka 版本](/tools/binlog/tidb-binlog-kafka.md)以及 [Local 版本](/tools/binlog/tidb-binlog-local.md)的 TiDB-Binlog，集群升级到新版本后只能使用 Cluster 版本的 TiDB-Binlog。如果在升级前已经使用了 Kafka／Local 版本的 TiDB-Binlog，必须将其升级到 Cluster 版本。
- 
- TiDB-Binlog 版本与 TiDB 版本的对应关系如下：
- 
+
+TiDB-Binlog 版本与 TiDB 版本的对应关系如下：
+
 | TiDB-Binlog 版本 | TiDB 版本 | 说明 |
 |---|---|---|
 | Local | TiDB 1.0 及更低版本 ||
@@ -22,21 +22,21 @@ category: tools
 > 如果能接受重新导全量数据，则可以直接废弃老版本，按 [TiDB-Binlog 集群部署](/tools/binlog/deploy.md)中的步骤重新部署。
 
 如果想从原来的 checkpoint 继续同步，使用以下升级流程：
-    1. 部署新版本 Pump。
-    2. 暂停 TiDB 集群业务。
-    3. 更新 TiDB 以及配置，写 Binlog 到新的 Pump Cluster。
-    4. TiDB 集群重新接入业务。
-    5. 确认老版本的 Drainer 已经将老版本的 Pump 的数据完全同步到下游。
 
-        查询 Drainer 的 `status` 接口，示例命令如下：
+1. 部署新版本 Pump。
+2. 暂停 TiDB 集群业务。
+3. 更新 TiDB 以及配置，写 Binlog 到新的 Pump Cluster。
+4. TiDB 集群重新接入业务。
+5. 确认老版本的 Drainer 已经将老版本的 Pump 的数据完全同步到下游。
 
-        ```bash
-        $ curl 'http://172.16.10.49:8249/status'
-        {"PumpPos":{"172.16.10.49:8250":{"offset":32686}},"Synced": true ,"DepositWindow":{"Upper":398907800202772481,"Lower":398907799455662081}}
-        ```
+    查询 Drainer 的 `status` 接口，示例命令如下：
 
-        如果返回的 `Synced` 为 true，则可以认为 Binlog 数据已经全部同步到了下游。
-    6. 启动新版本 Drainer；
-    7. 下线老版本的 Pump、Drainer 以及依赖的 Kafka 和 ZookeSeper。
+    ```bash
+    $ curl 'http://172.16.10.49:8249/status'
+    {"PumpPos":{"172.16.10.49:8250":{"offset":32686}},"Synced": true ,"DepositWindow":{"Upper":398907800202772481,"Lower":398907799455662081}}
+    ```
 
+    如果返回的 `Synced` 为 true，则可以认为 Binlog 数据已经全部同步到了下游。
 
+6. 启动新版本 Drainer；
+7. 下线老版本的 Pump、Drainer 以及依赖的 Kafka 和 ZookeSeper。