diff --git a/tools/binlog/binlog-slave-client.md b/tools/binlog/binlog-slave-client.md index 5daf144f17c2..5c06c0defe92 100644 --- a/tools/binlog/binlog-slave-client.md +++ b/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，相关配置如下： diff --git a/tools/binlog/deploy.md b/tools/binlog/deploy.md index 1bd4855cf4aa..5e9387da9396 100644 --- a/tools/binlog/deploy.md +++ b/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 - +### 第 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 开始同步增量数据。 diff --git a/tools/binlog/monitor.md b/tools/binlog/monitor.md index 3422af97b189..e019a64aced9 100644 --- a/tools/binlog/monitor.md +++ b/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 进行重试 - + - 上面都不满足或者操作后没有改观，则报备开发 support@pingcap.com 进行处理 ### Warning diff --git a/tools/binlog/operation.md b/tools/binlog/operation.md index cfa396c60a17..6d7eb7b0053c 100644 --- a/tools/binlog/operation.md +++ b/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 信息。 - - diff --git a/tools/binlog/overview.md b/tools/binlog/overview.md index 8ecf1960c337..c874c2593ac9 100644 --- a/tools/binlog/overview.md +++ b/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) 进行数据校验。 - diff --git a/tools/binlog/reparo.md b/tools/binlog/reparo.md index b4ba6a8b7052..f842cc3a2a42 100644 --- a/tools/binlog/reparo.md +++ b/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 用于指定要恢复的表，不指定的话，则全部都恢复。 \ No newline at end of file +> **注意：** +> +> - 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 用于指定要恢复的表，不指定的话，则全部都恢复。 \ No newline at end of file diff --git a/tools/binlog/tidb-binlog-kafka.md b/tools/binlog/tidb-binlog-kafka.md index 6530d6aa9ba7..d0f1024680ab 100644 --- a/tools/binlog/tidb-binlog-kafka.md +++ b/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 版本的对应关系，版本选择可咨询官方 info@pingcap.com。 -| 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 地址，根据实际情况添加/填写。 diff --git a/tools/binlog/tidb-binlog-local.md b/tools/binlog/tidb-binlog-local.md index 0aa2b0abcdb4..a3686f56a189 100644 --- a/tools/binlog/tidb-binlog-local.md +++ b/tools/binlog/tidb-binlog-local.md @@ -30,7 +30,7 @@ TiDB-Binlog 集群主要分为两个组件： ### TiDB-Binlog-local 下载 -TiDB-Binlog 包含在 tidb-enterprise-tools 安装包中，可[在此下载](../../tools/download.md)。 +TiDB-Binlog 包含在 tidb-enterprise-tools 安装包中，可[在此下载](/tools/download.md)。 ### TiDB-Binlog-local 部署 diff --git a/tools/binlog/upgrade.md b/tools/binlog/upgrade.md index 917a8cc4a7cd..683071ea578c 100644 --- a/tools/binlog/upgrade.md +++ b/tools/binlog/upgrade.md @@ -6,9 +6,9 @@ category: tools # TiDB-Binlog Cluster 版本升级方法 新版本的 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。