diff --git a/TOC.md b/TOC.md
index 167997f1407b..7d54cc261d94 100644
--- a/TOC.md
+++ b/TOC.md
@@ -114,7 +114,6 @@
- [PD 微服务部署拓扑](/pd-microservices-deployment-topology.md)
- [TiProxy 部署拓扑](/tiproxy/tiproxy-deployment-topology.md)
- [TiCDC 部署拓扑](/ticdc-deployment-topology.md)
- - [TiDB Binlog 部署拓扑](/tidb-binlog-deployment-topology.md)
- [TiSpark 部署拓扑](/tispark-deployment-topology.md)
- [跨机房部署拓扑结构](/geo-distributed-deployment-topology.md)
- [混合部署拓扑结构](/hybrid-deployment-topology.md)
@@ -607,26 +606,6 @@
- [故障处理](/ticdc/troubleshoot-ticdc.md)
- [常见问题解答](/ticdc/ticdc-faq.md)
- [术语表](/ticdc/ticdc-glossary.md)
- - TiDB Binlog（已废弃）
- - [概述](/tidb-binlog/tidb-binlog-overview.md)
- - [快速上手](/tidb-binlog/get-started-with-tidb-binlog.md)
- - [部署使用](/tidb-binlog/deploy-tidb-binlog.md)
- - [运维管理](/tidb-binlog/maintain-tidb-binlog-cluster.md)
- - [配置说明](/tidb-binlog/tidb-binlog-configuration-file.md)
- - [Pump](/tidb-binlog/tidb-binlog-configuration-file.md#pump)
- - [Drainer](/tidb-binlog/tidb-binlog-configuration-file.md#drainer)
- - [版本升级](/tidb-binlog/upgrade-tidb-binlog.md)
- - [监控告警](/tidb-binlog/monitor-tidb-binlog-cluster.md)
- - [增量恢复](/tidb-binlog/tidb-binlog-reparo.md)
- - [binlogctl 工具](/tidb-binlog/binlog-control.md)
- - [Kafka 自定义开发](/tidb-binlog/binlog-consumer-client.md)
- - [TiDB Binlog Relay Log](/tidb-binlog/tidb-binlog-relay-log.md)
- - [集群间双向同步](/tidb-binlog/bidirectional-replication-between-tidb-clusters.md)
- - [术语表](/tidb-binlog/tidb-binlog-glossary.md)
- - 故障诊断
- - [故障诊断](/tidb-binlog/troubleshoot-tidb-binlog.md)
- - [常见错误修复](/tidb-binlog/handle-tidb-binlog-errors.md)
- - [FAQ](/tidb-binlog/tidb-binlog-faq.md)
- PingCAP Clinic 诊断服务
- [概述](/clinic/clinic-introduction.md)
- [快速上手](/clinic/quick-start-with-clinic.md)
@@ -693,7 +672,6 @@
- [pd-ctl](/pd-control.md)
- [tidb-ctl](/tidb-control.md)
- [pd-recover](/pd-recover.md)
- - [binlog-ctl](/tidb-binlog/binlog-control.md)
- 命令行参数
- [tidb-server](/command-line-flags-for-tidb-configuration.md)
- [tikv-server](/command-line-flags-for-tikv-configuration.md)
@@ -772,8 +750,6 @@
- [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md)
- [`CANCEL IMPORT JOB`](/sql-statements/sql-statement-cancel-import-job.md)
- [`COMMIT`](/sql-statements/sql-statement-commit.md)
- - [`CHANGE DRAINER`](/sql-statements/sql-statement-change-drainer.md)
- - [`CHANGE PUMP`](/sql-statements/sql-statement-change-pump.md)
- [`CREATE BINDING`](/sql-statements/sql-statement-create-binding.md)
- [`CREATE DATABASE`](/sql-statements/sql-statement-create-database.md)
- [`CREATE INDEX`](/sql-statements/sql-statement-create-index.md)
@@ -853,7 +829,6 @@
- [`SHOW CREATE DATABASE`](/sql-statements/sql-statement-show-create-database.md)
- [`SHOW CREATE USER`](/sql-statements/sql-statement-show-create-user.md)
- [`SHOW DATABASES`](/sql-statements/sql-statement-show-databases.md)
- - [`SHOW DRAINER STATUS`](/sql-statements/sql-statement-show-drainer-status.md)
- [`SHOW ENGINES`](/sql-statements/sql-statement-show-engines.md)
- [`SHOW ERRORS`](/sql-statements/sql-statement-show-errors.md)
- [`SHOW FIELDS FROM`](/sql-statements/sql-statement-show-fields-from.md)
@@ -868,7 +843,6 @@
- [`SHOW PRIVILEGES`](/sql-statements/sql-statement-show-privileges.md)
- [`SHOW PROCESSLIST`](/sql-statements/sql-statement-show-processlist.md)
- [`SHOW PROFILES`](/sql-statements/sql-statement-show-profiles.md)
- - [`SHOW PUMP STATUS`](/sql-statements/sql-statement-show-pump-status.md)
- [`SHOW SCHEMAS`](/sql-statements/sql-statement-show-schemas.md)
- [`SHOW STATS_BUCKETS`](/sql-statements/sql-statement-show-stats-buckets.md)
- [`SHOW STATS_HEALTHY`](/sql-statements/sql-statement-show-stats-healthy.md)
diff --git a/alert-rules.md b/alert-rules.md
index 0f58674eac63..fd2f4909c3cb 100644
--- a/alert-rules.md
+++ b/alert-rules.md
@@ -6,7 +6,7 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/']
# TiDB 集群报警规则
-本文介绍了 TiDB 集群中各组件的报警规则，包括 TiDB、TiKV、PD、TiFlash、TiDB Binlog、TiCDC、Node_exporter 和 Blackbox_exporter 的各报警项的规则描述及处理方法。
+本文介绍了 TiDB 集群中各组件的报警规则，包括 TiDB、TiKV、PD、TiFlash、TiCDC、Node_exporter 和 Blackbox_exporter 的各报警项的规则描述及处理方法。
按照严重程度由高到低，报警项可分为紧急级别 \> 严重级别 \> 警告级别三类。该分级适用于以下各组件的报警项。
@@ -121,12 +121,11 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/']
TiDB 服务中发生的事件数量。当出现以下事件的时候会报警：
1. start：TiDB 服务启动。
- 2. hang：当发生了 Critical 级别的事件时（目前只有 Binlog 写不进去一种情况），TiDB 进入 `hang` 模式，并等待人工 Kill。
+ 2. hang：当发生了 Critical 级别的事件时，TiDB 进入 `hang` 模式，并等待人工 Kill。
* 处理方法：
- * 重启 TiDB 以恢复服务。
- * 检查 TiDB Binlog 服务是否正常。
+ 重启 TiDB 以恢复服务。
#### `TiDB_tikvclient_backoff_seconds_count`
@@ -771,10 +770,6 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/']
关于 TiFlash 报警规则的详细描述，参见 [TiFlash 报警规则](/tiflash/tiflash-alert-rules.md)。
-## TiDB Binlog 报警规则
-
-关于 TiDB Binlog 报警规则的详细描述，参见 [TiDB Binlog 集群监控报警文档](/tidb-binlog/monitor-tidb-binlog-cluster.md#监控报警规则)。
-
## TiCDC 报警规则
关于 TiCDC 报警规则的详细描述，参见 [TiCDC 集群监控报警](/ticdc/ticdc-alert-rules.md)。
@@ -961,38 +956,6 @@ aliases: ['/docs-cn/dev/alert-rules/','/docs-cn/dev/reference/alert-rules/']
* 检查 TiFlash 进程是否存在。
* 检查监控机与 TiFlash 服务所在机器之间网络是否正常。
-#### `Pump_server_is_down`
-
-* 报警规则：
-
- `probe_success{group="pump"} == 0`
-
-* 规则描述：
-
- Pump 服务端口探测失败。
-
-* 处理方法：
-
- * 检查 Pump 服务所在机器是否宕机。
- * 检查 Pump 进程是否存在。
- * 检查监控机与 Pump 服务所在机器之间网络是否正常。
-
-#### `Drainer_server_is_down`
-
-* 报警规则：
-
- `probe_success{group="drainer"} == 0`
-
-* 规则描述：
-
- Drainer 服务端口探测失败。
-
-* 处理方法：
-
- * 检查 Drainer 服务所在机器是否宕机。
- * 检查 Drainer 进程是否存在。
- * 检查监控机与 Drainer 服务所在机器之间网络是否正常。
-
#### `TiKV_server_is_down`
* 报警规则：
diff --git a/basic-features.md b/basic-features.md
index 4564b6ea3f30..1c65aa30a97e 100644
--- a/basic-features.md
+++ b/basic-features.md
@@ -213,7 +213,7 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0
| [Dumpling 逻辑导出](/dumpling-overview.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
| [事务 `LOAD DATA`](/sql-statements/sql-statement-load-data.md) [^5] | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
| [数据迁移工具](/migration-overview.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
-| [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) [^6] | 已废弃 | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
+| [TiDB Binlog](https://docs.pingcap.com/zh/tidb/v8.3/tidb-binlog-overview) [^6] | 已废弃 | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
| [Change data capture (CDC)](/ticdc/ticdc-overview.md) | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y | Y |
| [TiCDC 支持保存数据到存储服务 (Amazon S3/GCS/Azure Blob Storage/NFS)](/ticdc/ticdc-sink-to-cloud-storage.md) | Y | Y | Y | Y | Y | E | N | N | N | N | N |
| [TiCDC 支持在两个 TiDB 集群之间进行双向复制](/ticdc/ticdc-bidirectional-replication.md) | Y | Y | Y | Y | Y | Y | N | N | N | N | N |
@@ -272,4 +272,4 @@ aliases: ['/docs-cn/dev/basic-features/','/docs-cn/dev/experimental-features-4.0
[^5]: 从 [TiDB v7.0.0](/releases/release-7.0.0.md) 开始新增的参数 `FIELDS DEFINED NULL BY` 以及新增支持从 S3 和 GCS 导入数据，均为实验特性。从 [TiDB v7.6.0](/releases/release-7.6.0.md) 开始 `LOAD DATA` 的事务行为与 MySQL 的事务行为一致，包括事务内的 `LOAD DATA` 语句本身不再自动提交当前事务，也不会开启新事务，并且事务内的 `LOAD DATA` 语句可以被显式提交或者回滚。此外，`LOAD DATA` 语句会受 TiDB 事务模式设置（乐观/悲观）影响。
-[^6]: 从 v7.5.0 开始，[TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) 的数据同步功能被废弃。从 v8.3.0 开始，TiDB Binlog 被完全废弃，并计划在未来版本中移除。如需进行增量数据同步，请使用 [TiCDC](/ticdc/ticdc-overview.md)。如需按时间点恢复 (point-in-time recovery, PITR)，请使用 [PITR](/br/br-pitr-guide.md)。
+[^6]: 从 v7.5.0 开始，[TiDB Binlog](https://docs.pingcap.com/zh/tidb/v8.3/tidb-binlog-overview) 的数据同步功能被废弃。从 v8.3.0 开始，TiDB Binlog 被完全废弃。从 v8.4.0 开始，TiDB Binlog 被移除。如需进行增量数据同步，请使用 [TiCDC](/ticdc/ticdc-overview.md)。如需按时间点恢复 (point-in-time recovery, PITR)，请使用 [PITR](/br/br-pitr-guide.md)。
diff --git a/binary-package.md b/binary-package.md
index 20d60e1e2736..78c02699477d 100644
--- a/binary-package.md
+++ b/binary-package.md
@@ -59,12 +59,8 @@ TiDB 提供了 amd64 和 arm64 两种架构的离线包。对于每种架构，T
| errdoc-{version}-linux-{arch}.tar.gz | |
| dba-{version}-linux-{arch}.tar.gz | |
| PCC-{version}-linux-{arch}.tar.gz | |
-| pump-{version}-linux-{arch}.tar.gz | |
-| drainer-{version}-linux-{arch}.tar.gz | |
-| binlogctl | 从 v6.0.0 起新增 |
| sync_diff_inspector | |
| reparo | |
-| arbiter | |
| server-{version}-linux-{arch}.tar.gz | 从 v6.2.0 起新增 |
| grafana-{version}-linux-{arch}.tar.gz | 从 v6.2.0 起新增 |
| alertmanager-{version}-linux-{arch}.tar.gz | 从 v6.2.0 起新增 |
diff --git a/clustered-indexes.md b/clustered-indexes.md
index 660b6df68f0a..bbd928f30661 100644
--- a/clustered-indexes.md
+++ b/clustered-indexes.md
@@ -145,15 +145,6 @@ mysql> SELECT TIDB_PK_TYPE FROM information_schema.tables WHERE table_schema = '
- 不支持对聚簇索引表进行降级。如需降级，请使用逻辑备份工具迁移数据。
- 尚未支持，但未来有计划支持的使用限制：
- 尚未支持通过 `ALTER TABLE` 语句增加、删除、修改聚簇索引。
-- 特定版本的限制：
- - 在 v5.0 版本中，聚簇索引不支持与 TiDB Binlog 一起使用。开启 TiDB Binlog 后，TiDB 只允许创建单个整数列作为主键的聚簇索引；已创建的聚簇索引表的数据插入、删除和更新动作不会通过 TiDB Binlog 同步到下游。如需同步聚簇索引表，请升级至 v5.1 版本或使用 [TiCDC](/ticdc/ticdc-overview.md)。
-
-开启 TiDB Binlog 之后，要创建的聚簇索引如果不是由单个整数列构成，会报以下错误：
-
-```sql
-mysql> CREATE TABLE t (a VARCHAR(255) PRIMARY KEY CLUSTERED);
-ERROR 8200 (HY000): Cannot create clustered index table when the binlog is ON
-```
与 `SHARD_ROW_ID_BITS` 一起使用时会报以下错误：
diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md
index 0b8f8bb779b6..c82595a39077 100644
--- a/command-line-flags-for-tidb-configuration.md
+++ b/command-line-flags-for-tidb-configuration.md
@@ -1,7 +1,7 @@
---
title: TiDB 配置参数
aliases: ['/docs-cn/dev/command-line-flags-for-tidb-configuration/','/docs-cn/dev/reference/configuration/tidb-server/configuration/']
-summary: TiDB 配置参数包括启动参数和环境变量。启动参数包括 advertise-address、config、config-check、config-strict、cors、enable-binlog 等。其中默认端口为 4000 和 10080。其他参数包括 log-file、metrics-addr、metrics-interval 等。注意配置文件的有效性和安全模式下的启动。
+summary: TiDB 配置参数包括启动参数和环境变量。启动参数包括 advertise-address、config、config-check、config-strict、cors 等。其中默认端口为 4000 和 10080。其他参数包括 log-file、metrics-addr、metrics-interval 等。注意配置文件的有效性和安全模式下的启动。
---
# TiDB 配置参数
@@ -41,11 +41,6 @@ summary: TiDB 配置参数包括启动参数和环境变量。启动参数包括
+ 用于设置 TiDB HTTP 状态服务的 Access-Control-Allow-Origin
+ 默认：""
-## `--enable-binlog`
-
-+ 开启或关闭 TiDB 中 binlog 的生成
-+ 默认：false
-
## `--host`
+ TiDB 服务监听的 host
diff --git a/credits.md b/credits.md
index f2b81115d929..b14d4d3f5d82 100644
--- a/credits.md
+++ b/credits.md
@@ -18,7 +18,6 @@ TiDB 开发者为 TiDB 的新功能开发、性能优化、稳定性保障做出
- [pingcap/tiflash](https://github.com/pingcap/tiflash/graphs/contributors)
- [pingcap/tidb-operator](https://github.com/pingcap/tidb-operator/graphs/contributors)
- [pingcap/tiup](https://github.com/pingcap/tiup/graphs/contributors)
-- [pingcap/tidb-binlog](https://github.com/pingcap/tidb-binlog/graphs/contributors)
- [pingcap/tidb-dashboard](https://github.com/pingcap/tidb-dashboard/graphs/contributors)
- [pingcap/tiflow](https://github.com/pingcap/tiflow/graphs/contributors)
- [pingcap/tidb-tools](https://github.com/pingcap/tidb-tools/graphs/contributors)
diff --git a/download-ecosystem-tools.md b/download-ecosystem-tools.md
index 966fb3c18780..f68f873ffb87 100644
--- a/download-ecosystem-tools.md
+++ b/download-ecosystem-tools.md
@@ -43,7 +43,6 @@ TiDB 工具包中包含了一些常用的 TiDB 工具，例如数据导出工具
| [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) | `tidb-lightning-ctl`
`tidb-lightning-{version}-linux-{arch}.tar.gz` |
| [TiDB DM (Data Migration)](/dm/dm-overview.md) | `dm-worker-{version}-linux-{arch}.tar.gz`
`dm-master-{version}-linux-{arch}.tar.gz`
`dmctl-{version}-linux-{arch}.tar.gz` |
| [TiCDC](/ticdc/ticdc-overview.md) | `cdc-{version}-linux-{arch}.tar.gz` |
-| [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) | `pump-{version}-linux-{arch}.tar.gz`
`drainer-{version}-linux-{arch}.tar.gz`
`binlogctl`
`reparo` |
| [Backup & Restore (BR)](/br/backup-and-restore-overview.md) | `br-{version}-linux-{arch}.tar.gz` |
| [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md) | `sync_diff_inspector` |
| [PD Recover](/pd-recover.md) | `pd-recover-{version}-linux-{arch}.tar.gz` |
diff --git a/ecosystem-tool-user-guide.md b/ecosystem-tool-user-guide.md
index 13f5da39841a..c186ea710d3e 100644
--- a/ecosystem-tool-user-guide.md
+++ b/ecosystem-tool-user-guide.md
@@ -1,7 +1,7 @@
---
title: TiDB 工具功能概览
aliases: ['/docs-cn/dev/ecosystem-tool-user-guide/','/docs-cn/dev/reference/tools/user-guide/','/docs-cn/dev/how-to/migrate/from-mysql/', '/docs-cn/dev/how-to/migrate/incrementally-from-mysql/', '/docs-cn/dev/how-to/migrate/overview/', '/docs-cn/dev/reference/tools/use-guide/']
-summary: TiDB 提供了丰富的工具，包括部署运维工具 TiUP 和 TiDB Operator，数据管理工具如 TiDB Data Migration（DM）、Dumpling、TiDB Lightning、Backup & Restore（BR）、TiCDC、TiDB Binlog、sync-diff-inspector，以及 OLAP 分析工具 TiSpark。这些工具可用于部署、数据迁移、备份恢复、数据校验等多种操作，满足不同需求。
+summary: TiDB 提供了丰富的工具，包括部署运维工具 TiUP 和 TiDB Operator，数据管理工具如 TiDB Data Migration（DM）、Dumpling、TiDB Lightning、Backup & Restore（BR）、TiCDC、sync-diff-inspector，以及 OLAP 分析工具 TiSpark。这些工具可用于部署、数据迁移、备份恢复、数据校验等多种操作，满足不同需求。
---
# TiDB 工具功能概览
@@ -121,21 +121,6 @@ TiDB 提供了 TiUP 和 TiDB Operator 部署运维工具，满足你在不同系
- TiCDC 的输出：TiDB 集群、MySQL、Kafka、Confluent
- 适用 TiDB 版本：v4.0.6 及以上
-### TiDB 增量日志同步 - TiDB Binlog
-
-[TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) 是收集 TiDB 的增量 binlog 数据，并提供准实时同步和备份的工具。该工具可用于 TiDB 集群间的增量数据同步，如将其中一个 TiDB 集群作为另一个 TiDB 集群的从集群。
-
-> **警告：**
->
-> 从 v7.5.0 开始，[TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) 的数据同步功能被废弃。从 v8.3.0 开始，TiDB Binlog 被完全废弃，并计划在未来版本中移除。如需进行增量数据同步，请使用 [TiCDC](/ticdc/ticdc-overview.md)。如需按时间点恢复 (point-in-time recovery, PITR)，请使用 [PITR](/br/br-pitr-guide.md)。
-
-基本信息：
-
-- TiDB Binlog 的输入：TiDB 集群
-- TiDB Binlog 的输出：TiDB 集群、MySQL、Kafka 或者增量备份文件
-- 适用 TiDB 版本：v2.1 及以上
-- Kubernetes 支持：[TiDB Binlog 运维文档](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/deploy-tidb-binlog)，[Kubernetes 上的 TiDB Binlog Drainer 配置](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/configure-tidb-binlog-drainer)
-
### 数据校验 - sync-diff-inspector
[sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md) 是一个用于校验 MySQL/TiDB 中两份数据是否一致的工具。该工具还提供了修复数据的功能，可用于修复少量不一致的数据。
diff --git a/faq/backup-and-restore-faq.md b/faq/backup-and-restore-faq.md
index 52d1782201fd..d2de7148558e 100644
--- a/faq/backup-and-restore-faq.md
+++ b/faq/backup-and-restore-faq.md
@@ -110,12 +110,12 @@ Error: failed to check gc safePoint, checkpoint ts 433177834291200000: GC safepo
## 功能兼容性问题
-### 为什么 BR 恢复的数据无法同步到 TiCDC / Drainer 的上游集群？
+### 为什么 BR 恢复的数据无法同步到 TiCDC 的上游集群？
- **BR 恢复的数据无法被同步到下游**，因为恢复时 BR 直接导入 SST 文件，而下游集群目前没有办法获得上游的 SST 文件。
-- 在 4.0.3 版本之前，恢复时产生的 DDL jobs 还可能会让 TiCDC / Drainer 执行异常的 DDL。所以，如果一定要在 TiCDC / Drainer 的上游集群执行恢复，请将 BR 恢复的所有表加入 TiCDC / Drainer 的阻止名单。
+- 在 4.0.3 版本之前，恢复时产生的 DDL jobs 还可能会让 TiCDC 执行异常的 DDL。所以，如果一定要在 TiCDC 的上游集群执行恢复，请将 BR 恢复的所有表加入 TiCDC 的阻止名单。
-TiCDC 可以通过配置项中的 [`filter.rules`](https://github.com/pingcap/tiflow/blob/7c3c2336f98153326912f3cf6ea2fbb7bcc4a20c/cmd/changefeed.toml#L16) 项完成，Drainer 则可以通过 [`syncer.ignore-table`](/tidb-binlog/tidb-binlog-configuration-file.md#ignore-table) 完成。
+TiCDC 可以通过配置项中的 [`filter.rules`](https://github.com/pingcap/tiflow/blob/7c3c2336f98153326912f3cf6ea2fbb7bcc4a20c/cmd/changefeed.toml#L16) 项完成。
### 恢复时为什么会报 `new_collation_enabled` 不匹配？
diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md
index 2a5d913cd461..f3be50ca9846 100644
--- a/faq/deploy-and-maintain-faq.md
+++ b/faq/deploy-and-maintain-faq.md
@@ -28,7 +28,7 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器
### TiDB 集群各个组件的配置推荐？
-- TiDB 需要 CPU 和内存比较好的机器，参考官网配置要求，如果后期需要开启 TiDB Binlog（已废弃），根据业务量的评估和 GC 时间的要求，也需要本地磁盘大一点，不要求 SSD 磁盘；
+- TiDB 需要 CPU 和内存比较好的机器，参考官网配置要求；
- PD 里面存了集群元信息，会有频繁的读写请求，对磁盘 I/O 要求相对比较高，磁盘太差会影响整个集群性能，推荐 SSD 磁盘，空间不用太大。另外集群 Region 数量越多对 CPU、内存的要求越高；
- TiKV 对 CPU、内存、磁盘要求都比较高，一定要用 SSD 磁盘。
@@ -71,8 +71,6 @@ TiDB 支持部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器
| enable_ntpd | 检测部署目标机器 NTP 服务，默认为 True，请勿关闭 |
| machine_benchmark | 检测部署目标机器磁盘 IOPS，默认为 True，请勿关闭 |
| set_hostname | 根据 IP 修改部署目标机器主机名，默认为 False |
-| enable_binlog | 是否部署 pump 并开启 binlog，默认为 False，依赖 Kafka 集群，参见 zookeeper_addrs 变量 |
-| zookeeper_addrs | binlog Kafka 集群的 ZooKeeper 地址 |
| enable_slow_query_log | TiDB 慢查询日志记录到单独文件({{ deploy_dir }}/log/tidb_slow_query.log)，默认为 False，记录到 tidb 日志 |
| deploy_without_tidb | KV 模式，不部署 TiDB 服务，仅部署 PD、TiKV 及监控服务，请将 inventory.ini 文件中 tidb_servers 主机组 IP 设置为空。 |
diff --git a/faq/faq-overview.md b/faq/faq-overview.md
index 6b21f7110f18..eb4ab2f5cba6 100644
--- a/faq/faq-overview.md
+++ b/faq/faq-overview.md
@@ -11,7 +11,7 @@ summary: 汇总 TiDB 产品的常见问题解答。
| :------- | :------------------- |
| 产品架构和原理 | [产品架构常见问题](/faq/tidb-faq.md) |
| 安装部署 | - [安装部署常见问题](/faq/deploy-and-maintain-faq.md)
- [TiUP 常见问题](/tiup/tiup-faq.md)
- [Kubernetes 上的 TiDB 集群常见问题](https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/faq)
|
-| 数据迁移 | - [数据迁移常见问题](/faq/migration-tidb-faq.md)
- 数据导入
- [TiDB Lightning 常见问题](/tidb-lightning/tidb-lightning-faq.md)
- [TiDB Data Migration 常见问题](/dm/dm-faq.md)
- 增量数据同步
- [TiCDC 常见问题解答](/ticdc/ticdc-faq.md)
- [TiDB Binlog 常见问题](/tidb-binlog/tidb-binlog-faq.md)
|
+| 数据迁移 | - [数据迁移常见问题](/faq/migration-tidb-faq.md)
- 数据导入
- [TiDB Lightning 常见问题](/tidb-lightning/tidb-lightning-faq.md)
- [TiDB Data Migration 常见问题](/dm/dm-faq.md)
- 增量数据同步
- [TiCDC 常见问题解答](/ticdc/ticdc-faq.md)
|
| 数据备份与恢复 | [备份与恢复常见问题](/faq/backup-and-restore-faq.md) |
| SQL 使用 | [SQL 操作常见问题](/faq/sql-faq.md) |
| 集群升级 | [TiDB 集群升级常见问题](/faq/upgrade-faq.md) |
diff --git a/faq/manage-cluster-faq.md b/faq/manage-cluster-faq.md
index ff44cfdf38ee..394de80f24ee 100644
--- a/faq/manage-cluster-faq.md
+++ b/faq/manage-cluster-faq.md
@@ -117,10 +117,7 @@ TiDB 目前社区非常活跃，同时，我们还在不断的优化和修改 BU
### 为什么事务没有使用异步提交或一阶段提交？
-在以下情况中，即使通过系统变量开启了[异步提交](/system-variables.md#tidb_enable_async_commit-从-v50-版本开始引入)和[一阶段提交](/system-variables.md#tidb_enable_1pc-从-v50-版本开始引入)，TiDB 也不会使用这些特性：
-
-- 如果开启了 TiDB Binlog，受 TiDB Binlog 的实现原理限制，TiDB 不会使用异步提交或一阶段提交特性。
-- TiDB 只在事务写入不超过 256 个键值对，以及所有键值对里键的总大小不超过 4 KB 时，才会使用异步提交或一阶段提交特性。这是因为对于写入量大的事务，异步提交不能明显提升执行性能。
+TiDB 只在事务写入不超过 256 个键值对，以及所有键值对里键的总大小不超过 4 KB 时，才会使用异步提交或一阶段提交特性。否则，即使通过系统变量开启了[异步提交](/system-variables.md#tidb_enable_async_commit-从-v50-版本开始引入)和[一阶段提交](/system-variables.md#tidb_enable_1pc-从-v50-版本开始引入)，TiDB 也不会使用这些特性。这是因为对于写入量大的事务，异步提交不能明显提升执行性能。
## PD 管理
diff --git a/faq/migration-tidb-faq.md b/faq/migration-tidb-faq.md
index bb83efa9db4f..5774d56c1c0e 100644
--- a/faq/migration-tidb-faq.md
+++ b/faq/migration-tidb-faq.md
@@ -11,7 +11,6 @@ aliases: ['/docs-cn/dev/faq/migration-tidb-faq/']
如果要查看迁移相关工具的常见问题，请参考以下链接：
- [备份与恢复常见问题](/faq/backup-and-restore-faq.md)
-- [TiDB Binlog 常见问题](/tidb-binlog/tidb-binlog-faq.md)
- [TiDB Lightning 常见问题](/tidb-lightning/tidb-lightning-faq.md)
- [Data Migration 常见问题](/dm/dm-faq.md)
- [TiCDC 常见问题](/ticdc/ticdc-faq.md)
diff --git a/faq/upgrade-faq.md b/faq/upgrade-faq.md
index e9a247e1cd44..bab9edfb403a 100644
--- a/faq/upgrade-faq.md
+++ b/faq/upgrade-faq.md
@@ -14,7 +14,7 @@ aliases: ['/docs-cn/dev/faq/upgrade-faq/','/docs-cn/dev/faq/upgrade/']
### 滚动升级有那些影响？
-滚动升级 TiDB 期间，业务运行会受到一定影响。因此，不建议在业务高峰期进行滚动升级。需要配置最小集群拓扑 (TiDB \* 2、PD \* 3、TiKV \* 3)，如果集群环境中有 Pump 和 Drainer 服务，建议先停止 Drainer，然后滚动升级（升级 TiDB 时会升级 Pump）。
+滚动升级 TiDB 期间，业务运行会受到一定影响。因此，不建议在业务高峰期进行滚动升级。需要配置最小集群拓扑 (TiDB \* 2、PD \* 3、TiKV \* 3)。
### 集群在执行 DDL 请求期间可以进行升级操作吗？
diff --git a/foreign-key.md b/foreign-key.md
index 3fda884b5076..1a28b5a6b3d4 100644
--- a/foreign-key.md
+++ b/foreign-key.md
@@ -302,7 +302,6 @@ Create Table | CREATE TABLE `child` (
### 与 TiDB 工具的兼容性
-- [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) 不支持外键功能。
- [DM](/dm/dm-overview.md) 不兼容外键功能。DM 在同步数据到下游 TiDB 时，会显式关闭下游 TiDB 的 [`foreign_key_checks`](/system-variables.md#foreign_key_checks)，所以由外键产生的级联操作不会从上游同步到下游，这会导致上下游数据不一致。
- [TiCDC](/ticdc/ticdc-overview.md) v6.6.0 兼容外键功能。旧版本的 TiCDC 在同步带外键的表时，可能会报错，建议使用 v6.6.0 之前版本 TiCDC 时先关闭下游 TiDB 集群的 `foreign_key_checks`。
- [BR](/br/backup-and-restore-overview.md) v6.6.0 兼容外键功能。之前版本的 BR 在恢复带外键的表到 v6.6.0 及之后版本的集群时，可能会报错，建议先关闭下游 TiDB 集群的 `foreign_key_checks` 后再恢复集群。
diff --git a/grafana-tidb-dashboard.md b/grafana-tidb-dashboard.md
index a594944ef217..18b394b9abac 100644
--- a/grafana-tidb-dashboard.md
+++ b/grafana-tidb-dashboard.md
@@ -51,7 +51,7 @@ aliases: ['/docs-cn/dev/grafana-tidb-dashboard/','/docs-cn/dev/reference/key-mon
- Panic And Critical Error：TiDB 中出现的 Panic、Critical Error 数量。
- Time Jump Back OPS：每个 TiDB 实例上每秒操作系统时间回跳的次数。
- Get Token Duration：每个连接获取 Token 的耗时。
-- Skip Binlog Count：TiDB 写入 Binlog 失败的数量。
+- Skip Binlog Count：TiDB 写入 Binlog 失败的数量。从 v8.4.0 开始，TiDB Binlog 已移除，该指标不再有计数。
- Client Data Traffic：TiDB 和客户端的数据流量。
### Transaction
diff --git a/hardware-and-software-requirements.md b/hardware-and-software-requirements.md
index 4cfe332bc840..552b2d366916 100644
--- a/hardware-and-software-requirements.md
+++ b/hardware-and-software-requirements.md
@@ -153,8 +153,6 @@ TiDB 作为开源一栈式实时 HTAP 数据库，其正常运行需要网络环
|TiFlash|20170|TiFlash Proxy 服务端口|
|TiFlash|20292|Prometheus 拉取 TiFlash Proxy metrics 端口|
|TiFlash|8234|Prometheus 拉取 TiFlash metrics 端口|
-| Pump | 8250 | Pump 通信端口 |
-| Drainer | 8249 | Drainer 通信端口 |
| CDC | 8300 | CDC 通信接口 |
| Monitoring | 9090 | Prometheus 服务通信端口 |
| Monitoring | 12020 | NgMonitoring 服务通信端口 |
diff --git a/identify-slow-queries.md b/identify-slow-queries.md
index 76adc129c0ff..c6ba6afb3f35 100644
--- a/identify-slow-queries.md
+++ b/identify-slow-queries.md
@@ -101,7 +101,7 @@ Slow Query 基础信息：
* `Write_keys`：表示该事务向 TiKV 的 Write CF 写入 Key 的数量。
* `Write_size`：表示事务提交时写 key 或 value 的总大小。
* `Prewrite_region`：表示事务两阶段提交中第一阶段（prewrite 阶段）涉及的 TiKV Region 数量。每个 Region 会触发一次远程过程调用。
-* `Wait_prewrite_binlog_time`：表示事务提交时用于写 binlog 的时间。
+* `Wait_prewrite_binlog_time`：表示事务提交时用于写 binlog 的时间。从 v8.4.0 开始，TiDB Binlog 已移除，不再有相关时间。
* `Resolve_lock_time`：表示事务提交时遇到锁后，清理锁或者等待锁过期的时间。
和内存使用相关的字段：
diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md
index 3c996dfbff46..76c65efdb687 100644
--- a/information-schema/information-schema-inspection-result.md
+++ b/information-schema/information-schema-inspection-result.md
@@ -259,7 +259,6 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo
| 组件 | 错误名字 | 相关监控表 | 错误说明 |
| ---- | ---- | ---- | ---- |
| TiDB | panic-count | tidb_panic_count_total_count | TiDB 出现 panic 错误 |
- | TiDB | binlog-error | tidb_binlog_error_total_count | TiDB 写 binlog 时出现的错误 |
| TiKV | critical-error | tikv_critical_error_total_count | TiKV 的 critical error |
| TiKV | scheduler-is-busy | tikv_scheduler_is_busy_total_count | TiKV 的 scheduler 太忙，会导致 TiKV 临时不可用 |
| TiKV | coprocessor-is-busy | tikv_coprocessor_is_busy_total_count | TiKV 的 coprocessor 太忙 |
diff --git a/maintain-tidb-using-tiup.md b/maintain-tidb-using-tiup.md
index 656e0710b1db..c3010d8ca084 100644
--- a/maintain-tidb-using-tiup.md
+++ b/maintain-tidb-using-tiup.md
@@ -20,7 +20,7 @@ tiup cluster list
## 启动集群
-启动集群操作会按 PD -> TiKV -> Pump -> TiDB -> TiFlash -> Drainer -> TiCDC -> Prometheus -> Grafana -> Alertmanager 的顺序启动整个 TiDB 集群所有组件：
+启动集群操作会按 PD -> TiKV -> TiDB -> TiFlash -> TiCDC -> Prometheus -> Grafana -> Alertmanager 的顺序启动整个 TiDB 集群所有组件：
{{< copyable "shell-regular" >}}
@@ -187,7 +187,7 @@ tiup cluster rename ${cluster-name} ${new-name}
## 关闭集群
-关闭集群操作会按 Alertmanager -> Grafana -> Prometheus -> TiCDC -> Drainer -> TiFlash -> TiDB -> Pump -> TiKV -> PD 的顺序关闭整个 TiDB 集群所有组件（同时也会关闭监控组件）：
+关闭集群操作会按 Alertmanager -> Grafana -> Prometheus -> TiCDC -> TiFlash -> TiDB -> TiKV -> PD 的顺序关闭整个 TiDB 集群所有组件（同时也会关闭监控组件）：
{{< copyable "shell-regular" >}}
diff --git a/migration-tools.md b/migration-tools.md
index 10fd9de7b584..35705430a1e1 100644
--- a/migration-tools.md
+++ b/migration-tools.md
@@ -52,7 +52,7 @@ TiDB 提供了丰富的数据迁移相关的工具，用于全量迁移、增量
| **上游** | TiDB |
| **下游（输出文件）** | SST，backup.meta 文件，backup.lock 文件 |
| **主要优势** | - 适用于向另一个 TiDB 迁移数据。
- 支持数据冷备份到外部存储，可以用于灾备恢复。
|
-| **使用限制** | - BR 恢复到 TiCDC / Drainer 的上游集群时，恢复数据无法由 TiCDC / Drainer 同步到下游。
- BR 只支持在 `mysql.tidb` 表中 `new_collation_enabled` 开关值相同的集群之间进行操作。
|
+| **使用限制** | - BR 恢复到 TiCDC 的上游集群时，恢复数据无法由 TiCDC 同步到下游。
- BR 只支持在 `mysql.tidb` 表中 `new_collation_enabled` 开关值相同的集群之间进行操作。
|
## [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)
diff --git a/placement-rules-in-sql.md b/placement-rules-in-sql.md
index d90a42d9393a..59ae34ef1f94 100644
--- a/placement-rules-in-sql.md
+++ b/placement-rules-in-sql.md
@@ -440,4 +440,3 @@ PLACEMENT POLICY=app_list
| Backup & Restore (BR) | 6.0 | BR 在 v6.0 之前不支持放置策略的备份与恢复，请参见[恢复 Placement Rule 到集群时为什么会报错？](/faq/backup-and-restore-faq.md#恢复-placement-rule-到集群时为什么会报错) |
| TiDB Lightning | 暂时不兼容 | 导入包含放置策略的数据时会报错 |
| TiCDC | 6.0 | 忽略放置策略，不同步策略到下游集群 |
-| TiDB Binlog | 6.0 | 忽略放置策略，不同步策略到下游集群 |
diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md
index 086e2768f26e..c4427ac237a6 100644
--- a/production-deployment-using-tiup.md
+++ b/production-deployment-using-tiup.md
@@ -8,7 +8,7 @@ aliases: ['/docs-cn/dev/production-offline-deployment-using-tiup/', '/zh/tidb/de
[TiUP](https://github.com/pingcap/tiup) 是 TiDB 4.0 版本引入的集群运维工具，[TiUP cluster](https://github.com/pingcap/tiup/tree/master/components/cluster) 是 TiUP 提供的使用 Golang 编写的集群管理组件，通过 TiUP cluster 组件就可以进行日常的运维工作，包括部署、启动、关闭、销毁、弹性扩缩容、升级 TiDB 集群，以及管理 TiDB 集群参数。
-目前 TiUP 可以支持部署 TiDB、TiFlash、[TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md)（已废弃）、TiCDC 以及监控系统。本文将介绍不同集群拓扑的具体部署步骤。
+目前 TiUP 可以支持部署 TiDB、TiFlash、TiCDC 以及监控系统。本文将介绍不同集群拓扑的具体部署步骤。
## 第 1 步：软硬件环境需求及前置检查
@@ -278,7 +278,6 @@ alertmanager_servers:
| OLTP 业务 | [部署最小拓扑架构](/minimal-deployment-topology.md) | [简单最小配置模板](/minimal-deployment-topology.md#拓扑模版)
[详细最小配置模板](/minimal-deployment-topology.md#拓扑模版) | 最小集群拓扑，包括 tidb-server、tikv-server、pd-server。 |
| HTAP 业务 | [部署 TiFlash 拓扑架构](/tiflash-deployment-topology.md) | [简单 TiFlash 配置模版](/tiflash-deployment-topology.md#拓扑模版)
[详细 TiFlash 配置模版](/tiflash-deployment-topology.md#拓扑模版) | 在最小拓扑的基础上部署 TiFlash。TiFlash 是列式存储引擎，已经逐步成为集群拓扑的标配。|
| 使用 [TiCDC](/ticdc/ticdc-overview.md) 进行增量同步 | [部署 TiCDC 拓扑架构](/ticdc-deployment-topology.md) | [简单 TiCDC 配置模板](/ticdc-deployment-topology.md#拓扑模版)
[详细 TiCDC 配置模板](/ticdc-deployment-topology.md#拓扑模版) | 在最小拓扑的基础上部署 TiCDC。TiCDC 支持多种下游：TiDB、MySQL、Kafka、MQ、Confluent 和存储服务。 |
-| 使用 [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) 进行增量同步 | [部署 TiDB Binlog 拓扑架构](/tidb-binlog-deployment-topology.md) | [简单 TiDB Binlog 配置模板（下游为 MySQL）](/tidb-binlog-deployment-topology.md#拓扑模版)
[简单 TiDB Binlog 配置模板（下游为 file）](/tidb-binlog-deployment-topology.md#拓扑模版)
[详细 TiDB Binlog 配置模板](/tidb-binlog-deployment-topology.md#拓扑模版) | 在最小拓扑的基础上部署 TiDB Binlog。 |
| 使用 Spark 的 OLAP 业务 | [部署 TiSpark 拓扑架构](/tispark-deployment-topology.md) | [简单 TiSpark 配置模板](/tispark-deployment-topology.md#拓扑模版)
[详细 TiSpark 配置模板](/tispark-deployment-topology.md#拓扑模版) | 在最小拓扑的基础上部署 TiSpark 组件。TiSpark 是 PingCAP 为解决用户复杂 OLAP 需求而推出的产品。TiUP cluster 组件对 TiSpark 的支持目前为实验特性。 |
| 单台机器，多个实例 | [混合部署拓扑架构](/hybrid-deployment-topology.md) | [简单混部配置模板](/hybrid-deployment-topology.md#拓扑模版)
[详细混部配置模板](/hybrid-deployment-topology.md#拓扑模版) | 也适用于单机多实例需要额外增加目录、端口、资源配比、label 等配置的场景。 |
| 跨机房部署 TiDB 集群 | [跨机房部署拓扑架构](/geo-distributed-deployment-topology.md) | [跨机房配置模板](/geo-distributed-deployment-topology.md#拓扑模版) | 以典型的两地三中心架构为例，介绍跨机房部署架构，以及需要注意的关键设置。 |
diff --git a/releases/release-2.1-ga.md b/releases/release-2.1-ga.md
index adb711ef4835..d1cc38bebcdc 100644
--- a/releases/release-2.1-ga.md
+++ b/releases/release-2.1-ga.md
@@ -1,7 +1,7 @@
---
title: TiDB 2.1 GA Release Notes
aliases: ['/docs-cn/dev/releases/release-2.1-ga/','/docs-cn/dev/releases/2.1ga/']
-summary: TiDB 2.1 GA 版本发布，对系统稳定性、性能、兼容性、易用性做了大量改进。包括 SQL 优化器、SQL 执行引擎、统计信息、表达式、Server、DDL、兼容性等方面的优化。PD (Placement Driver) 进行了可用性优化、调度器优化、API 及运维工具优化、监控和性能优化。TiKV 进行了 Coprocessor、Transaction、Raftstore、存储引擎和 tikv-ctl 方面的优化。同时支持全量数据快速导入工具 TiDB Lightning 和新版本 TiDB Binlog。升级兼容性说明包括存储引擎更新不支持回退至 2.0.x 或更旧版本，以及升级前需要确认集群中是否存在正在运行中的 DDL 操作。
+summary: TiDB 2.1 GA 版本发布，对系统稳定性、性能、兼容性、易用性做了大量改进。包括 SQL 优化器、SQL 执行引擎、统计信息、表达式、Server、DDL、兼容性等方面的优化。PD (Placement Driver) 进行了可用性优化、调度器优化、API 及运维工具优化、监控和性能优化。TiKV 进行了 Coprocessor、Transaction、Raftstore、存储引擎和 tikv-ctl 方面的优化。同时支持全量数据快速导入工具 TiDB Lightning。升级兼容性说明包括存储引擎更新不支持回退至 2.0.x 或更旧版本，以及升级前需要确认集群中是否存在正在运行中的 DDL 操作。
---
# TiDB 2.1 GA Release Notes
diff --git a/releases/release-2.1-rc.5.md b/releases/release-2.1-rc.5.md
index f37867aefb13..0ce2d75f47ef 100644
--- a/releases/release-2.1-rc.5.md
+++ b/releases/release-2.1-rc.5.md
@@ -1,7 +1,7 @@
---
title: TiDB 2.1 RC5 Release Notes
aliases: ['/docs-cn/dev/releases/release-2.1-rc.5/','/docs-cn/dev/releases/21rc5/']
-summary: TiDB 2.1 RC5 版本发布，对系统稳定性、优化器、统计信息和执行引擎做了很多改进。包括修复了多个问题，提升了性能，增加了环境变量设置功能。PD 修复了多个问题，TiKV 优化了报错信息和接口限制。TiDB 支持 TiDB Binlog cluster，不兼容旧版本。
+summary: TiDB 2.1 RC5 版本发布，对系统稳定性、优化器、统计信息和执行引擎做了很多改进。包括修复了多个问题，提升了性能，增加了环境变量设置功能。PD 修复了多个问题，TiKV 优化了报错信息和接口限制。
---
@@ -62,4 +62,4 @@ summary: TiDB 2.1 RC5 版本发布，对系统稳定性、优化器、统计信
## Tools
-- TiDB 支持 TiDB Binlog cluster，不兼容旧版本 TiDB Binlog [#8093](https://github.com/pingcap/tidb/pull/8093)，[使用文档](/tidb-binlog/tidb-binlog-overview.md)
+- TiDB 支持 TiDB Binlog cluster，不兼容旧版本 TiDB Binlog [#8093](https://github.com/pingcap/tidb/pull/8093)，[使用文档](https://docs-archive.pingcap.com/zh/tidb/v2.1/tidb-binlog-overview)
diff --git a/releases/release-7.5.0.md b/releases/release-7.5.0.md
index 4dbcc481cef8..1ec2d7105123 100644
--- a/releases/release-7.5.0.md
+++ b/releases/release-7.5.0.md
@@ -203,7 +203,7 @@ TiDB 7.5.0 为长期支持版本 (Long-Term Support Release, LTS)。
* TiKV-importer 组件在 v7.5.0 中废弃，建议使用 [TiDB Lightning 物理导入模式](/tidb-lightning/tidb-lightning-physical-import-mode.md)作为替代方案。
-* 从 v7.5.0 开始，不再提供 [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) 数据同步功能的技术支持，强烈建议使用 [TiCDC](/ticdc/ticdc-overview.md) 实现高效稳定的数据同步。尽管 TiDB Binlog 在 v7.5.0 仍支持 Point-in-Time Recovery (PITR) 场景，但是该组件在未来 LTS 版本中将被完全废弃，推荐使用 [PITR](/br/br-pitr-guide.md) 替代。
+* 从 v7.5.0 开始，不再提供 [TiDB Binlog](https://docs.pingcap.com/zh/tidb/v7.5/tidb-binlog-overview) 数据同步功能的技术支持，强烈建议使用 [TiCDC](/ticdc/ticdc-overview.md) 实现高效稳定的数据同步。尽管 TiDB Binlog 在 v7.5.0 仍支持 Point-in-Time Recovery (PITR) 场景，但是该组件在未来 LTS 版本中将被完全废弃，推荐使用 [PITR](/br/br-pitr-guide.md) 替代。
* 统计信息的[快速分析](/system-variables.md#tidb_enable_fast_analyze)（实验特性）在 v7.5.0 中废弃。
diff --git a/releases/release-8.3.0.md b/releases/release-8.3.0.md
index b332b2d0cf3d..a587ad7b423d 100644
--- a/releases/release-8.3.0.md
+++ b/releases/release-8.3.0.md
@@ -233,13 +233,13 @@ TiDB 版本：8.3.0
### 系统表
-* 在系统表 [`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md) 和 [`INFORMATION_SCHEMA.CLUSTER_PROCESSLIST`](/information-schema/information-schema-processlist.md#cluster_processlist) 中新增 `ROWS_AFFECTED` 字段，用于显示 DML 语句当前影响的数据行数。[#46889](https://github.com/pingcap/tidb/issues/46889) @[lcwangchao](https://github.com/lcwangchao)
+* 在系统表 [`INFORMATION_SCHEMA.PROCESSLIST`](/information-schema/information-schema-processlist.md) 和 [`INFORMATION_SCHEMA.CLUSTER_PROCESSLIST`](/information-schema/information-schema-processlist.md#cluster_processlist) 中新增 `ROWS_AFFECTED` 字段，用于显示 DML 语句当前影响的数据行数。[#46889](https://github.com/pingcap/tidb/issues/46889) @[lcwangchao](https://github.com/lcwangchao)
## 废弃功能
* 以下为从 v8.3.0 开始已废弃的功能：
- * 从 v7.5.0 开始，[TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) 的数据同步功能被废弃。从 v8.3.0 开始，TiDB Binlog 被完全废弃，并计划在未来版本中移除。如需进行增量数据同步，请使用 [TiCDC](/ticdc/ticdc-overview.md)。如需按时间点恢复 (point-in-time recovery, PITR)，请使用 [PITR](/br/br-pitr-guide.md)。
+ * 从 v7.5.0 开始，[TiDB Binlog](https://docs.pingcap.com/zh/tidb/v8.3/tidb-binlog-overview) 的数据同步功能被废弃。从 v8.3.0 开始，TiDB Binlog 被完全废弃，并计划在未来版本中移除。如需进行增量数据同步，请使用 [TiCDC](/ticdc/ticdc-overview.md)。如需按时间点恢复 (point-in-time recovery, PITR)，请使用 [PITR](/br/br-pitr-guide.md)。
* 从 v8.3.0 开始，系统变量 [`tidb_enable_column_tracking`](/system-variables.md#tidb_enable_column_tracking-从-v540-版本开始引入) 被废弃。TiDB 默认收集 [predicate columns](/glossary.md#predicate-columns) 的统计信息。更多信息，参见 [`tidb_analyze_column_options`](/system-variables.md#tidb_analyze_column_options-从-v830-版本开始引入)。
* 以下为计划将在未来版本中废弃的功能：
diff --git a/resources/doc-templates/template-concept.md b/resources/doc-templates/template-concept.md
index 178e1ec71d41..fc53de4f0876 100644
--- a/resources/doc-templates/template-concept.md
+++ b/resources/doc-templates/template-concept.md
@@ -7,7 +7,7 @@ summary: xxx（一句话介绍该文档的主要内容，请尽可能多地包
模板说明：
-- 本文档为概念介绍类模板，主要包含概念和说明信息。你可直接复制使用，并删除模板中不需要的说明。该类文档示例：[TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md)。
+- 本文档为概念介绍类模板，主要包含概念和说明信息。你可直接复制使用，并删除模板中不需要的说明。该类文档示例：[TiCDC 简介](/ticdc/ticdc-overview.md)。
- 对于新文档，请在 TOC.md 中合适的位置加目录（思考用户最有可能在目录哪里找文档）。
- 文内标题级别不可跳级，尽量避免使用五级标题。
diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md
index dd8f32ac44be..8c2d61e4809b 100644
--- a/scale-tidb-using-tiup.md
+++ b/scale-tidb-using-tiup.md
@@ -284,11 +284,8 @@ tiup cluster display
> **注意：**
>
> - 移除 TiDB、PD 节点和移除 TiKV 节点的步骤类似。
-> - 由于 TiKV、TiFlash 和 TiDB Binlog 组件是异步下线的，且下线过程耗时较长，所以 TiUP 对 TiKV、TiFlash 和 TiDB Binlog 组件做了特殊处理，详情参考[下线特殊处理](/tiup/tiup-component-cluster-scale-in.md#下线特殊处理)。
-
-> **注意：**
->
-> TiKV 中的 PD Client 会缓存 PD 节点的列表。当前版本的 TiKV 有定期自动更新 PD 节点的机制，可以降低 TiKV 缓存的 PD 节点列表过旧这一问题出现的概率。但你应尽量避免在扩容新 PD 后直接一次性缩容所有扩容前就已经存在的 PD 节点。如果需要，请确保在下线所有之前存在的 PD 节点前将 PD 的 leader 切换至新扩容的 PD 节点。
+> - 由于 TiKV 和 TiFlash 组件是异步下线的，且下线过程耗时较长，所以 TiUP 对 TiKV 和 TiFlash 组件做了特殊处理，详情参考[下线特殊处理](/tiup/tiup-component-cluster-scale-in.md#下线特殊处理)。
+> - TiKV 中的 PD Client 会缓存 PD 节点的列表。当前版本的 TiKV 有定期自动更新 PD 节点的机制，可以降低 TiKV 缓存的 PD 节点列表过旧这一问题出现的概率。但你应尽量避免在扩容新 PD 后直接一次性缩容所有扩容前就已经存在的 PD 节点。如果需要，请确保在下线所有之前存在的 PD 节点前将 PD 的 leader 切换至新扩容的 PD 节点。
### 1. 查看节点 ID 信息
diff --git a/sql-statements/sql-statement-alter-table-compact.md b/sql-statements/sql-statement-alter-table-compact.md
index 815746a9d86a..34be22d97718 100644
--- a/sql-statements/sql-statement-alter-table-compact.md
+++ b/sql-statements/sql-statement-alter-table-compact.md
@@ -200,9 +200,9 @@ SELECT PARTITION_NAME, TOTAL_DELTA_ROWS, TOTAL_STABLE_ROWS
`ALTER TABLE ... COMPACT` 语法是 TiDB 引入的对标准 SQL 语法的扩展。尽管没有对应的 MySQL 语法，但你仍然可通过 MySQL 各版本客户端，或各个遵循 MySQL 协议的数据库驱动执行该语句。
-### TiDB Binlog 及 TiCDC 兼容性
+### TiCDC 兼容性
-`ALTER TABLE ... COMPACT` 语句不会导致逻辑数据变化，因而不会被 TiDB Binlog 及 TiCDC 同步到下游。
+`ALTER TABLE ... COMPACT` 语句不会导致逻辑数据变化，因而不会被 TiCDC 同步到下游。
## 另请参阅
diff --git a/sql-statements/sql-statement-change-drainer.md b/sql-statements/sql-statement-change-drainer.md
deleted file mode 100644
index 1ea88953004f..000000000000
--- a/sql-statements/sql-statement-change-drainer.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: CHANGE DRAINER
-summary: TiDB 数据库中 CHANGE DRAINER 的使用概况。
-aliases: ['/docs-cn/dev/sql-statements/sql-statement-change-drainer/']
----
-
-# CHANGE DRAINER
-
-`CHANGE DRAINER` 语句用于修改集群中 Drainer 的状态信息。
-
-> **注意：**
->
-> Drainer 在正常运行时会自动上报状态到 PD，仅在 Drainer 处于异常情况导致实际状态与 PD 中保存的状态信息不一致时，使用该语句修改 PD 中存储的 Drainer 状态信息。
-
-## 示例
-
-{{< copyable "sql" >}}
-
-```sql
-SHOW DRAINER STATUS;
-```
-
-```sql
-+----------|----------------|--------|--------------------|---------------------|
-| NodeID | Address | State | Max_Commit_Ts | Update_Time |
-+----------|----------------|--------|--------------------|---------------------|
-| drainer1 | 127.0.0.3:8249 | Online | 408553768673342532 | 2019-04-30 00:00:03 |
-+----------|----------------|--------|--------------------|---------------------|
-| drainer2 | 127.0.0.4:8249 | Online | 408553768673345531 | 2019-05-01 00:00:04 |
-+----------|----------------|--------|--------------------|---------------------|
-2 rows in set (0.00 sec)
-```
-
-可以看出 `drainer1` 已经超过一天没有更新状态，该 Drainer 处于异常状态，但是 State 仍然为 `Online`，使用 `CHANGE DRAINER` 将该 Drainer 状态修改为 `paused`：
-
-{{< copyable "sql" >}}
-
-```sql
-CHANGE DRAINER TO NODE_STATE ='paused' FOR NODE_ID 'drainer1';
-```
-
-```sql
-Query OK, 0 rows affected (0.01 sec)
-```
-
-{{< copyable "sql" >}}
-
-```sql
-SHOW DRAINER STATUS;
-```
-
-```sql
-+----------|----------------|--------|--------------------|---------------------|
-| NodeID | Address | State | Max_Commit_Ts | Update_Time |
-+----------|----------------|--------|--------------------|---------------------|
-| drainer1 | 127.0.0.3:8249 | Paused | 408553768673342532 | 2019-04-30 00:00:03 |
-+----------|----------------|--------|--------------------|---------------------|
-| drainer2 | 127.0.0.4:8249 | Online | 408553768673345531 | 2019-05-01 00:00:04 |
-+----------|----------------|--------|--------------------|---------------------|
-2 rows in set (0.00 sec)
-```
-
-## MySQL 兼容性
-
-该语句是 TiDB 对 MySQL 语法的扩展。
-
-## 另请参阅
-
-* [SHOW PUMP STATUS](/sql-statements/sql-statement-show-pump-status.md)
-* [SHOW DRAINER STATUS](/sql-statements/sql-statement-show-drainer-status.md)
-* [CHANGE PUMP STATUS](/sql-statements/sql-statement-change-pump.md)
diff --git a/sql-statements/sql-statement-change-pump.md b/sql-statements/sql-statement-change-pump.md
deleted file mode 100644
index 0866d3b87c24..000000000000
--- a/sql-statements/sql-statement-change-pump.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: CHANGE PUMP
-summary: TiDB 数据库中 CHANGE PUMP 的使用概况。
-aliases: ['/docs-cn/dev/sql-statements/sql-statement-change-pump/']
----
-
-# CHANGE PUMP
-
-`CHANGE PUMP` 语句用于修改集群中 Pump 的状态信息。
-
-> **注意：**
->
-> Pump 在正常运行时会自动上报状态到 PD，仅在 Pump 处于异常情况导致实际状态与 PD 中保存的状态信息不一致时，使用该语句修改 PD 中存储的 Pump 状态信息。
-
-## 示例
-
-{{< copyable "sql" >}}
-
-```sql
-SHOW PUMP STATUS;
-```
-
-```sql
-+--------|----------------|--------|--------------------|---------------------|
-| NodeID | Address | State | Max_Commit_Ts | Update_Time |
-+--------|----------------|--------|--------------------|---------------------|
-| pump1 | 127.0.0.1:8250 | Online | 408553768673342237 | 2019-04-30 00:00:01 |
-+--------|----------------|--------|--------------------|---------------------|
-| pump2 | 127.0.0.2:8250 | Online | 408553768673342335 | 2019-05-01 00:00:02 |
-+--------|----------------|--------|--------------------|---------------------|
-2 rows in set (0.00 sec)
-```
-
-可以看出 `pump1` 已经超过一天没有更新状态，该 Pump 处于异常状态，但是 State 仍然为 `Online`，使用 `CHANGE PUMP` 将该 Pump 状态修改为 `paused`：
-
-{{< copyable "sql" >}}
-
-```sql
-CHANGE PUMP TO NODE_STATE ='paused' FOR NODE_ID 'pump1';
-```
-
-```sql
-Query OK, 0 rows affected (0.01 sec)
-```
-
-{{< copyable "sql" >}}
-
-```sql
-SHOW PUMP STATUS;
-```
-
-```sql
-+--------|----------------|--------|--------------------|---------------------|
-| NodeID | Address | State | Max_Commit_Ts | Update_Time |
-+--------|----------------|--------|--------------------|---------------------|
-| pump1 | 127.0.0.1:8250 | Paused | 408553768673342237 | 2019-04-30 00:00:01 |
-+--------|----------------|--------|--------------------|---------------------|
-| pump2 | 127.0.0.2:8250 | Online | 408553768673342335 | 2019-05-01 00:00:02 |
-+--------|----------------|--------|--------------------|---------------------|
-2 rows in set (0.00 sec)
-```
-
-## MySQL 兼容性
-
-该语句是 TiDB 对 MySQL 语法的扩展。
-
-## 另请参阅
-
-* [SHOW PUMP STATUS](/sql-statements/sql-statement-show-pump-status.md)
-* [SHOW DRAINER STATUS](/sql-statements/sql-statement-show-drainer-status.md)
-* [CHANGE DRAINER STATUS](/sql-statements/sql-statement-change-drainer.md)
diff --git a/sql-statements/sql-statement-flashback-database.md b/sql-statements/sql-statement-flashback-database.md
index 737805a5ae8f..c215aca7c3c3 100644
--- a/sql-statements/sql-statement-flashback-database.md
+++ b/sql-statements/sql-statement-flashback-database.md
@@ -37,12 +37,6 @@ FlashbackToNewName ::=
- 不能用 `FLASHBACK DATABASE` 多次恢复同一个被删除的数据库，因为 `FLASHBACK DATABASE` 所恢复数据库的 schema ID 和原被删除数据库的 schema ID 一致，多次恢复同一数据库会导致重复的 schema ID。在 TiDB 中，所有数据库的 schema ID 必须全局唯一。
-- 在开启 TiDB Binlog（已废弃）时，使用 `FLASHBACK DATABASE` 需要注意以下情况：
-
- * 下游从集群也需要支持 `FLASHBACK DATABASE`。
- * 从集群的 GC life time 一定要长于主集群的 GC life time。否则上下游同步存在的延迟可能也会造成下游恢复数据失败。
- * 如果 TiDB Binlog 同步出错，则需要在 TiDB Binlog 中过滤掉该数据库，同时手动全量重新导入该数据库的数据。
-
## 示例
- 恢复被 `DROP` 删除的 `test` 数据库：
diff --git a/sql-statements/sql-statement-flashback-table.md b/sql-statements/sql-statement-flashback-table.md
index 4066bd6c1b06..523ea73c4451 100644
--- a/sql-statements/sql-statement-flashback-table.md
+++ b/sql-statements/sql-statement-flashback-table.md
@@ -43,13 +43,6 @@ FlashbackToNewName ::=
如果删除了一张表并过了 GC lifetime，就不能再用 `FLASHBACK TABLE` 语句来恢复被删除的数据了，否则会返回错误，错误类似于 `Can't find dropped/truncated table 't' in GC safe point 2020-03-16 16:34:52 +0800 CST`。
-在开启 TiDB Binlog（已废弃）时使用 `FLASHBACK TABLE` 需要注意以下情况：
-
-* 下游从集群也支持 `FLASHBACK TABLE`
-* 从集群的 GC lifetime 一定要长于主集群的 GC lifetime。上下游同步存在的延迟可能也会造成下游恢复数据失败。
-
-如果 Binlog 同步出错，则需要在 Binlog 过滤掉该表，同时手动全量重新导入该表的数据。
-
## 示例
- 恢复被 `DROP` 删除的表数据：
diff --git a/sql-statements/sql-statement-overview.md b/sql-statements/sql-statement-overview.md
index e47b62d42375..e280e31ae20d 100644
--- a/sql-statements/sql-statement-overview.md
+++ b/sql-statements/sql-statement-overview.md
@@ -213,16 +213,12 @@ TiDB 使用的 SQL 语句旨在遵循 ISO/IEC SQL 标准，并在必要时对 My
| [`SHOW GRANTS`](/sql-statements/sql-statement-show-grants.md) | 显示与用户关联的权限。 |
| [`SHOW PRIVILEGES`](/sql-statements/sql-statement-show-privileges.md) | 显示可用的权限。 |
-## TiCDC 与 TiDB Binlog
+## TiCDC
| SQL 语句 | 描述 |
|----------|------|
| [`ADMIN [SET\|SHOW\|UNSET] BDR ROLE`](/sql-statements/sql-statement-admin-bdr-role.md) | 管理 BDR 角色。 |
-| [`CHANGE DRAINER`](/sql-statements/sql-statement-change-drainer.md) | 修改集群中 Drainer 的状态信息。 |
-| [`CHANGE PUMP`](/sql-statements/sql-statement-change-pump.md) | 修改集群中 Pump 的状态信息。 |
-| [`SHOW DRAINER STATUS`](/sql-statements/sql-statement-show-drainer-status.md) | 显示集群中所有 Drainer 节点的状态。 |
| [`SHOW MASTER STATUS`](/sql-statements/sql-statement-show-master-status.md) | 显示集群中当前最新的 TSO。 |
-| [`SHOW PUMP STATUS`](/sql-statements/sql-statement-show-pump-status.md) | 显示集群中所有 Pump 节点的状态信息。 |
## 统计信息和执行计划管理
diff --git a/sql-statements/sql-statement-recover-table.md b/sql-statements/sql-statement-recover-table.md
index 37d7a1402d94..36e29be959f9 100644
--- a/sql-statements/sql-statement-recover-table.md
+++ b/sql-statements/sql-statement-recover-table.md
@@ -40,26 +40,6 @@ NUM ::= intLit
如果删除表后并过了 GC lifetime，就不能再用 `RECOVER TABLE` 来恢复被删除的表了，执行 `RECOVER TABLE` 语句会返回类似错误：`snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST`。
-对于 3.0.0 及之后的 TiDB 版本，不推荐在使用 TiDB Binlog（已废弃）的情况下使用 `RECOVER TABLE` 功能。
-
-TiDB Binlog 在 3.0.1 支持 `RECOVER TABLE` 后，可在下面的情况下使用 `RECOVER TABLE`：
-
-* 3.0.1+ 版本的 TiDB Binlog
-* 主从集群都使用 TiDB 3.0
-* 从集群 GC lifetime 一定要长于主集群（不过由于上下游同步的延迟，可能也会造成下游 recover 失败）
-
-### TiDB Binlog 同步错误处理
-
-当使用 TiDB Binlog 同步工具时，上游 TiDB 使用 `RECOVER TABLE` 后，TiDB Binlog 可能会因为下面几个原因造成同步中断：
-
-* 下游数据库不支持 `RECOVER TABLE` 语句。类似错误：`check the manual that corresponds to your MySQL server version for the right syntax to use near 'RECOVER TABLE table_name'`。
-
-* 上下游数据库的 GC lifetime 不一样。类似错误：`snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST`。
-
-* 上下游数据库的同步延迟。类似错误：`snapshot is older than GC safe point 2019-07-10 13:45:57 +0800 CST`。
-
-只能通过重新[全量导入被删除的表](/ecosystem-tool-user-guide.md#备份和恢复---backup--restore)来恢复 TiDB Binlog 的数据同步。
-
## 示例
- 根据表名恢复被删除的表。
diff --git a/sql-statements/sql-statement-savepoint.md b/sql-statements/sql-statement-savepoint.md
index 6c660d0f48c4..48f6fef91e5a 100644
--- a/sql-statements/sql-statement-savepoint.md
+++ b/sql-statements/sql-statement-savepoint.md
@@ -15,7 +15,7 @@ RELEASE SAVEPOINT identifier
> **警告：**
>
-> `SAVEPOINT` 特性不支持与 TiDB Binlog 一起使用，也不支持在关闭 [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-从-v630-版本开始引入) 的悲观事务中使用。
+> `SAVEPOINT` 特性不支持在关闭 [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-从-v630-版本开始引入) 的悲观事务中使用。
- `SAVEPOINT` 语句用于在当前事务中，设置一个指定名字保存点。如果已经存在相同名字的保存点，就删除已有的保存点并设置新的保存点。
diff --git a/sql-statements/sql-statement-show-drainer-status.md b/sql-statements/sql-statement-show-drainer-status.md
deleted file mode 100644
index f72222fef883..000000000000
--- a/sql-statements/sql-statement-show-drainer-status.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: SHOW DRAINER STATUS
-summary: TiDB 数据库中 SHOW DRAINER STATUS 的使用概况。
-aliases: ['/docs-cn/dev/sql-statements/sql-statement-show-drainer-status/']
----
-
-# SHOW DRAINER STATUS
-
-`SHOW DRAINER STATUS` 语句用于显示集群中所有 Drainer 的状态信息。
-
-## 示例
-
-{{< copyable "sql" >}}
-
-```sql
-SHOW DRAINER STATUS;
-```
-
-```sql
-+----------|----------------|--------|--------------------|---------------------|
-| NodeID | Address | State | Max_Commit_Ts | Update_Time |
-+----------|----------------|--------|--------------------|---------------------|
-| drainer1 | 127.0.0.3:8249 | Online | 408553768673342532 | 2019-05-01 00:00:03 |
-+----------|----------------|--------|--------------------|---------------------|
-| drainer2 | 127.0.0.4:8249 | Online | 408553768673345531 | 2019-05-01 00:00:04 |
-+----------|----------------|--------|--------------------|---------------------|
-2 rows in set (0.00 sec)
-```
-
-## MySQL 兼容性
-
-该语句是 TiDB 对 MySQL 语法的扩展。
-
-## 另请参阅
-
-* [SHOW PUMP STATUS](/sql-statements/sql-statement-show-pump-status.md)
-* [CHANGE PUMP STATUS](/sql-statements/sql-statement-change-pump.md)
-* [CHANGE DRAINER STATUS](/sql-statements/sql-statement-change-drainer.md)
diff --git a/sql-statements/sql-statement-show-master-status.md b/sql-statements/sql-statement-show-master-status.md
index d6c6bc4e4449..690c9b8c208a 100644
--- a/sql-statements/sql-statement-show-master-status.md
+++ b/sql-statements/sql-statement-show-master-status.md
@@ -30,10 +30,3 @@ SHOW MASTER STATUS;
`SHOW MASTER STATUS` 语句与 MySQL 兼容，但是执行结果有差异，在 MySQL 中执行结果为 binlog 的位置信息，而在 TiDB 中为最新的 TSO 信息。
`SHOW BINARY LOG STATUS` 语句在 TiDB 中是 `SHOW MASTER STATUS` 的别名，但 `SHOW MASTER STATUS` 在 MySQL 8.2.0 及更高版本中已被废弃。
-
-## 另请参阅
-
-* [SHOW PUMP STATUS](/sql-statements/sql-statement-show-pump-status.md)
-* [SHOW DRAINER STATUS](/sql-statements/sql-statement-show-drainer-status.md)
-* [CHANGE PUMP STATUS](/sql-statements/sql-statement-change-pump.md)
-* [CHANGE DRAINER STATUS](/sql-statements/sql-statement-change-drainer.md)
diff --git a/sql-statements/sql-statement-show-pump-status.md b/sql-statements/sql-statement-show-pump-status.md
deleted file mode 100644
index cad513ee2f01..000000000000
--- a/sql-statements/sql-statement-show-pump-status.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: SHOW PUMP STATUS
-summary: TiDB 数据库中 SHOW PUMP STATUS 的使用概况。
-aliases: ['/docs-cn/dev/sql-statements/sql-statement-show-pump-status/']
----
-
-# SHOW PUMP STATUS
-
-`SHOW PUMP STATUS` 语句用于显示集群中所有 Pump 的状态信息。
-
-## 示例
-
-{{< copyable "sql" >}}
-
-```sql
-SHOW PUMP STATUS;
-```
-
-```sql
-+--------|----------------|--------|--------------------|---------------------|
-| NodeID | Address | State | Max_Commit_Ts | Update_Time |
-+--------|----------------|--------|--------------------|---------------------|
-| pump1 | 127.0.0.1:8250 | Online | 408553768673342237 | 2019-05-01 00:00:01 |
-+--------|----------------|--------|--------------------|---------------------|
-| pump2 | 127.0.0.2:8250 | Online | 408553768673342335 | 2019-05-01 00:00:02 |
-+--------|----------------|--------|--------------------|---------------------|
-2 rows in set (0.00 sec)
-```
-
-## MySQL 兼容性
-
-该语句是 TiDB 对 MySQL 语法的扩展。
-
-## 另请参阅
-
-* [SHOW DRAINER STATUS](/sql-statements/sql-statement-show-drainer-status.md)
-* [CHANGE PUMP STATUS](/sql-statements/sql-statement-change-pump.md)
-* [CHANGE DRAINER STATUS](/sql-statements/sql-statement-change-drainer.md)
diff --git a/system-variables.md b/system-variables.md
index cec73a463b29..cc8f9729e04a 100644
--- a/system-variables.md
+++ b/system-variables.md
@@ -595,14 +595,6 @@ mysql> SELECT * FROM t1;
- 默认值：`Apache License 2.0`
- 这个变量表示 TiDB 服务器的安装许可证。
-### `log_bin`
-
-- 作用域：NONE
-- 是否受 Hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value) 控制：否
-- 类型：布尔型
-- 默认值：`OFF`
-- 该变量表示是否使用 [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md)（已废弃）。
-
### `max_connections`
- 作用域：GLOBAL
@@ -821,19 +813,6 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count';
- 默认值：""
- 使用 MySQL 协议时，tidb-server 所监听的本地 unix 套接字文件。
-### `sql_log_bin`
-
-- 作用域：SESSION | GLOBAL
-- 是否持久化到集群：是
-- 是否受 Hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value) 控制：否
-- 类型：布尔型
-- 默认值：`ON`
-- 表示是否将更改写入 TiDB Binlog。
-
-> **注意：**
->
-> 不建议将 `sql_log_bin` 设置为全局变量，因为 TiDB 的未来版本可能只允许将其设置为会话变量。
-
### `sql_mode`
- 作用域：SESSION | GLOBAL
@@ -1659,7 +1638,6 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1;
> **注意：**
>
> - 对于新创建的集群，默认值为 ON。对于升级版本的集群，如果升级前是 v5.0 以下版本，升级后默认值为 `OFF`。
-> - 启用 TiDB Binlog（已废弃）后，开启该选项无法获得性能提升。要获得性能提升，建议使用 [TiCDC](/ticdc/ticdc-overview.md) 替代 TiDB Binlog。
> - 启用该参数仅意味着一阶段提交成为可选的事务提交模式，实际由 TiDB 自行判断选择最合适的提交模式进行事务提交。
### `tidb_enable_analyze_snapshot` 从 v6.2.0 版本开始引入
@@ -1688,7 +1666,6 @@ mysql> SELECT job_info FROM mysql.analyze_jobs ORDER BY end_time DESC LIMIT 1;
> **注意：**
>
> - 对于新创建的集群，默认值为 ON。对于升级版本的集群，如果升级前是 v5.0 以下版本，升级后默认值为 `OFF`。
-> - 启用 TiDB Binlog（已废弃）后，开启该选项无法获得性能提升。要获得性能提升，建议使用 [TiCDC](/ticdc/ticdc-overview.md) 替代 TiDB Binlog。
> - 启用该参数仅意味着 Async Commit 成为可选的事务提交模式，实际由 TiDB 自行判断选择最合适的提交模式进行事务提交。
### `tidb_enable_auto_analyze` 从 v6.1.0 版本开始引入
diff --git a/table-attributes.md b/table-attributes.md
index 49bc7468a262..254f81040977 100644
--- a/table-attributes.md
+++ b/table-attributes.md
@@ -7,10 +7,10 @@ summary: 介绍 TiDB 的 `ATTRIBUTES` 使用方法。
表属性是 TiDB 从 5.3.0 版本开始引入的新特性，用于为表或分区添加特定的属性，以对表或分区执行相应属性对应的操作，例如可以利用表属性控制 Region 的合并。
-> **注意：**
->
+> **注意：**
+>
> - 目前 TiDB 仅支持为表或分区添加 `merge_option` 属性，用于控制 Region 合并。该属性仅能处理部分热点问题。如需了解更多的热点问题处理相关内容，请参阅 [TiDB 热点问题处理](/troubleshoot-hot-spot-issues.md)。
-> - 当使用 TiDB Binlog 或 TiCDC 进行同步或者使用 BR 进行增量备份时，同步和备份会跳过设置表属性的 DDL 语句。如需在下游或者备份集群使用表属性，需要在下游或者备份集群手动执行该 DDL 语句以设置表属性。
+> - 当使用 TiCDC 进行同步或者使用 BR 进行增量备份时，同步和备份会跳过设置表属性的 DDL 语句。如需在下游或者备份集群使用表属性，需要在下游或者备份集群手动执行该 DDL 语句以设置表属性。
## 使用方法
diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md
index 5bfc6251ce00..dc16b3a7ca69 100644
--- a/three-data-centers-in-two-cities-deployment.md
+++ b/three-data-centers-in-two-cities-deployment.md
@@ -55,8 +55,6 @@ AZ1 的 rac1 机架中，一台服务器部署了 TiDB 和 PD 服务，另外两
机架 rac3 上部署了 TiDB Server、中控及监控服务器。TiDB Server 用于日常管理维护和备份。中控和监控服务器上部署了 Prometheus、Grafana 以及恢复工具。
-另可增加备份服务器，其上部署 Drainer，Drainer 以输出 file 文件的方式将 binlog 数据保存到指定位置，实现增量备份的目的。
-
## 配置
### 示例
diff --git a/ticdc-deployment-topology.md b/ticdc-deployment-topology.md
index da6001f3d7e0..b905604925b9 100644
--- a/ticdc-deployment-topology.md
+++ b/ticdc-deployment-topology.md
@@ -10,7 +10,7 @@ aliases: ['/docs-cn/dev/ticdc-deployment-topology/','/docs-cn/dev/reference/tool
>
> TiCDC 从 v4.0.6 起成为正式功能，可用于生产环境。
-本文介绍 [TiCDC](/ticdc/ticdc-overview.md) 部署的拓扑，以及如何在最小拓扑的基础上同时部署 TiCDC。TiCDC 是 4.0 版本开始支持的 TiDB 增量数据同步工具，支持多种下游（TiDB、MySQL、Kafka、MQ、存储服务等）。相比于 TiDB Binlog（已废弃），TiCDC 有延迟更低、天然高可用等优点。
+本文介绍 [TiCDC](/ticdc/ticdc-overview.md) 部署的拓扑，以及如何在最小拓扑的基础上同时部署 TiCDC。TiCDC 是 4.0 版本开始支持的 TiDB 增量数据同步工具，支持多种下游（TiDB、MySQL、Kafka、MQ、存储服务等），有延迟低、天然高可用等优点。
## 拓扑信息
diff --git a/ticdc/deploy-ticdc.md b/ticdc/deploy-ticdc.md
index a7f897c91e5a..1cc53570f60e 100644
--- a/ticdc/deploy-ticdc.md
+++ b/ticdc/deploy-ticdc.md
@@ -128,8 +128,6 @@ tiup cluster upgrade --transfer-timeout 600
pd: {}
tiflash: {}
tiflash-learner: {}
- pump: {}
- drainer: {}
cdc:
gc-ttl: 172800
```
diff --git a/tidb-binlog-deployment-topology.md b/tidb-binlog-deployment-topology.md
deleted file mode 100644
index cc515d3a387c..000000000000
--- a/tidb-binlog-deployment-topology.md
+++ /dev/null
@@ -1,346 +0,0 @@
----
-title: TiDB Binlog 部署拓扑
-summary: 介绍如何在部署最小拓扑集群的基础上，同时部署 TiDB Binlog。
-aliases: ['/docs-cn/dev/tidb-binlog-deployment-topology/']
----
-
-# TiDB Binlog 部署拓扑
-
-本文介绍在部署最小拓扑集群的基础上，同时部署 [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md)。TiDB Binlog 可提供准实时备份和同步功能。
-
-> **警告：**
->
-> 从 v7.5.0 开始，[TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) 的数据同步功能被废弃。从 v8.3.0 开始，TiDB Binlog 被完全废弃，并计划在未来版本中移除。如需进行增量数据同步，请使用 [TiCDC](/ticdc/ticdc-overview.md)。如需按时间点恢复 (point-in-time recovery, PITR)，请使用 [PITR](/br/br-pitr-guide.md)。
-
-## 拓扑信息
-
-| 实例 |个数| 物理机配置 | IP | 配置 |
-| :-- | :-- | :-- | :-- | :-- |
-|TiDB | 3 | 16 VCore 32 GB | 10.0.1.1
10.0.1.2
10.0.1.3 | 默认端口配置；
开启 enable_binlog；
开启 ignore-error |
-| PD | 3 | 4 VCore 8 GB | 10.0.1.4
10.0.1.5
10.0.1.6 | 默认端口配置 |
-| TiKV | 3 | 16 VCore 32 GB | 10.0.1.7
10.0.1.8
10.0.1.9 | 默认端口配置 |
-| Pump| 3 |8 VCore 16GB |10.0.1.1
10.0.1.7
10.0.1.8 | 默认端口配置；
设置 GC 时间 7 天 |
-| Drainer | 1 | 8 VCore 16GB | 10.0.1.12 | 默认端口配置；
设置默认初始化 commitTS -1 为最近的时间戳
配置下游目标 TiDB 10.0.1.12:4000 |
-
-### 拓扑模版
-
-
-简单 TiDB Binlog 配置模板（下游为 MySQL）
-
-```yaml
-# # Global variables are applied to all deployments and used as the default value of
-# # the deployments if a specific deployment value is missing.
-global:
- user: "tidb"
- ssh_port: 22
- deploy_dir: "/tidb-deploy"
- data_dir: "/tidb-data"
-
-server_configs:
- tidb:
- binlog.enable: true
- binlog.ignore-error: true
-
-pd_servers:
- - host: 10.0.1.4
- - host: 10.0.1.5
- - host: 10.0.1.6
-tidb_servers:
- - host: 10.0.1.1
- - host: 10.0.1.2
- - host: 10.0.1.3
-tikv_servers:
- - host: 10.0.1.7
- - host: 10.0.1.8
- - host: 10.0.1.9
-
-pump_servers:
- - host: 10.0.1.1
- - host: 10.0.1.2
- - host: 10.0.1.3
-drainer_servers:
- - host: 10.0.1.12
- config:
- syncer.db-type: "tidb"
- syncer.to.host: "10.0.1.12"
- syncer.to.user: "root"
- syncer.to.password: ""
- syncer.to.port: 4000
-
-monitoring_servers:
- - host: 10.0.1.10
-
-grafana_servers:
- - host: 10.0.1.10
-
-alertmanager_servers:
- - host: 10.0.1.10
-```
-
-
-
-
-简单 TiDB Binlog 配置模板（下游为 file）
-
-```yaml
-# # Global variables are applied to all deployments and used as the default value of
-# # the deployments if a specific deployment value is missing.
-global:
- user: "tidb"
- ssh_port: 22
- deploy_dir: "/tidb-deploy"
- data_dir: "/tidb-data"
-
-server_configs:
- tidb:
- binlog.enable: true
- binlog.ignore-error: true
-
-pd_servers:
- - host: 10.0.1.4
- - host: 10.0.1.5
- - host: 10.0.1.6
-tidb_servers:
- - host: 10.0.1.1
- - host: 10.0.1.2
- - host: 10.0.1.3
-tikv_servers:
- - host: 10.0.1.7
- - host: 10.0.1.8
- - host: 10.0.1.9
-
-pump_servers:
- - host: 10.0.1.1
- - host: 10.0.1.2
- - host: 10.0.1.3
-drainer_servers:
- - host: 10.0.1.12
- # drainer meta data directory path
- data_dir: "/path/to/save/data"
- config:
- syncer.db-type: "file"
- # directory to save binlog file, default same as data-dir(save checkpoint file) if this is not configured.
- # syncer.to.dir: "/path/to/save/binlog"
-
-monitoring_servers:
- - host: 10.0.1.10
-
-grafana_servers:
- - host: 10.0.1.10
-
-alertmanager_servers:
- - host: 10.0.1.10
-```
-
-
-
-
-详细 TiDB Binlog 配置模板
-
-```yaml
-# # Global variables are applied to all deployments and used as the default value of
-# # the deployments if a specific deployment value is missing.
-global:
- user: "tidb"
- ssh_port: 22
- deploy_dir: "/tidb-deploy"
- data_dir: "/tidb-data"
-
-# # Monitored variables are applied to all the machines.
-monitored:
- node_exporter_port: 9100
- blackbox_exporter_port: 9115
- # deploy_dir: "/tidb-deploy/monitored-9100"
- # data_dir: "/tidb-data/monitored-9100"
- # log_dir: "/tidb-deploy/monitored-9100/log"
-
-# # Server configs are used to specify the runtime configuration of TiDB components.
-# # All configuration items can be found in TiDB docs:
-# # - TiDB: https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file
-# # - TiKV: https://docs.pingcap.com/zh/tidb/stable/tikv-configuration-file
-# # - PD: https://docs.pingcap.com/zh/tidb/stable/pd-configuration-file
-# # All configuration items use points to represent the hierarchy, e.g:
-# # readpool.storage.use-unified-pool
-# #
-# # You can overwrite this configuration via the instance-level `config` field.
-
-server_configs:
- tidb:
- log.slow-threshold: 300
- binlog.enable: true
- binlog.ignore-error: true
- tikv:
- # server.grpc-concurrency: 4
- # raftstore.apply-pool-size: 2
- # raftstore.store-pool-size: 2
- # rocksdb.max-sub-compactions: 1
- # storage.block-cache.capacity: "16GB"
- # readpool.unified.max-thread-count: 12
- readpool.storage.use-unified-pool: false
- readpool.coprocessor.use-unified-pool: true
- pd:
- schedule.leader-schedule-limit: 4
- schedule.region-schedule-limit: 2048
- schedule.replica-schedule-limit: 64
-
-pd_servers:
- - host: 10.0.1.4
- # ssh_port: 22
- # name: "pd-1"
- # client_port: 2379
- # peer_port: 2380
- # deploy_dir: "/tidb-deploy/pd-2379"
- # data_dir: "/tidb-data/pd-2379"
- # log_dir: "/tidb-deploy/pd-2379/log"
- # numa_node: "0,1"
- # # The following configs are used to overwrite the `server_configs.pd` values.
- # config:
- # schedule.max-merge-region-size: 20
- # schedule.max-merge-region-keys: 200000
- - host: 10.0.1.5
- - host: 10.0.1.6
-tidb_servers:
- - host: 10.0.1.1
- # ssh_port: 22
- # port: 4000
- # status_port: 10080
- # deploy_dir: "/tidb-deploy/tidb-4000"
- # log_dir: "/tidb-deploy/tidb-4000/log"
- # numa_node: "0,1"
- # # The following configs are used to overwrite the `server_configs.tidb` values.
- # config:
- # log.slow-query-file: tidb-slow-overwrited.log
- - host: 10.0.1.2
- - host: 10.0.1.3
-tikv_servers:
- - host: 10.0.1.7
- # ssh_port: 22
- # port: 20160
- # status_port: 20180
- # deploy_dir: "/tidb-deploy/tikv-20160"
- # data_dir: "/tidb-data/tikv-20160"
- # log_dir: "/tidb-deploy/tikv-20160/log"
- # numa_node: "0,1"
- # # The following configs are used to overwrite the `server_configs.tikv` values.
- # config:
- # server.grpc-concurrency: 4
- # server.labels: { zone: "zone1", dc: "dc1", host: "host1" }
- - host: 10.0.1.8
- - host: 10.0.1.9
-
-pump_servers:
- - host: 10.0.1.1
- ssh_port: 22
- port: 8250
- deploy_dir: "/tidb-deploy/pump-8250"
- data_dir: "/tidb-data/pump-8250"
- # The following configs are used to overwrite the `server_configs.pump` values.
- config:
- gc: 7
- - host: 10.0.1.2
- ssh_port: 22
- port: 8250
- deploy_dir: "/tidb-deploy/pump-8250"
- data_dir: "/tidb-data/pump-8250"
- # The following configs are used to overwrite the `server_configs.pump` values.
- config:
- gc: 7
- - host: 10.0.1.3
- ssh_port: 22
- port: 8250
- deploy_dir: "/tidb-deploy/pump-8250"
- data_dir: "/tidb-data/pump-8250"
- # The following configs are used to overwrite the `server_configs.pump` values.
- config:
- gc: 7
-drainer_servers:
- - host: 10.0.1.12
- port: 8249
- deploy_dir: "/tidb-deploy/drainer-8249"
- data_dir: "/tidb-data/drainer-8249"
- # If drainer doesn't have a checkpoint, use initial commitTS as the initial checkpoint.
- # Will get a latest timestamp from pd if commit_ts is set to -1 (the default value).
- commit_ts: -1
- # The following configs are used to overwrite the `server_configs.drainer` values.
- config:
- syncer.db-type: "tidb"
- syncer.to.host: "10.0.1.12"
- syncer.to.user: "root"
- syncer.to.password: ""
- syncer.to.port: 4000
- syncer.to.checkpoint:
- schema: "tidb_binlog"
- type: "tidb"
- host: "10.0.1.14"
- user: "root"
- password: "123"
- port: 4000
- - host: 10.0.1.13
- port: 8249
- deploy_dir: "/tidb-deploy/drainer-8249"
- data_dir: "/tidb-data/drainer-8249"
- # If Drainer does not have a checkpoint, use the initial commitTS as the initial checkpoint.
- # If commit_ts is set to -1 (the default value), you will get a latest timestamp from PD.
- commit_ts: -1
- # The following configurations are used to overwrite the `server_configs.drainer` values.
- config:
- syncer.db-type: "kafka"
- syncer.replicate-do-db:
- - db1
- - db2
- syncer.to.kafka-addrs: "10.0.1.20:9092,10.0.1.21:9092,10.0.1.22:9092"
- syncer.to.kafka-version: "2.4.0"
- syncer.to.topic-name: "asyouwish"
-
-monitoring_servers:
- - host: 10.0.1.10
- # ssh_port: 22
- # port: 9090
- # deploy_dir: "/tidb-deploy/prometheus-8249"
- # data_dir: "/tidb-data/prometheus-8249"
- # log_dir: "/tidb-deploy/prometheus-8249/log"
-
-grafana_servers:
- - host: 10.0.1.10
- # port: 3000
- # deploy_dir: /tidb-deploy/grafana-3000
-
-alertmanager_servers:
- - host: 10.0.1.10
- # ssh_port: 22
- # web_port: 9093
- # cluster_port: 9094
- # deploy_dir: "/tidb-deploy/alertmanager-9093"
- # data_dir: "/tidb-data/alertmanager-9093"
- # log_dir: "/tidb-deploy/alertmanager-9093/log"
-```
-
-
-
-以上 TiDB 集群拓扑文件中，详细的配置项说明见[通过 TiUP 部署 TiDB 集群的拓扑文件配置](/tiup/tiup-cluster-topology-reference.md)。
-
-### 关键参数介绍
-
-拓扑配置模版的关键参数如下：
-
-- `server_configs.tidb.binlog.enable: true`
-
- 开启 TiDB Binlog 服务，默认为 false。
-
-- `server_configs.tidb.binlog.ignore-error: true`
-
- 高可用场景建议开启，如果设置为 true，发生错误时，TiDB 会停止写入 TiDB Binlog，并且在监控项 `tidb_server_critical_error_total` 上计数加 1；如果设置为 false，一旦写入 TiDB Binlog 失败，会停止整个 TiDB 的服务。
-
-- `drainer_servers.config.syncer.db-type`
-
- TiDB Binlog 的下游类型，目前支持 `mysql`、`tidb`、`kafka` 和 `file`。
-
-- `drainer_servers.config.syncer.to`
-
- TiDB Binlog 的下游配置。根据 `db-type` 的不同，该选项可配置下游数据库的连接参数、Kafka 的连接参数、文件保存路径。详细说明可参见 [TiDB Binlog 配置说明](/tidb-binlog/tidb-binlog-configuration-file.md#syncerto)。
-
-> **注意：**
->
-> - 编辑配置文件模版时，如无需自定义端口或者目录，仅修改 IP 即可。
-> - 无需手动创建配置文件中的 `tidb` 用户，TiUP cluster 组件会在目标主机上自动创建该用户。可以自定义用户，也可以和中控机的用户保持一致。
-> - 如果部署目录配置为相对路径，会部署在用户的 Home 目录下。
diff --git a/tidb-binlog/bidirectional-replication-between-tidb-clusters.md b/tidb-binlog/bidirectional-replication-between-tidb-clusters.md
deleted file mode 100644
index ab3f0ac64049..000000000000
--- a/tidb-binlog/bidirectional-replication-between-tidb-clusters.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: 集群间双向同步
-aliases: ['/docs-cn/dev/tidb-binlog/bidirectional-replication-between-tidb-clusters/','/docs-cn/dev/reference/tidb-binlog/bidirectional-replication/','/docs-cn/dev/reference/tidb-binlog/bi-repl/']
-summary: 本文介绍了如何使用 TiDB Binlog 实现集群间双向同步，包括使用场景、实现原理、标识表、同步 DDL 和配置开启双向同步。双向同步需保证数据写入两个集群不会发生冲突，且 DDL 操作采用单向同步。配置上需要设置相同的 channel-id，并在下游配置 sync-ddl 为 false。从 v8.3.0 开始，TiDB Binlog 被完全废弃。
----
-
-# 集群间双向同步
-
-> **警告：**
->
-> - 从 v7.5.0 开始，[TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) 的数据同步功能被废弃。从 v8.3.0 开始，TiDB Binlog 被完全废弃，并计划在未来版本中移除。如需进行增量数据同步，请使用 [TiCDC](/ticdc/ticdc-overview.md)。如需按时间点恢复 (point-in-time recovery, PITR)，请使用 [PITR](/br/br-pitr-guide.md)。
-> - TiDB Binlog 与 TiDB v5.0 开始引入的一些特性不兼容，无法一起使用，详情参照[注意事项](/tidb-binlog/tidb-binlog-overview.md#注意事项)。
-
-本文档介绍如何将一个 TiDB 集群的数据双向同步到另一个 TiDB 集群、双向同步的实现原理、如何开启双向同步、以及如何同步 DDL 操作。
-
-## 使用场景
-
-当用户需要在两个 TiDB 集群之间双向同步数据时，可使用 TiDB Binlog 进行操作。例如要将集群 A 的数据同步到集群 B，而且要将集群 B 的数据同步到集群 A。
-
-> **注意：**
->
-> 集群间双向同步的前提条件是，写入两个集群的数据必须保证无冲突，即在两个集群中，不会同时修改同一张表的同一主键和具有唯一索引的行。
-
-使用场景示例图如下：
-
-
-
-## 实现原理
-
-
-
-在 A 和 B 两个集群间开启双向同步，则写入集群 A 的数据会同步到集群 B 中，然后这部分数据又会继续同步到集群 A，这样就会出现无限循环同步的情况。如上图所示，在同步数据的过程中 Drainer 对 binlog 加上标记，通过过滤掉有标记的 binlog 来避免循环同步。详细的实现流程如下：
-
-1. 为两个集群分别启动 TiDB Binlog 同步程序。
-2. 待同步的事务经过 A 的 Drainer 时，Drainer 为事务加入 [`_drainer_repl_mark` 标识表](#标识表)，并在表中写入本次 DML event 更新，将事务同步至集群 B。
-3. 集群 B 向集群 A 返回带有 `_drainer_repl_mark` 标识表的 binlog event。集群 B 的 Drainer 在解析该 binlog event 时发现带有 DML event 的标识表，放弃同步该 binlog event 到集群 A。
-
-将集群 B 中的数据同步到集群 A 的流程与以上流程相同，两个集群可以互为上下游。
-
-> **注意：**
->
-> * 更新 `_drainer_repl_mark` 标识表时，一定要有数据改动才会产生 binlog。
-> * DDL 操作没有事务概念，因此采取单向同步的方案，见[同步 DDL](#同步-ddl)。
-
-Drainer 与下游的每个连接可以使用一个 ID 以避免冲突。`channel_id` 用来表示进行双向同步的一个通道。A 和 B 两个集群进行双向同步的配置应使用相同的值。
-
-当有添加或者删除列时，要同步到下游的数据可能会出现多列或者少列的情况。Drainer 通过添加配置来允许这种情况，会忽略多了的列值或者给少了的列写入默认值。
-
-## 标识表
-
-`_drainer_repl_mark` 标识表的结构如下：
-
-{{< copyable "sql" >}}
-
-```sql
-CREATE TABLE `_drainer_repl_mark` (
- `id` bigint(20) NOT NULL,
- `channel_id` bigint(20) NOT NULL DEFAULT '0',
- `val` bigint(20) DEFAULT '0',
- `channel_info` varchar(64) DEFAULT NULL,
- PRIMARY KEY (`id`,`channel_id`)
-);
-```
-
-Drainer 使用如下 SQL 语句更新 `_drainer_repl_mark` 可保证数据改动，从而保证产生 binlog：
-
-{{< copyable "sql" >}}
-
-```sql
-update drainer_repl_mark set val = val + 1 where id = ? && channel_id = ?;
-```
-
-## 同步 DDL
-
-因为 Drainer 无法为 DDL 操作加入标识表，所以采用单向同步的方式来同步 DDL 操作。
-
-比如集群 A 到集群 B 开启了 DDL 同步，则集群 B 到集群 A 会关闭 DDL 同步。即 DDL 操作全部在 A 上执行。
-
-> **注意：**
->
-> DDL 操作无法在两个集群上同时执行。执行 DDL 时，若同时有 DML 操作或者 DML binlog 没同步完，会可能出现 DML 同步的上下游表结构不一致的情况。
-
-## 配置并开启双向同步
-
-若要在集群 A 和集群 B 间进行双向同步，假设统一在集群 A 上执行 DDL。在集群 A 到集群 B 的同步路径上，向 Drainer 添加以下配置：
-
-{{< copyable "" >}}
-
-```toml
-[syncer]
-loopback-control = true
-channel-id = 1 # 互相同步的两个集群配置相同的 ID。
-sync-ddl = true # 需要同步 DDL 操作
-
-[syncer.to]
-# 1 表示 SyncFullColumn，2 表示 SyncPartialColumn。
-# 若设为 SyncPartialColumn，Drainer 会允许下游表结构比当前要同步的数据多或者少列
-# 并且去掉 SQL mode 的 STRICT_TRANS_TABLES，来允许少列的情况，并插入零值到下游。
-sync-mode = 2
-
-# 忽略 checkpoint 表。
-[[syncer.ignore-table]]
-db-name = "tidb_binlog"
-tbl-name = "checkpoint"
-```
-
-在集群 B 到集群 A 的同步路径上，向 Drainer 添加以下配置：
-
-{{< copyable "" >}}
-
-```toml
-[syncer]
-loopback-control = true
-channel-id = 1 # 互相同步的两个集群配置相同的 ID。
-sync-ddl = false # 不需要同步 DDL 操作。
-
-[syncer.to]
-# 1 表示 SyncFullColumn，2 表示 SyncPartialColumn。
-# 若设为 SyncPartialColumn，Drainer 会允许下游表结构比当前要同步的数据多或者少列
-# 并且去掉 SQL mode 的 STRICT_TRANS_TABLES，来允许少列的情况，并插入零值到下游。
-sync-mode = 2
-
-# 忽略 checkpoint 表。
-[[syncer.ignore-table]]
-db-name = "tidb_binlog"
-tbl-name = "checkpoint"
-```
diff --git a/tidb-binlog/binlog-consumer-client.md b/tidb-binlog/binlog-consumer-client.md
deleted file mode 100644
index 308d24131a70..000000000000
--- a/tidb-binlog/binlog-consumer-client.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-title: Binlog Consumer Client 用户文档
-aliases: ['/zh/tidb/dev/binlog-slave-client','/docs-cn/dev/tidb-binlog/binlog-slave-client/','/docs-cn/dev/reference/tidb-binlog/binlog-slave-client/','/docs-cn/dev/reference/tools/tidb-binlog/binlog-slave-client/']
-summary: Drainer 现在支持将 binlog 数据输出到 Kafka，用户可以根据自定义需求从 Kafka 中读取数据进行处理。用户需要修改 Drainer 配置文件，设置输出为 Kafka，并了解 Drainer 写入到 Kafka 中的数据格式。TiDB-Tools 项目提供了用于读取 Kafka 中 binlog 数据的 Driver，用户可以配置相关信息并以包的形式引用 Driver 的代码来使用。目前仅提供了 golang 版本的 Driver 以及示例代码，如果需要使用其他语言，用户需要自行开发程序读取 Kafka 中的 binlog 数据、解析数据、输出到下游。
----
-
-# Binlog Consumer Client 用户文档
-
-目前 Drainer 提供了多种输出方式，包括 MySQL、TiDB、file 等。但是用户往往有一些自定义的需求，比如输出到 Elasticsearch、Hive 等，这些需求 Drainer 现在还没有实现，因此 Drainer 增加了输出到 Kafka 的功能，将 binlog 数据解析后按一定的格式再输出到 Kafka 中，用户编写代码从 Kafka 中读出数据再进行处理。
-
-## 配置 Kafka Drainer
-
-修改 Drainer 的配置文件，设置输出为 Kafka，相关配置如下：
-
-```
-[syncer]
-db-type = "kafka"
-
-[syncer.to]
-# Kafka 地址
-kafka-addrs = "127.0.0.1:9092"
-# Kafka 版本号
-kafka-version = "2.4.0"
-```
-
-## 自定义开发
-
-### 数据格式
-
-首先需要了解 Drainer 写入到 Kafka 中的数据格式：
-
-```
-// Column 保存列的数据，针对数据的类型，保存在对应的变量中
-message Column {
- // 数据是否为 null
- optional bool is_null = 1 [ default = false ];
- // 保存 int 类型的数据
- optional int64 int64_value = 2;
- // 保存 uint、enum, set 类型的数据
- optional uint64 uint64_value = 3;
- // 保存 float、double 类型的数据
- optional double double_value = 4;
- // 保存 bit、blob、binary、json 类型的数据
- optional bytes bytes_value = 5;
- // 保存 date、time、decimal、text、char 类型的数据
- optional string string_value = 6;
-}
-
-// ColumnInfo 保存列的信息，包括列名、类型、是否为主键
-message ColumnInfo {
- optional string name = 1 [ (gogoproto.nullable) = false ];
- // MySQL 中小写的列字段类型
- // https://dev.mysql.com/doc/refman/8.0/en/data-types.html
- // numeric 类型：int bigint smallint tinyint float double decimal bit
- // string 类型：text longtext mediumtext char tinytext varchar
- // blob longblob mediumblob binary tinyblob varbinary
- // enum set
- // json 类型：json
- optional string mysql_type = 2 [ (gogoproto.nullable) = false ];
- optional bool is_primary_key = 3 [ (gogoproto.nullable) = false ];
-}
-
-// Row 保存一行的具体数据
-message Row { repeated Column columns = 1; }
-
-// MutationType 表示 DML 的类型
-enum MutationType {
- Insert = 0;
- Update = 1;
- Delete = 2;
-}
-
-// Table 包含一个表的数据变更
-message Table {
- optional string schema_name = 1;
- optional string table_name = 2;
- repeated ColumnInfo column_info = 3;
- repeated TableMutation mutations = 4;
-}
-
-// TableMutation 保存一行数据的变更
-message TableMutation {
- required MutationType type = 1;
- // 修改后的数据
- required Row row = 2;
- // 修改前的数据，只对 Update MutationType 有效
- optional Row change_row = 3;
-}
-
-// DMLData 保存一个事务所有的 DML 造成的数据变更
-message DMLData {
- // `tables` 包含事务中所有表的数据变更
- repeated Table tables = 1;
-}
-
-// DDLData 保存 DDL 的信息
-message DDLData {
- // 当前使用的数据库
- optional string schema_name = 1;
- // 相关表
- optional string table_name = 2;
- // `ddl_query` 是原始的 DDL 语句 query
- optional bytes ddl_query = 3;
-}
-
-// BinlogType 为 Binlog 的类型，分为 DML 和 DDL
-enum BinlogType {
- DML = 0; // Has `dml_data`
- DDL = 1; // Has `ddl_query`
-}
-
-// Binlog 保存一个事务所有的变更，Kafka 中保存的数据为该结构数据序列化后的结果
-message Binlog {
- optional BinlogType type = 1 [ (gogoproto.nullable) = false ];
- optional int64 commit_ts = 2 [ (gogoproto.nullable) = false ];
- optional DMLData dml_data = 3;
- optional DDLData ddl_data = 4;
-}
-```
-
-查看数据格式的具体定义，参见 [`secondary_binlog.proto`](https://github.com/pingcap/tidb/blob/master/pkg/tidb-binlog/proto/proto/secondary_binlog.proto)。
-
-### Driver
-
-TiDB-Tools 项目提供了用于读取 Kafka 中 binlog 数据的 Driver，具有如下功能：
-
-* 读取 Kafka 的数据
-* 根据 commit ts 查找 binlog 在 kafka 中的储存位置
-
-使用该 Driver 时，用户需要配置如下信息：
-
-* KafkaAddr：Kafka 集群的地址
-* CommitTS：从哪个 commit ts 开始读取 binlog
-* Offset：从 Kafka 哪个 offset 开始读取，如果设置了 CommitTS 就不用配置该参数
-* ClusterID：TiDB 集群的 cluster ID
-* Topic: Kafka Topic 名称，如果 Topic 名称为空，将会使用 drainer `_obinlog` 中的默认名称
-
-用户以包的形式引用 Driver 的代码即可使用，可以参考 Driver 中提供的示例代码来学习如何使用 Driver 以及 binlog 数据的解析，目前提供了两个例子：
-
-* 使用该 Driver 将数据同步到 MySQL，该示例包含将 binlog 转化为 SQL 的具体方法
-* 使用该 Driver 将数据打印出来
-
-Driver 项目地址：[Binlog Slave Driver](https://github.com/pingcap/tidb/tree/master/pkg/tidb-binlog/driver)。
-
-> **注意：**
->
-> - 示例代码仅仅用于示范如何使用 Driver，如果需要用于生产环境需要优化代码。
-> - 目前仅提供了 golang 版本的 Driver 以及示例代码。如果需要使用其他语言，用户需要根据 binlog 的 proto 文件生成相应语言的代码文件，并自行开发程序读取 Kafka 中的 binlog 数据、解析数据、输出到下游。也欢迎用户优化 example 代码，以及提交其他语言的示例代码到 [TiDB-Tools](https://github.com/pingcap/tidb-tools)。
diff --git a/tidb-binlog/binlog-control.md b/tidb-binlog/binlog-control.md
deleted file mode 100644
index 0f0b339fb3c9..000000000000
--- a/tidb-binlog/binlog-control.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: binlogctl 工具
-summary: 介绍 binlogctl 的使用方法。
-aliases: ['/docs-cn/dev/tidb-binlog/binlog-control/']
----
-
-# binlogctl 工具
-
-Binlog Control（以下简称 binlogctl）是 [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md)（已废弃）的命令行工具，用于管理 TiDB Binlog 集群。
-
-binlogctl 支持如下这些功能：
-
-* 查看 Pump/Drainer 状态
-* 暂停/下线 Pump/Drainer
-* Pump/Drainer 异常状态处理
-
-使用 binlogctl 的场景：
-
-* 同步出现故障/检查运行情况，需要查看 Pump/Drainer 的状态
-* 维护集群，需要暂停/下线 Pump/Drainer
-* Pump/Drainer 异常退出，状态没有更新，或者状态不符合预期，对业务造成影响
-
-## binlogctl 下载
-
-> **注意：**
->
-> 建议使用的 Control 工具版本与集群版本保持一致。
-
-binlogctl 的安装包位于 TiDB 离线工具包中。下载方式，请参考 [TiDB 工具下载](/download-ecosystem-tools.md)。
-
-## binlogctl 使用说明
-
-命令行参数：
-
-```bash
-Usage of binlogctl:
--V
-输出 binlogctl 的版本信息
--cmd string
- 命令模式，包括 "generate_meta"（已废弃）, "pumps", "drainers", "update-pump" ,"update-drainer", "pause-pump", "pause-drainer", "offline-pump", "offline-drainer"
--data-dir string
- 保存 Drainer 的 checkpoint 的文件的路径 (默认 "binlog_position")（已废弃）
--node-id string
- Pump/Drainer 的 ID
--pd-urls string
- PD 的地址，如果有多个，则用"," 连接 (默认 "http://127.0.0.1:2379")
--ssl-ca string
- SSL CAs 文件的路径
--ssl-cert string
- PEM 格式的 X509 认证文件的路径
--ssl-key string
- PEM 格式的 X509 key 文件的路径
--time-zone string
- 如果设置时区，在 "generate_meta" 模式下会打印出获取到的 tso 对应的时间。例如 "Asia/Shanghai" 为 CST 时区，"Local" 为本地时区
--show-offline-nodes
- 在用 `-cmd pumps` 或 `-cmd drainers` 命令时使用，这两个命令默认不显示 offline 的节点，仅当明确指定 `-show-offline-nodes` 时会显示
-```
-
-命令示例：
-
-- 查询所有的 Pump/Drainer 的状态：
-
- 设置 `cmd` 为 `pumps` 或者 `drainers` 来查看所有 Pump 或者 Drainer 的状态。例如：
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pumps
- ```
-
- ```
- [2019/04/28 09:29:59.016 +00:00] [INFO] [nodes.go:48] ["query node"] [type=pump] [node="{NodeID: 1.1.1.1:8250, Addr: pump:8250, State: online, MaxCommitTS: 408012403141509121, UpdateTime: 2019-04-28 09:29:57 +0000 UTC}"]
- ```
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd drainers
- ```
-
- ```
- [2019/04/28 09:29:59.016 +00:00] [INFO] [nodes.go:48] ["query node"] [type=drainer] [node="{NodeID: 1.1.1.1:8249, Addr: 1.1.1.1:8249, State: online, MaxCommitTS: 408012403141509121, UpdateTime: 2019-04-28 09:29:57 +0000 UTC}"]
- ```
-
-- 暂停/下线 Pump/Drainer
-
- binlogctl 提供以下命令暂停/下线服务：
-
- | cmd | 说明 | 示例 |
- | --------------- | ------------- | ------------------------------------------------------------------------------------------------|
- | pause-pump | 暂停 Pump | `bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pause-pump -node-id ip-127-0-0-1:8250` |
- | pause-drainer | 暂停 Drainer | `bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd pause-drainer -node-id ip-127-0-0-1:8249` |
- | offline-pump | 下线 Pump | `bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd offline-pump -node-id ip-127-0-0-1:8250` |
- | offline-drainer | 下线 Drainer | `bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd offline-drainer -node-id ip-127-0-0-1:8249` |
-
- binlogctl 会发送 HTTP 请求给 Pump/Drainer，Pump/Drainer 收到命令后会主动执行对应的退出流程。
-
-- 异常情况下修改 Pump/Drainer 的状态
-
- 在服务正常运行以及符合流程的暂停、下线过程中，Pump/Drainer 的状态都是可以正确的。但是在一些异常情况下 Pump/Drainer 无法正确维护自己的状态，可能会影响数据同步任务，在这种情况下需要使用 binlogctl 修复状态信息。
-
- 设置 `cmd` 为 `update-pump` 或者 `update-drainer` 来更新 Pump 或者 Drainer 的状态。Pump 和 Drainer 的状态可以为 paused 或者 offline。例如：
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- bin/binlogctl -pd-urls=http://127.0.0.1:2379 -cmd update-pump -node-id ip-127-0-0-1:8250 -state paused
- ```
-
- > **注意：**
- >
- > Pump/Drainer 在正常运行过程中会定期在 PD 中更新自己的状态，而这条命令是直接去修改 Pump/Drainer 保存在 PD 中的状态，所以在 Pump/Drainer 服务正常的情况下使用这些命令是没有意义的。仅在 Pump/Drainer 服务异常的情况下使用，具体哪些场景下使用这条命令可以参考 FAQ。
\ No newline at end of file
diff --git a/tidb-binlog/deploy-tidb-binlog.md b/tidb-binlog/deploy-tidb-binlog.md
deleted file mode 100644
index 0d66567408cb..000000000000
--- a/tidb-binlog/deploy-tidb-binlog.md
+++ /dev/null
@@ -1,368 +0,0 @@
----
-title: TiDB Binlog 集群部署
-aliases: ['/docs-cn/dev/tidb-binlog/deploy-tidb-binlog/','/docs-cn/dev/reference/tidb-binlog/deploy/','/docs-cn/dev/how-to/deploy/tidb-binlog/','/docs-cn/dev/reference/tools/tidb-binlog/deploy/']
-summary: TiDB Binlog 集群部署需要满足服务器硬件配置要求。推荐使用 TiUP 部署 TiDB Binlog，也可以使用 Binary 部署。部署过程中需要注意配置参数和启动命令。在运行 TiDB 时，需要保证至少一个 Pump 正常运行。Drainer 不支持对 ignore schemas 的 table 进行 rename DDL 操作。从 v8.3.0 开始，TiDB Binlog 被完全废弃。
----
-
-# TiDB Binlog 集群部署
-
-> **警告：**
->
-> 从 v7.5.0 开始，[TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) 的数据同步功能被废弃。从 v8.3.0 开始，TiDB Binlog 被完全废弃，并计划在未来版本中移除。如需进行增量数据同步，请使用 [TiCDC](/ticdc/ticdc-overview.md)。如需按时间点恢复 (point-in-time recovery, PITR)，请使用 [PITR](/br/br-pitr-guide.md)。
-
-## 服务器要求
-
-Pump 和 Drainer 均可部署和运行在 Intel x86-64 架构的 64 位通用硬件服务器平台上。在开发、测试和生产环境下，对服务器硬件配置的要求和建议如下：
-
-| 服务 | 部署数量 | CPU | 磁盘 | 内存 |
-| :-------- | :-------- | :--------| :--------------- | :------ |
-| Pump | 3 | 8核+ | SSD, 200 GB+ | 16G |
-| Drainer | 1 | 8核+ | SAS, 100 GB+ （如果输出 binlog 为本地文件，磁盘大小视保留数据天数而定） | 16G |
-
-## 使用 TiUP 部署 TiDB Binlog
-
-推荐使用 TiUP 部署 TiDB Binlog。即在使用 TiUP 部署 TiDB 时，在[拓扑文件](/tidb-binlog-deployment-topology.md)中添加 TiDB Binlog 的 `drainer` 和 `pump` 节点信息后，再随 TiDB 一起部署。详细部署方式参考 [TiUP 部署 TiDB 集群](/production-deployment-using-tiup.md)。
-
-## 使用 Binary 部署 TiDB Binlog
-
-### 下载 TiDB Binlog 安装包
-
-TiDB Binlog 安装包位于 TiDB 离线工具包中。下载方式，请参考 [TiDB 工具下载](/download-ecosystem-tools.md)。
-
-### 使用样例
-
-假设有三个 PD，一个 TiDB，另外有两台机器用于部署 Pump，一台机器用于部署 Drainer。各个节点信息如下：
-
-```
-TiDB="192.168.0.10"
-PD1="192.168.0.16"
-PD2="192.168.0.15"
-PD3="192.168.0.14"
-Pump="192.168.0.11"
-Pump="192.168.0.12"
-Drainer="192.168.0.13"
-```
-
-下面以此为例，说明 Pump/Drainer 的使用。
-
-1. 使用 binary 部署 Pump
-
- - Pump 命令行参数说明（以在 “192.168.0.11” 上部署为例）
-
- ```bash
- Usage of Pump:
- -L string
- 日志输出信息等级设置：debug，info，warn，error，fatal (默认 "info")
- -V
- 打印版本信息
- -addr string
- Pump 提供服务的 RPC 地址(-addr="192.168.0.11:8250")
- -advertise-addr string
- Pump 对外提供服务的 RPC 地址(-advertise-addr="192.168.0.11:8250")
- -config string
- 配置文件路径，如果你指定了配置文件，Pump 会首先读取配置文件的配置;
- 如果对应的配置在命令行参数里面也存在，Pump 就会使用命令行参数的配置来覆盖配置文件里的配置。
- -data-dir string
- Pump 数据存储位置路径
- -gc int
- Pump 只保留多少天以内的数据 (默认 7)
- -heartbeat-interval int
- Pump 向 PD 发送心跳间隔 (单位 秒)
- -log-file string
- log 文件路径
- -log-rotate string
- log 文件切换频率，hour/day
- -metrics-addr string
- Prometheus Pushgateway 地址，不设置则禁止上报监控信息
- -metrics-interval int
- 监控信息上报频率 (默认 15，单位 秒)
- -node-id string
- Pump 节点的唯一识别 ID，如果不指定，程序会根据主机名和监听端口自动生成
- -pd-urls string
- PD 集群节点的地址 (-pd-urls="http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379")
- -fake-binlog-interval int
- Pump 节点生成 fake binlog 的频率 (默认 3，单位 秒)
- ```
-
- - Pump 配置文件（以在 “192.168.0.11” 上部署为例）
-
- ```toml
- # Pump Configuration
-
- # Pump 绑定的地址
- addr = "192.168.0.11:8250"
-
- # Pump 对外提供服务的地址
- advertise-addr = "192.168.0.11:8250"
-
- # Pump 只保留多少天以内的数据 (默认 7)
- gc = 7
-
- # Pump 数据存储位置路径
- data-dir = "data.pump"
-
- # Pump 向 PD 发送心跳的间隔 (单位 秒)
- heartbeat-interval = 2
-
- # PD 集群节点的地址 (英文逗号分割，中间不加空格)
- pd-urls = "http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379"
-
- # [security]
- # 如无特殊安全设置需要，该部分一般都注解掉
- # 包含与集群连接的受信任 SSL CA 列表的文件路径
- # ssl-ca = "/path/to/ca.pem"
- # 包含与集群连接的 PEM 形式的 X509 certificate 的路径
- # ssl-cert = "/path/to/drainer.pem"
- # 包含与集群链接的 PEM 形式的 X509 key 的路径
- # ssl-key = "/path/to/drainer-key.pem"
-
- # [storage]
- # 设置为 true（默认值）来保证可靠性，确保 binlog 数据刷新到磁盘
- # sync-log = true
-
- # 当可用磁盘容量小于该设置值时，Pump 将停止写入数据
- # 42 MB -> 42000000, 42 mib -> 44040192
- # default: 10 gib
- # stop-write-at-available-space = "10 gib"
-
- # Pump 内嵌的 LSM DB 设置，除非对该部分很了解，否则一般注解掉
- # [storage.kv]
- # block-cache-capacity = 8388608
- # block-restart-interval = 16
- # block-size = 4096
- # compaction-L0-trigger = 8
- # compaction-table-size = 67108864
- # compaction-total-size = 536870912
- # compaction-total-size-multiplier = 8.0
- # write-buffer = 67108864
- # write-L0-pause-trigger = 24
- # write-L0-slowdown-trigger = 17
- ```
-
- - 启动示例
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- ./pump -config pump.toml
- ```
-
- 如果命令行参数与配置文件中的参数重合，则使用命令行设置的参数的值。
-
-2. 使用 binary 部署 Drainer
-
- - Drainer 命令行参数说明（以在 “192.168.0.13” 上部署为例）
-
- ```bash
- Usage of Drainer
- -L string
- 日志输出信息等级设置：debug，info，warn，error，fatal (默认 "info")
- -V
- 打印版本信息
- -addr string
- Drainer 提供服务的地址(-addr="192.168.0.13:8249")
- -c int
- 同步下游的并发数，该值设置越高同步的吞吐性能越好 (default 1)
- -cache-binlog-count int
- 缓存中的 binlog 数目限制（默认 8）
- 如果上游的单个 binlog 较大导致 Drainer 出现 OOM 时，可尝试调小该值减少内存使用
- -config string
- 配置文件路径，Drainer 会首先读取配置文件的配置；
- 如果对应的配置在命令行参数里面也存在，Drainer 就会使用命令行参数的配置来覆盖配置文件里面的配置
- -data-dir string
- Drainer 数据存储位置路径 (默认 "data.drainer")
- -dest-db-type string
- Drainer 下游服务类型 (默认为 mysql，支持 tidb、kafka、file)
- -detect-interval int
- 向 PD 查询在线 Pump 的时间间隔 (默认 10，单位 秒)
- -disable-detect
- 是否禁用冲突监测
- -disable-dispatch
- 是否禁用拆分单个 binlog 的 SQL 的功能，如果设置为 true，则每个 binlog
- 按顺序依次还原成单个事务进行同步（下游服务类型为 MySQL，该项设置为 False）
- -ignore-schemas string
- db 过滤列表 (默认 "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test")，
- 不支持对 ignore schemas 的 table 进行 rename DDL 操作
- -initial-commit-ts（默认为 `-1`）
- 如果 Drainer 没有相关的断点信息，可以通过该项来设置相关的断点信息
- 该参数值为 `-1` 时，Drainer 会自动从 PD 获取一个最新的时间戳
- -log-file string
- log 文件路径
- -log-rotate string
- log 文件切换频率，hour/day
- -metrics-addr string
- Prometheus Pushgateway 地址，不设置则禁止上报监控信息
- -metrics-interval int
- 监控信息上报频率（默认 15，单位：秒）
- -node-id string
- drainer 节点的唯一识别 ID，如果不指定，程序会根据主机名和监听端口自动生成
- -pd-urls string
- PD 集群节点的地址 (-pd-urls="http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379")
- -safe-mode
- 是否开启安全模式使得下游 MySQL/TiDB 可被重复写入
- 即将 insert 语句换为 replace 语句，将 update 语句拆分为 delete + replace 语句
- -txn-batch int
- 输出到下游数据库一个事务的 SQL 数量（默认 1）
- ```
-
- - Drainer 配置文件（以在 “192.168.0.13” 上部署为例）
-
- ```toml
- # Drainer Configuration.
-
- # Drainer 提供服务的地址("192.168.0.13:8249")
- addr = "192.168.0.13:8249"
-
- # Drainer 对外提供服务的地址
- advertise-addr = "192.168.0.13:8249"
-
- # 向 PD 查询在线 Pump 的时间间隔 (默认 10，单位 秒)
- detect-interval = 10
-
- # Drainer 数据存储位置路径 (默认 "data.drainer")
- data-dir = "data.drainer"
-
- # PD 集群节点的地址 (英文逗号分割，中间不加空格)
- pd-urls = "http://192.168.0.16:2379,http://192.168.0.15:2379,http://192.168.0.14:2379"
-
- # log 文件路径
- log-file = "drainer.log"
-
- # Drainer 从 Pump 获取 binlog 时对数据进行压缩，值可以为 "gzip"，如果不配置则不进行压缩
- # compressor = "gzip"
-
- # [security]
- # 如无特殊安全设置需要，该部分一般都注解掉
- # 包含与集群连接的受信任 SSL CA 列表的文件路径
- # ssl-ca = "/path/to/ca.pem"
- # 包含与集群连接的 PEM 形式的 X509 certificate 的路径
- # ssl-cert = "/path/to/pump.pem"
- # 包含与集群链接的 PEM 形式的 X509 key 的路径
- # ssl-key = "/path/to/pump-key.pem"
-
- # Syncer Configuration
- [syncer]
- # 如果设置了该项，会使用该 sql-mode 解析 DDL 语句，此时如果下游是 MySQL 或 TiDB 则
- # 下游的 sql-mode 也会被设置为该值
- # sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
-
- # 输出到下游数据库一个事务的 SQL 语句数量 (默认 20)
- txn-batch = 20
-
- # 同步下游的并发数，该值设置越高同步的吞吐性能越好 (默认 16)
- worker-count = 16
-
- # 是否禁用拆分单个 binlog 的 SQL 的功能，如果设置为 true，则按照每个 binlog
- # 顺序依次还原成单个事务进行同步（下游服务类型为 MySQL, 该项设置为 False）
- disable-dispatch = false
-
- # safe mode 会使写下游 MySQL/TiDB 可被重复写入
- # 会用 replace 替换 insert 语句，用 delete + replace 替换 update 语句
- safe-mode = false
-
- # Drainer 下游服务类型（默认为 mysql）
- # 参数有效值为 "mysql"，"tidb"，"file"，"kafka"
- db-type = "mysql"
-
- # 事务的 commit ts 若在该列表中，则该事务将被过滤，不会同步至下游
- ignore-txn-commit-ts = []
-
- # db 过滤列表 (默认 "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql,test")，
- # 不支持对 ignore schemas 的 table 进行 rename DDL 操作
- ignore-schemas = "INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql"
-
- # replicate-do-db 配置的优先级高于 replicate-do-table。如果配置了相同的库名，支持使用正则表达式进行配置。
- # 以 '~' 开始声明使用正则表达式
-
- # replicate-do-db = ["~^b.*","s1"]
-
- # [syncer.relay]
- # 保存 relay log 的目录，空值表示不开启。
- # 只有下游是 TiDB 或 MySQL 时该配置才生效。
- # log-dir = ""
- # 每个文件的大小上限
- # max-file-size = 10485760
-
- # [[syncer.replicate-do-table]]
- # db-name ="test"
- # tbl-name = "log"
-
- # [[syncer.replicate-do-table]]
- # db-name ="test"
- # tbl-name = "~^a.*"
-
- # 忽略同步某些表
- # [[syncer.ignore-table]]
- # db-name = "test"
- # tbl-name = "log"
-
- # db-type 设置为 mysql 时，下游数据库服务器参数
- [syncer.to]
- host = "192.168.0.13"
- user = "root"
- # 如果你不想在配置文件中写明文密码，则可以使用 `./binlogctl -cmd encrypt -text string` 生成加密的密码
- # 如果配置了 encrypted_password 且非空，那么配置的 password 不生效。encrypted_password 和 password 无法同时生效。
- password = ""
- encrypted_password = ""
- port = 3306
-
- [syncer.to.checkpoint]
- # 当 checkpoint type 是 mysql 或 tidb 时可以开启该选项，以改变保存 checkpoint 的数据库
- # schema = "tidb_binlog"
- # 目前只支持 mysql 或者 tidb 类型。可以去掉注释来控制 checkpoint 保存的位置。
- # db-type 默认的 checkpoint 保存方式是:
- # mysql/tidb -> 对应的下游 mysql/tidb
- # file/kafka -> file in `data-dir`
- # type = "mysql"
- # host = "127.0.0.1"
- # user = "root"
- # password = ""
- # 使用 `./binlogctl -cmd encrypt -text string` 加密的密码
- # encrypted_password 非空时 password 会被忽略
- # encrypted_password = ""
- # port = 3306
-
- # db-type 设置为 file 时，存放 binlog 文件的目录
- # [syncer.to]
- # dir = "data.drainer"
-
- # db-type 设置为 kafka 时，Kafka 相关配置
- # [syncer.to]
- # kafka-addrs 和 zookeeper-addrs 只需要一个，两者都有时程序会优先用 zookeeper 中的 kafka 地址
- # zookeeper-addrs = "127.0.0.1:2181"
- # kafka-addrs = "127.0.0.1:9092"
- # kafka-version = "0.8.2.0"
- # 配置单条 broker request 中的最大 message 数（即 binlog 数），不配置或配置小于等于 0 时会使用默认值 1024
- # kafka-max-messages = 1024
- # 配置单条 broker request 的最大 size（单位为 Byte），默认为 1 GiB，最大可配置为 2 GiB
- # kafka-max-message-size = 1073741824
-
- # 保存 binlog 数据的 Kafka 集群的 topic 名称，默认值为 _obinlog
- # 如果运行多个 Drainer 同步数据到同一个 Kafka 集群，每个 Drainer 的 topic-name 需要设置不同的名称
- # topic-name = ""
- ```
-
- - 启动示例
-
- > **注意：**
- >
- > 如果下游为 MySQL/TiDB，为了保证数据的完整性，在 Drainer 初次启动前需要获取 `initial-commit-ts` 的值，并进行全量数据的备份与恢复。
-
- 初次启动时使用参数 `initial-commit-ts`，命令如下：
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- ./drainer -config drainer.toml -initial-commit-ts {initial-commit-ts}
- ```
-
- 如果命令行参数与配置文件中的参数重合，则使用命令行设置的参数的值。
-
-> **注意：**
->
-> - 在运行 TiDB 时，需要保证至少一个 Pump 正常运行。
-> - 通过给 TiDB 增加启动参数 `enable-binlog` 来开启 binlog 服务。尽量保证同一集群的所有 TiDB 都开启了 binlog 服务，否则在同步数据时可能会导致上下游数据不一致。如果要临时运行一个不开启 binlog 服务的 TiDB 实例，需要在 TiDB 的配置文件中设置 `run_ddl= false`。
-> - Drainer 不支持对 ignore schemas（在过滤列表中的 schemas）的 table 进行 rename DDL 操作。
-> - 在已有的 TiDB 集群中启动 Drainer，一般需要全量备份并且获取**快照时间戳**，然后导入全量备份，最后启动 Drainer 从对应的快照时间戳开始同步增量数据。
-> - 下游使用 MySQL 或 TiDB 时应当保证上下游数据库的 sql_mode 具有一致性，即下游数据库同步每条 SQL 语句时的 sql_mode 应当与上游数据库执行该条 SQL 语句时的 sql_mode 保持一致。可以在上下游分别执行 `select @@sql_mode;` 进行查询和比对。
-> - 如果存在上游 TiDB 能运行但下游 MySQL 不支持的 DDL 语句时（例如下游 MySQL 使用 InnoDB 引擎时同步语句 `CREATE TABLE t1(a INT) ROW_FORMAT=FIXED;`），Drainer 也会同步失败，此时可以在 Drainer 配置中跳过该事务，同时在下游手动执行兼容的语句，详见[跳过事务](/tidb-binlog/tidb-binlog-faq.md#同步时出现上游数据库支持但是下游数据库执行会出错的-ddl应该怎么办)。
diff --git a/tidb-binlog/get-started-with-tidb-binlog.md b/tidb-binlog/get-started-with-tidb-binlog.md
deleted file mode 100644
index da7d3f4263c1..000000000000
--- a/tidb-binlog/get-started-with-tidb-binlog.md
+++ /dev/null
@@ -1,521 +0,0 @@
----
-title: TiDB Binlog 教程
-aliases: ['/docs-cn/dev/tidb-binlog/get-started-with-tidb-binlog/','/docs-cn/dev/how-to/get-started/tidb-binlog/','/docs-cn/dev/get-started-with-tidb-binlog/']
-summary: TiDB Binlog 是用于将数据从 TiDB 推送到 MariaDB 实例的工具。它包含 Pump 和 Drainer 两个组件，用于实时数据备份和同步。用户需要对 TiDB 架构有一定了解，并在现代 Linux 发行版本中的 x86-64上使用。安装和配置过程需要按照指导进行，以确保成功启动各个组件。使用 binlogctl 可以查询和修改集群中 Pump 和 Drainer 的状态信息。
----
-
-# TiDB Binlog 教程
-
-本文档主要介绍如何使用 [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md)（已废弃）将数据从 TiDB 推送到 MariaDB 实例。文中的 TiDB Binlog 集群包含 Pump 和 Drainer 的单个节点，TiDB 集群包含 TiDB、TiKV 和 Placement Driver (PD) 各组件的单个节点。
-
-希望上手实践 TiDB Binlog 工具的用户需要对 [TiDB 架构](/tidb-architecture.md)有一定的了解，最好有创建过 TiDB 集群的经验。该文档也有助于简单快速了解 TiDB Binlog 架构以及相关概念。
-
-> **警告：**
->
-> 该文档中部署 TiDB 的操作指导**不适用于**在生产或研发环境中部署 TiDB 的情况。
-
-该文档假设用户使用的是现代 Linux 发行版本中的 x86-64。示例中使用的是 VMware 中运行的 CentOS 7 最小化安装。建议在一开始就进行清洁安装，以避免受现有环境中未知情况的影响。如果不想使用本地虚拟环境，也可以使用云服务启动 CentOS 7 VM。
-
-## TiDB Binlog 简介
-
-TiDB Binlog 用于收集 TiDB 中二进制日志数据、提供实时数据备份和同步以及将 TiDB 集群的数据增量同步到下游。
-
-TiDB Binlog 支持以下功能场景：
-
-- 增量备份，将 TiDB 集群中的数据增量同步到另一个集群，或通过 Kafka 增量同步到选择的下游。
-- 当使用 TiDB DM (Data Migration) 将数据从上游 MySQL 或者 MariaDB 迁移到 TiDB 集群时，可使用 TiDB Binlog 保持 TiDB 集群与其一个独立下游 MySQL 或 MariaDB 实例或集群同步。当 TiDB 集群上游数据迁移过程中出现问题，下游数据同步过程中可使用 TiDB Binlog 恢复数据到原先的状态。
-
-更多信息参考 [TiDB Binlog Cluster 版本用户文档](/tidb-binlog/tidb-binlog-overview.md)。
-
-## 架构
-
-TiDB Binlog 集群由 **Pump** 和 **Drainer** 两个组件组成。一个 Pump 集群中有若干个 Pump 节点。TiDB 实例连接到各个 Pump 节点并发送 binlog 数据到 Pump 节点。Pump 集群连接到 Drainer 节点，Drainer 将接收到的更新数据转换到某个特定下游（例如 Kafka、另一个 TiDB 集群或 MySQL 或 MariaDB Server）指定的正确格式。
-
-
-
-Pump 的集群架构能确保 TiDB 或 Pump 集群中有新的实例加入或退出时更新数据不会丢失。
-
-## 安装
-
-由于 RHEL/CentOS 7 的默认包装库中包括 MariaDB Server，本示例选择的是 MariaDB Server。后续除了安装服务器，也需要安装客户端。安装指令如下：
-
-{{< copyable "shell-regular" >}}
-
-```bash
-sudo yum install -y mariadb-server
-```
-
-{{< copyable "shell-regular" >}}
-
-```bash
-curl -LO https://download.pingcap.org/tidb-community-server-v8.3.0-linux-amd64.tar.gz | tar xzf - &&
-cd tidb-latest-linux-amd64
-```
-
-预期输出：
-
-```
- % Total % Received % Xferd Average Speed Time Time Time Current
- Dload Upload Total Spent Left Speed
-100 368M 100 368M 0 0 8394k 0 0:00:44 0:00:44 --:--:-- 11.1M
-```
-
-## 配置
-
-通过执行以下步骤配置一个 TiDB 集群，该集群包括 `pd-server`、`tikv-server` 和 `tidb-server` 各组件的单个实例。
-
-1. 填充配置文件：
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- printf > pd.toml %s\\n 'log-file="pd.log"' 'data-dir="pd.data"' &&
- printf > tikv.toml %s\\n 'log-file="tikv.log"' '[storage]' 'data-dir="tikv.data"' '[pd]' 'endpoints=["127.0.0.1:2379"]' '[rocksdb]' max-open-files=1024 '[raftdb]' max-open-files=1024 &&
- printf > pump.toml %s\\n 'log-file="pump.log"' 'data-dir="pump.data"' 'addr="127.0.0.1:8250"' 'advertise-addr="127.0.0.1:8250"' 'pd-urls="http://127.0.0.1:2379"' &&
- printf > tidb.toml %s\\n 'store="tikv"' 'path="127.0.0.1:2379"' '[log.file]' 'filename="tidb.log"' '[binlog]' 'enable=true' &&
- printf > drainer.toml %s\\n 'log-file="drainer.log"' '[syncer]' 'db-type="mysql"' '[syncer.to]' 'host="127.0.0.1"' 'user="root"' 'password=""' 'port=3306'
- ```
-
-2. 查看配置细节：
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- for f in *.toml; do echo "$f:"; cat "$f"; echo; done
- ```
-
- 预期输出：
-
- ```
- drainer.toml:
- log-file="drainer.log"
- [syncer]
- db-type="mysql"
- [syncer.to]
- host="127.0.0.1"
- user="root"
- password=""
- port=3306
-
- pd.toml:
- log-file="pd.log"
- data-dir="pd.data"
-
- pump.toml:
- log-file="pump.log"
- data-dir="pump.data"
- addr="127.0.0.1:8250"
- advertise-addr="127.0.0.1:8250"
- pd-urls="http://127.0.0.1:2379"
-
- tidb.toml:
- store="tikv"
- path="127.0.0.1:2379"
- [log.file]
- filename="tidb.log"
- [binlog]
- enable=true
-
- tikv.toml:
- log-file="tikv.log"
- [storage]
- data-dir="tikv.data"
- [pd]
- endpoints=["127.0.0.1:2379"]
- [rocksdb]
- max-open-files=1024
- [raftdb]
- max-open-files=1024
- ```
-
-## 启动程序
-
-现在可启动各个组件。推荐启动顺序依次为 Placement Driver (PD)、TiKV、Pump（TiDB 发送 binlog 日志必须连接 Pump 服务）、TiDB。
-
-1. 启动所有服务：
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- ./bin/pd-server --config=pd.toml &>pd.out &
- ```
-
- ```
- [1] 20935
- ```
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- ./bin/tikv-server --config=tikv.toml &>tikv.out &
- ```
-
- ```
- [2] 20944
- ```
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- ./pump --config=pump.toml &>pump.out &
- ```
-
- ```
- [3] 21050
- ```
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- sleep 3 &&
- ./bin/tidb-server --config=tidb.toml &>tidb.out &
- ```
-
- ```
- [4] 21058
- ```
-
-2. 如果执行 `jobs`，可以看到后台正在运行的程序，列表如下：
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- jobs
- ```
-
- ```
- [1] Running ./bin/pd-server --config=pd.toml &>pd.out &
- [2] Running ./bin/tikv-server --config=tikv.toml &>tikv.out &
- [3]- Running ./pump --config=pump.toml &>pump.out &
- [4]+ Running ./bin/tidb-server --config=tidb.toml &>tidb.out &
- ```
-
- 如果有服务启动失败（例如出现 “`Exit 1`” 而不是 “`Running`”），尝试重启单个组件。
-
-## 连接
-
-按以上步骤操作后，TiDB 的 4 个组件开始运行。接下来可以使用以下 MariaDB 或 MySQL 命令行客户端，通过 4000 端口连接到 TiDB 服务：
-
-{{< copyable "shell-regular" >}}
-
-```bash
-mysql -h 127.0.0.1 -P 4000 -u root -e 'select tidb_version();'
-```
-
-预期输出：
-
-```
-*************************** 1. row ***************************
-tidb_version(): Release Version: v3.0.0-beta.1-154-gd5afff70c
-Git Commit Hash: d5afff70cdd825d5fab125c8e52e686cc5fb9a6e
-Git Branch: master
-UTC Build Time: 2019-04-24 03:10:00
-GoVersion: go version go1.12 linux/amd64
-Race Enabled: false
-TiKV Min Version: 2.1.0-alpha.1-ff3dd160846b7d1aed9079c389fc188f7f5ea13e
-Check Table Before Drop: false
-```
-
-连接后 TiDB 集群已开始运行，`pump` 读取集群中的 binlog 数据，并在其数据目录中将 binlog 数据存储为 relay log。下一步是启动一个可供 `drainer` 写入的 MariaDB Server。
-
-1. 启动 `drainer`：
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- sudo systemctl start mariadb &&
- ./drainer --config=drainer.toml &>drainer.out &
- ```
-
- 如果你的操作系统更易于安装 MySQL，只需保证监听 3306 端口。另外，可使用密码为空的 "root" 用户连接到 MySQL，或调整 `drainer.toml` 连接到 MySQL。
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- mysql -h 127.0.0.1 -P 3306 -u root
- ```
-
- 预期输出：
-
- ```
- Welcome to the MariaDB monitor. Commands end with ; or \g.
- Your MariaDB connection id is 20
- Server version: 5.5.60-MariaDB MariaDB Server
-
- Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
-
- Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
-
- MariaDB [(none)]>
- ```
-
- {{< copyable "sql" >}}
-
- ```sql
- show databases;
- ```
-
- 预期输出：
-
- ```
- +--------------------+
- | Database |
- +--------------------+
- | information_schema |
- | mysql |
- | performance_schema |
- | test |
- | tidb_binlog |
- +--------------------+
- 5 rows in set (0.01 sec)
- ```
-
- 如下表格是包含 `checkpoint` 表格的 `tidb_binlog` 数据库。`drainer` 使用 `checkpoint` 表格，记录 TiDB 集群中的 binlog 已经更新到了哪个位置。
-
- {{< copyable "sql" >}}
-
- ```sql
- use tidb_binlog;
- ```
-
- ```
- Database changed
- ```
-
- {{< copyable "sql" >}}
-
- ```sql
- select * from checkpoint;
- ```
-
- ```
- +---------------------+---------------------------------------------+
- | clusterID | checkPoint |
- +---------------------+---------------------------------------------+
- | 6678715361817107733 | {"commitTS":407637466476445697,"ts-map":{}} |
- +---------------------+---------------------------------------------+
- 1 row in set (0.00 sec)
- ```
-
- 打开另一个连接到 TiDB 的客户端，创建一个表格并插入几行数据。建议在 GNU Screen 软件中操作，从而同时打开多个客户端。
-
- {{< copyable "shell-regular" >}}
-
- ```bash
- mysql -h 127.0.0.1 -P 4000 --prompt='TiDB [\d]> ' -u root
- ```
-
- {{< copyable "sql" >}}
-
- ```sql
- create database tidbtest;
- ```
-
- ```
- Query OK, 0 rows affected (0.12 sec)
- ```
-
- {{< copyable "sql" >}}
-
- ```sql
- use tidbtest;
- ```
-
- ```
- Database changed
- ```
-
- {{< copyable "sql" >}}
-
- ```sql
- create table t1 (id int unsigned not null AUTO_INCREMENT primary key);
- ```
-
- ```
- Query OK, 0 rows affected (0.11 sec)
- ```
-
- {{< copyable "sql" >}}
-
- ```sql
- insert into t1 () values (),(),(),(),();
- ```
-
- ```
- Query OK, 5 rows affected (0.01 sec)
- Records: 5 Duplicates: 0 Warnings: 0
- ```
-
- {{< copyable "sql" >}}
-
- ```sql
- select * from t1;
- ```
-
- ```
- +----+
- | id |
- +----+
- | 1 |
- | 2 |
- | 3 |
- | 4 |
- | 5 |
- +----+
- 5 rows in set (0.00 sec)
- ```
-
- 切换回 MariaDB 客户端可看到新的数据库、新的表格和最近插入的行数据。
-
- {{< copyable "sql" >}}
-
- ```sql
- use tidbtest;
- ```
-
- ```
- Reading table information for completion of table and column names
- You can turn off this feature to get a quicker startup with -A
-
- Database changed
- ```
-
- {{< copyable "sql" >}}
-
- ```sql
- show tables;
- ```
-
- ```
- +--------------------+
- | Tables_in_tidbtest |
- +--------------------+
- | t1 |
- +--------------------+
- 1 row in set (0.00 sec)
- ```
-
- {{< copyable "sql" >}}
-
- ```sql
- select * from t1;
- ```
-
- ```
- +----+
- | id |
- +----+
- | 1 |
- | 2 |
- | 3 |
- | 4 |
- | 5 |
- +----+
- 5 rows in set (0.00 sec)
- ```
-
- 可看到查询 MariaDB 时插入到 TiDB 相同的行数据，表明 TiDB Binlog 安装成功。
-
-## binlogctl
-
-加入到集群的 Pump 和 Drainer 的数据存储在 Placement Driver (PD) 中。binlogctl 可用于查询和修改状态信息。更多信息请参考 [binlogctl guide](/tidb-binlog/binlog-control.md)。
-
-使用 `binlogctl` 查看集群中 Pump 和 Drainer 的当前状态：
-
-{{< copyable "shell-regular" >}}
-
-```bash
-./binlogctl -cmd drainers
-```
-
-```
-[2019/04/11 17:44:10.861 -04:00] [INFO] [nodes.go:47] ["query node"] [type=drainer] [node="{NodeID: localhost.localdomain:8249, Addr: 192.168.236.128:8249, State: online, MaxCommitTS: 407638907719778305, UpdateTime: 2019-04-11 17:44:10 -0400 EDT}"]
-```
-
-{{< copyable "shell-regular" >}}
-
-```bash
-./binlogctl -cmd pumps
-```
-
-```
-[2019/04/11 17:44:13.904 -04:00] [INFO] [nodes.go:47] ["query node"] [type=pump] [node="{NodeID: localhost.localdomain:8250, Addr: 192.168.236.128:8250, State: online, MaxCommitTS: 407638914024079361, UpdateTime: 2019-04-11 17:44:13 -0400 EDT}"]
-```
-
-如果结束 Drainer 进程，集群会改进程设置“已暂停（即集群等待 Drainer 重新加入）”的状态。
-
-{{< copyable "shell-regular" >}}
-
-```bash
-pkill drainer &&
-./binlogctl -cmd drainers
-```
-
-预期输出：
-
-```
-[2019/04/11 17:44:22.640 -04:00] [INFO] [nodes.go:47] ["query node"] [type=drainer] [node="{NodeID: localhost.localdomain:8249, Addr: 192.168.236.128:8249, State: paused, MaxCommitTS: 407638915597467649, UpdateTime: 2019-04-11 17:44:18 -0400 EDT}"]
-```
-
-使用 binlogctl 的 "NodeIDs" 可控制单个对应节点。在该情况下，Drainer 的节点 ID 是 "localhost.localdomain:8249"，Pump 的节点 ID 是 "localhost.localdomain:8250"。
-
-本文档中的 binlogctl 主要用于集群重启。如果在 TiDB 集群中终止并尝试重启所有的进程，由于 Pump 无法连接 Drainer 且认为 Drainer 依旧“在线”，Pump 会拒绝启动。这里的进程并不包括下游的 MySQL 或 MariaDB 或 Drainer。
-
-以下有三个方案可解决上述问题：
-
-- 使用 binlogctl 停止 Drainer，而不是结束进程：
-
- ```bash
- ./binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=drainers &&
- ./binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=pause-drainer --node-id=localhost.localdomain:8249
- ```
-
-- 在启动 Pump **之前**先启动 Drainer。
-
-- 在启动 PD 之后但在启动 Drainer 和 Pump 之前，使用 binlogctl 更新已暂定 Drainer 的状态。
-
- ```bash
- ./binlogctl --pd-urls=http://127.0.0.1:2379 --cmd=update-drainer --node-id=localhost.localdomain:8249 --state=paused
- ```
-
-## 清理
-
-在 shell 终端里可启动创建集群的所有进程（`pd-server` 、`tikv-server`、`pump`、`tidb-server`、`drainer`）。可通过在 shell 终端中执行 `pkill -P $$` 停止 TiDB 集群服务和 TiDB Binlog 进程。按一定的顺序停止这些进程有利于留出足够的时间彻底关闭每个组件。
-
-{{< copyable "shell-regular" >}}
-
-```bash
-for p in tidb-server drainer pump tikv-server pd-server; do pkill "$p"; sleep 1; done
-```
-
-预期输出：
-
-```
-[4]- Done ./bin/tidb-server --config=tidb.toml &>tidb.out
-[5]+ Done ./drainer --config=drainer.toml &>drainer.out
-[3]+ Done ./pump --config=pump.toml &>pump.out
-[2]+ Done ./bin/tikv-server --config=tikv.toml &>tikv.out
-[1]+ Done ./bin/pd-server --config=pd.toml &>pd.out
-```
-
-如果需要所有服务退出后重启集群，可以使用一开始启动服务的命令。如以上 [`binlogctl`](#binlogctl) 部分所述，需要先启动 Drainer 再启动 Pump，最后启动 `tidb-server`。
-
-{{< copyable "shell-regular" >}}
-
-```bash
-./bin/pd-server --config=pd.toml &>pd.out &
-./bin/tikv-server --config=tikv.toml &>tikv.out &
-./drainer --config=drainer.toml &>drainer.out &
-sleep 3
-./pump --config=pump.toml &>pump.out &
-sleep 3
-./bin/tidb-server --config=tidb.toml &>tidb.out &
-```
-
-如果有组件启动失败，请尝试单独重启该组件。
-
-## 总结
-
-本文档介绍了如何通过设置 TiDB Binlog，使用单个 Pump 和 Drainer 组成的集群同步 TiDB 集群数据到下游的 MariaDB。可以发现，TiDB Binlog 是用于获取处理 TiDB 集群中更新数据的综合性平台工具。
-
-在更稳健的开发、测试或生产部署环境中，可以使用多个 TiDB 服务以实现高可用性和扩展性。使用多个 Pump 实例可以避免 Pump 集群中的问题影响发送到 TiDB 实例的应用流量。或者可以使用增加的 Drainer 实例同步数据到不同的下游或实现数据增量备份。
diff --git a/tidb-binlog/handle-tidb-binlog-errors.md b/tidb-binlog/handle-tidb-binlog-errors.md
deleted file mode 100644
index f43c64e1d34a..000000000000
--- a/tidb-binlog/handle-tidb-binlog-errors.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-title: TiDB Binlog 常见错误修复
-aliases: ['/docs-cn/dev/tidb-binlog/handle-tidb-binlog-errors/','/docs-cn/dev/reference/tidb-binlog/troubleshoot/error-handling/']
-summary: TiDB Binlog 常见错误修复：介绍了 Drainer 同步数据到 Kafka 时报错的解决方法，Pump 报错 "no space left on device" 的原因和解决方法，以及 Drainer 输出 file 格式的增量数据的清理机制。需要确认 TiDB 实例是否开启了 TiDB Binlog 并且状态正常，以及调整 Pump 的 gRPC message 最大大小。
----
-
-# TiDB Binlog 常见错误修复
-
-本文档介绍 TiDB Binlog 中常见的错误以及修复方法。
-
-## Drainer 同步数据到 Kafka 时报错 "kafka server: Message was too large, server rejected it to avoid allocation error"
-
-报错原因：如果在 TiDB 中执行了大事务，则生成的 binlog 数据会比较大，可能超过了 Kafka 的消息大小限制。
-
-解决方法：需要调整 Kafka 的配置参数，如下所示。
-
-```
-message.max.bytes=1073741824
-replica.fetch.max.bytes=1073741824
-fetch.message.max.bytes=1073741824
-```
-
-## Pump 报错 "no space left on device"
-
-报错原因：本地磁盘空间不足，Pump 无法正常写 binlog 数据。
-
-解决方法：需要清理磁盘空间，然后重启 Pump。
-
-## Pump 启动时报错 "fail to notify all living drainer"
-
-报错原因：Pump 启动时需要通知所有 Online 状态的 Drainer，如果通知失败则会打印该错误日志。
-
-解决方法：可以使用 [binlogctl 工具](/tidb-binlog/binlog-control.md)查看所有 Drainer 的状态是否有异常，保证 Online 状态的 Drainer 都在正常工作。如果某个 Drainer 的状态和实际运行情况不一致，则使用 binlogctl 修改状态，然后再重启 Pump。
-
-## TiDB Binlog 同步中发现数据丢失
-
-需要确认所有 TiDB 实例均开启了 TiDB Binlog，并且运行状态正常。如果集群版本大于 v3.0，可以使用 `curl {TiDB_IP}:{STATUS_PORT}/info/all` 命令确认所有 TiDB 实例上的 TiDB Binlog 状态。
-
-## 当上游事务较大时，Pump 报错 `rpc error: code = ResourceExhausted desc = trying to send message larger than max (2191430008 vs. 2147483647)`
-
-出现该错误的原因是 TiDB 发送给 Pump 的 gRPC message 超过限值。可以在启动 Pump 时通过指定 `max-message-size` 来调整 Pump 可接受 gRPC message 的最大大小。
-
-## Drainer 输出 file 格式的增量数据，数据有什么清理机制吗？数据会被删除吗？
-
-+ 在 v3.0.x 版本的 Drainer 中，file 格式的增量数据没有任何清理机制。
-+ 在 v4.0.x 版本中，有基于时间的数据清理机制，详见 [Drainer 的 `retention-time` 配置项](https://github.com/pingcap/tidb-binlog/blob/v4.0.9/cmd/drainer/drainer.toml#L153)。
diff --git a/tidb-binlog/maintain-tidb-binlog-cluster.md b/tidb-binlog/maintain-tidb-binlog-cluster.md
deleted file mode 100644
index 056308b70eda..000000000000
--- a/tidb-binlog/maintain-tidb-binlog-cluster.md
+++ /dev/null
@@ -1,134 +0,0 @@
----
-title: TiDB Binlog 集群运维
-aliases: ['/docs-cn/dev/tidb-binlog/maintain-tidb-binlog-cluster/','/docs-cn/dev/reference/tidb-binlog/maintain/','/docs-cn/dev/how-to/maintain/tidb-binlog/','/docs-cn/dev/reference/tools/tidb-binlog/maintain/']
-summary: TiDB Binlog 集群运维包括了 Pump 和 Drainer 的状态管理和启动、退出流程。通过 binlogctl 工具或 TiDB SQL 操作可以管理集群状态。具体操作方法请参考 binlogctl 工具的使用方法介绍。
----
-
-# TiDB Binlog 集群运维
-
-本文首先介绍 Pump 和 Drainer 的状态及启动、退出的内部处理流程，然后说明如何通过 binlogctl 工具或者直接在 TiDB 执行 SQL 操作来管理 binlog 集群，最后的 FAQ 部分会介绍一些常见问题以及处理方法。
-
-## Pump/Drainer 的状态
-
-Pump/Drainer 中状态的定义：
-
-* online：正常运行中
-* pausing：暂停中
-* paused：已暂停
-* closing：下线中
-* offline：已下线
-
-这些状态由 Pump/Drainer 服务自身进行维护，并定时将状态信息更新到 PD 中。
-
-## Pump/Drainer 的启动、退出流程
-
-### Pump
-
-* 启动：Pump 启动时会通知所有 online 状态的 Drainer，如果通知成功，则 Pump 将状态设置为 online，否则 Pump 将报错，然后将状态设置为 paused 并退出进程。
-* 退出：Pump 进程正常退出前要选择进入暂停或者下线状态；非正常退出（kill -9、进程 panic、宕机）都依然保持 online 状态。
-
- * 暂停：使用 kill（非 kill -9）、Ctrl+C 或者使用 binlogctl 的 pause-pump 命令都可以暂停 Pump。接收到暂停指令后，Pump 会变更状态为 pausing，并停止接受 binlog 的写请求，也停止向 Drainer 提供 binlog 数据。安全退出所有线程后，更新状态为 paused 然后退出进程。
- * 下线：仅在使用 binlogctl 的 offline-pump 命令的情况下才会下线 Pump。接收到下线指令后，Pump 会变更状态为 closing，并停止接受 binlog 的写请求。Pump 继续向 Drainer 提供 binlog，等待所有 binlog 数据都被 Drainer 消费后再将状态设置为 offline 并退出进程。
-
-### Drainer
-
-* 启动：Drainer 启动时将状态设置为 online，并尝试从所有非 offline 状态的 Pump 获取 binlog，如果获取 binlog 失败，会不断尝试重新获取。
-* 退出：Drainer 进程正常退出前要选择进入暂停或者下线状态；非正常退出（kill -9 、进程 panic、宕机）都依然保持 online 状态。
-
- * 暂停：使用 kill（非 kill -9）、Ctrl+C 或者使用 binlogctl 的 pause-drainer 命令都可以暂停 Drainer。接收到指令后，Drainer 会变更状态为 pausing，并停止从 Pump 获取 binlog。安全退出所有线程后，更新状态为 paused 然后退出进程。
- * 下线：仅在使用 binlogctl 的 offline-drainer 命令的情况下才会下线 Drainer。接收到下线指令后，Drainer 变更状态为 closing，并停止从 Pump 获取 binlog。安全退出所有线程后，更新状态为 offline 然后退出进程。
-
-关于 Pump/Drainer 暂停、下线、状态查询、状态修改等具体的操作方法，参考如下 binlogctl 工具的使用方法介绍。
-
-## 使用 binlogctl 工具管理 Pump/Drainer
-
-binlogctl 支持如下这些功能：
-
-* 查看 Pump/Drainer 状态
-* 暂停/下线 Pump/Drainer
-* Pump/Drainer 异常状态处理
-
-详细的介绍和使用方法请参考 [binlogctl 工具](/tidb-binlog/binlog-control.md)。
-
-## 使用 TiDB SQL 管理 Pump/Drainer
-
-要查看和管理 binlog 相关的状态，可在 TiDB 中执行相应的 SQL 语句。
-
-- 查看 TiDB 是否开启 binlog，0 代表关闭，1 代表开启
-
- {{< copyable "sql" >}}
-
- ```sql
- show variables like "log_bin";
- ```
-
- ```
- +---------------+-------+
- | Variable_name | Value |
- +---------------+-------+
- | log_bin | 0 |
- +---------------+-------+
- ```
-
-- 查看 Pump/Drainer 状态
-
- {{< copyable "sql" >}}
-
- ```sql
- show pump status;
- ```
-
- ```
- +--------|----------------|--------|--------------------|---------------------|
- | NodeID | Address | State | Max_Commit_Ts | Update_Time |
- +--------|----------------|--------|--------------------|---------------------|
- | pump1 | 127.0.0.1:8250 | Online | 408553768673342237 | 2019-05-01 00:00:01 |
- +--------|----------------|--------|--------------------|---------------------|
- | pump2 | 127.0.0.2:8250 | Online | 408553768673342335 | 2019-05-01 00:00:02 |
- +--------|----------------|--------|--------------------|---------------------|
- ```
-
- {{< copyable "sql" >}}
-
- ```sql
- show drainer status;
- ```
-
- ```
- +----------|----------------|--------|--------------------|---------------------|
- | NodeID | Address | State | Max_Commit_Ts | Update_Time |
- +----------|----------------|--------|--------------------|---------------------|
- | drainer1 | 127.0.0.3:8249 | Online | 408553768673342532 | 2019-05-01 00:00:03 |
- +----------|----------------|--------|--------------------|---------------------|
- | drainer2 | 127.0.0.4:8249 | Online | 408553768673345531 | 2019-05-01 00:00:04 |
- +----------|----------------|--------|--------------------|---------------------|
- ```
-
-- 异常情况下修改 Pump/Drainer 状态
-
- {{< copyable "sql" >}}
-
- ```sql
- change pump to node_state ='paused' for node_id 'pump1';
- ```
-
- ```
- Query OK, 0 rows affected (0.01 sec)
- ```
-
- {{< copyable "sql" >}}
-
- ```sql
- change drainer to node_state ='paused' for node_id 'drainer1';
- ```
-
- ```
- Query OK, 0 rows affected (0.01 sec)
- ```
-
- 该 SQL 的功能和 binlogctl 中的 update-pump 和 update-drainer 命令的功能一样，因此也只有在 Pump/Drainer 异常的情况下使用。
-
-> **注意：**
->
-> 1. 查看 binlog 开启状态以及 Pump/Drainer 状态的功能在 TiDB v2.1.7 及以上版本中支持。
-> 2. 修改 Pump/Drainer 状态的功能在 TiDB v3.0.0-rc.1 及以上版本中支持。该功能只修改 PD 中存储的 Pump/Drainer 状态，如果需要暂停/下线节点，仍然需要使用 `binlogctl`。
diff --git a/tidb-binlog/monitor-tidb-binlog-cluster.md b/tidb-binlog/monitor-tidb-binlog-cluster.md
deleted file mode 100644
index 3164e5b07e5f..000000000000
--- a/tidb-binlog/monitor-tidb-binlog-cluster.md
+++ /dev/null
@@ -1,165 +0,0 @@
----
-title: TiDB Binlog 集群监控
-aliases: ['/docs-cn/dev/tidb-binlog/monitor-tidb-binlog-cluster/','/docs-cn/dev/reference/tidb-binlog/monitor/','/docs-cn/dev/how-to/monitor/tidb-binlog-monitor/','/docs-cn/dev/reference/tools/tidb-binlog/monitor/','/docs-cn/dev/how-to/monitor/tidb-binlog/']
-summary: TiDB Binlog 集群监控包括 Pump 和 Drainer 的监控指标，以及紧急、重要和警告级别的监控报警规则。监控指标包括 Pump 的存储大小、写 Binlog QPS、写 Binlog 延迟等，以及 Drainer 的同步延迟、处理 SQL 耗时等。报警规则包括紧急级别的 Pump 存储错误、重要级别的 Drainer 同步延迟超过1小时、警告级别的 Pump 写 Binlog 耗时过大等。
----
-
-# TiDB Binlog 集群监控
-
-成功部署 TiDB Binlog 集群后，可以进入 Grafana Web 界面（默认地址: ，默认账号：admin，密码：admin）查看 Pump 和 Drainer 的运行状态。
-
-## 监控指标
-
-### Pump
-
-| metric 名称 | 说明 |
-|:----|:------------|
-| Storage Size | 记录磁盘的总空间大小 (capacity)，以及可用磁盘空间大小 (available) |
-| Metadata | 记录每个 Pump 的可删除 binlog 的最大 tso (gc_tso)，以及保存的 binlog 的最大的 commit tso (max_commit_tso)。 |
-| Write Binlog QPS by Instance | 每个 Pump 接收到的写 binlog 请求的 QPS |
-| Write Binlog Latency | 记录每个 Pump 写 binlog 的延迟时间 |
-| Storage Write Binlog Size | Pump 写 binlog 数据的大小 |
-| Storage Write Binlog Latency | Pump 中的 storage 模块写 binlog 数据的延迟 |
-| Pump Storage Error By Type | Pump 遇到的 error 数量，按照 error 的类型进行统计 |
-| Query TiKV | Pump 通过 TiKV 查询事务状态的次数 |
-
-### Drainer
-
-| metric 名称 | 说明 |
-|:----|:------------|
-| Checkpoint TSO | Drainer 已经同步到下游的 binlog 的最大 TSO 对应的时间。可以通过该指标估算同步延迟时间 |
-| Pump Handle TSO | 记录 Drainer 从各个 Pump 获取到的 binlog 的最大 TSO 对应的时间 |
-| Pull Binlog QPS by Pump NodeID | Drainer 从每个 Pump 获取 binlog 的 QPS |
-| 95% Binlog Reach Duration By Pump | 记录 binlog 从写入 Pump 到被 Drainer 获取到这个过程的延迟时间 |
-| Error By Type | Drainer 遇到的 error 数量，按照 error 的类型进行统计 |
-| SQL Query Time| Drainer 在下游执行 SQL 的耗时 |
-| Drainer Event | 各种类型 event 的数量，event 包括 ddl、insert、delete、update、flush、savepoint |
-| Execute Time | 写入 binlog 到同步下游模块所消耗的时间 |
-| 95% Binlog Size | Drainer 从各个 Pump 获取到 binlog 数据的大小 |
-| DDL Job Count | Drainer 处理的 DDL 的数量|
-| Queue Size | Drainer 内部工作队列大小 |
-
-## 监控报警规则
-
-本节介绍了 TiDB Binlog 组件的报警项及相应的报警规则。根据严重级别，报警项可分为三类，按照严重程度由高到低依次为：紧急级别 (Emergency)、重要级别 (Critical)、警告级别 (Warning)。
-
-### 紧急级别报警项
-
-紧急级别的报警通常由于服务停止或节点故障导致，此时需要马上进行人工干预操作。
-
-#### `binlog_pump_storage_error_count`
-
-* 报警规则：
-
- `changes(binlog_pump_storage_error_count[1m]) > 0`
-
-* 规则描述：
-
- Pump 写 binlog 到本地存储时失败。
-
-* 处理方法：
-
- 确认 `pump_storage_error` 监控是否存在错误，查看 Pump 日志确认原因。
-
-### 重要级别报警项
-
-对于重要级别的报警，需要密切关注异常指标。
-
-#### `binlog_drainer_checkpoint_high_delay`
-
-* 报警规则：
-
- `(time() - binlog_drainer_checkpoint_tso / 1000) > 3600`
-
-* 规则描述：
-
- Drainer 同步落后延迟超过 1 个小时。
-
-* 处理方法：
-
- * 判断从 Pump 获取数据是否太慢：
-
- 监控 Pump handle tso 可以看每个 Pump 最近一条消息的时间，是不是有延迟特别大的 Pump，确认对应 Pump 正常运行。
-
- * 根据 Drainer event 和 Drainer execute latency 来判断是否下游同步太慢：
-
- * 如果 Drainer execute time 过大，则检查到目标库网络带宽和延迟，以及目标库状态。
- * 如果 Drainer execute time 不大，Drainer event 过小，则增加 work count 和 batch 进行重试。
-
- * 如果上面都不满足或者操作后没有改观，请从 PingCAP 官方或 TiDB 社区[获取支持](/support.md)。
-
-### 警告级别报警项
-
-警告级别的报警是对某一问题或错误的提醒。
-
-#### `binlog_pump_write_binlog_rpc_duration_seconds_bucket`
-
-* 报警规则：
-
- `histogram_quantile(0.9, rate(binlog_pump_rpc_duration_seconds_bucket{method="WriteBinlog"}[5m])) > 1`
-
-* 规则描述：
-
- Pump 处理 TiDB 写 Binlog 请求耗时过大。
-
-* 处理方法：
-
- * 确认磁盘性能压力，通过 `node exported` 查看 disk performance 监控。
- * 如果 `disk latency` 和 `util` 都很低，请从 PingCAP 官方或 TiDB 社区[获取支持](/support.md)。
-
-#### `binlog_pump_storage_write_binlog_duration_time_bucket`
-
-* 报警规则：
-
- `histogram_quantile(0.9, rate(binlog_pump_storage_write_binlog_duration_time_bucket{type="batch"}[5m])) > 1`
-
-* 规则描述：
-
- Pump 写本地 binlog 到本地盘的耗时。
-
-* 处理方法：
-
- 确认 Pump 本地盘情况，进行修复。
-
-#### `binlog_pump_storage_available_size_less_than_20G`
-
-* 报警规则：
-
- `binlog_pump_storage_storage_size_bytes{type="available"} < 20 * 1024 * 1024 * 1024`
-
-* 规则描述：
-
- Pump 剩余可用磁盘空间不足 20 G。
-
-* 处理方法：
-
- 监控确认 Pump 的 `gc_tso` 是否正常。如果不正常，调整 Pump 的 GC 时间配置或者下线对应 Pump。
-
-#### `binlog_drainer_checkpoint_tso_no_change_for_1m`
-
-* 报警规则：
-
- `changes(binlog_drainer_checkpoint_tso[1m]) < 1`
-
-* 规则描述：
-
- Drainer 的 `checkpoint` 在 1 分钟内没有更新。
-
-* 处理方法：
-
- 确认所有非下线的 Pump 是否正常运行。
-
-#### `binlog_drainer_execute_duration_time_more_than_10s`
-
-* 报警规则：
-
- `histogram_quantile(0.9, rate(binlog_drainer_execute_duration_time_bucket[1m])) > 10`
-
-* 规则描述：
-
- Drainer 同步到 TiDB 的事务耗时。如果这个值过大，会影响 Drainer 同步。
-
-* 处理方法：
-
- * 查看 TiDB 集群的状态。
- * 查看 Drainer 日志或监控，如果是 DDL 操作导致了该问题，则忽略。
diff --git a/tidb-binlog/tidb-binlog-configuration-file.md b/tidb-binlog/tidb-binlog-configuration-file.md
deleted file mode 100644
index 4dda1aee46f8..000000000000
--- a/tidb-binlog/tidb-binlog-configuration-file.md
+++ /dev/null
@@ -1,353 +0,0 @@
----
-title: TiDB Binlog 配置说明
-aliases: ['/docs-cn/dev/tidb-binlog/tidb-binlog-configuration-file/','/docs-cn/dev/reference/tidb-binlog/configs/']
-summary: TiDB Binlog 配置说明：介绍 Pump 和 Drainer 的配置项，包括地址、存储、安全和同步相关配置。 Pump 包括 addr、advertise-addr、socket、pd-urls、data-dir、heartbeat-interval、gen-binlog-interval、gc、log-file、log-level、node-id、security 和 storage 配置。 Drainer 包括 addr、advertise-addr、log-file、log-level、node-id、data-dir、detect-interval、pd-urls、initial-commit-ts、synced-check-time、compressor、security 和 syncer 配置。
----
-
-# TiDB Binlog 配置说明
-
-本文档介绍 TiDB Binlog 的各项配置说明。
-
-## Pump
-
-本节介绍 Pump 的配置项。可以在 [Pump Configuration](https://github.com/pingcap/tidb-binlog/blob/master/cmd/pump/pump.toml) 中查看完整的 Pump 配置文件示例。
-
-### addr
-
-* HTTP API 的监听地址，格式为 `host:port`。
-* 默认：`"127.0.0.1:8250"`
-
-### advertise-addr
-
-* 对外可访问的 HTTP API 地址。这个地址会被注册到 PD，格式为 `host:port`。
-* 默认：与 `addr` 的配置相同。
-
-### socket
-
-* HTTP API 监听的 Unix socket 地址。
-* 默认：`""`
-
-### pd-urls
-
-* 由逗号分隔的 PD URL 列表。如果指定了多个地址，PD 客户端在连接一个地址时出错时会自动尝试连接另一个地址。
-* 默认：`"http://127.0.0.1:2379"`
-
-### data-dir
-
-* 本地存放 binlog 及其索引的目录。
-* 默认：`"data.pump"`
-
-### heartbeat-interval
-
-* 心跳间隔，即每隔指定秒数向 PD 汇报最新的状态。
-* 默认：`2`
-
-### gen-binlog-interval
-
-* 指定写入 fake binlog 的间隔秒数。
-* 默认：`3`
-
-### gc
-
-* 指定 binlog 可在本地存储的天数（整型）。超过指定天数的 binlog 会被自动删除。
-* 默认：`7`
-
-### log-file
-
-* 保存日志文件的路径。如果为空，日志不会被保存。
-* 默认：`""`
-
-### log-level
-
-* Log 等级。
-* 默认：`"info"`
-
-### node-id
-
-* Pump 节点的 ID，用于在集群中识别这个进程。
-* 默认：`主机名:端口号`，例如 `node-1:8250`。
-
-### security
-
-以下是与安全相关的配置项。
-
-#### ssl-ca
-
-* 包含可信 SSL 证书或 CA 证书列表的文件路径，例如 `/path/to/ca.pem`。
-* 默认：`""`
-
-#### ssl-cert
-
-* 包含 PEM 格式编码的 X509 证书文件路径，例如 `/path/to/pump.pem`。
-* 默认：`""`
-
-#### ssl-key
-
-* 包含 PEM 格式编码的 X509 Key 文件路径，例如 `/path/to/pump-key.pem`。
-* 默认：`""`
-
-### storage
-
-以下是与存储相关的配置项。
-
-#### sync-log
-
-* 指定是否在每次**批量**写入 binlog 后使用 `fsync` 以确保数据安全。
-* 默认：`true`
-
-#### kv_chan_cap
-
-* 在 Pump 接收写入请求时会先将请求放入一个缓冲区，该项指定缓冲区能存放的请求数量。
-* 默认：`1048576`（即 2 的 20 次方）
-
-#### slow_write_threshold
-
-* 写入单个 binlog 的耗时超过该项设定的秒数就被认为是慢写入，并输出一条包含 `"take a long time to write binlog"` 的日志。
-* 默认：`1`
-
-#### stop-write-at-available-space
-
-* 可用存储空间低于指定值时不再接收 binlog 写入请求。可以用例如 `900 MB`、`5 GB`、`12 GiB` 的格式指定空间大小。如果集群中 Pump 节点多于一个，那么在某个 Pump 节点因为空间不足而拒绝写入时，TiDB 端会自动写入到其他 Pump 节点。
-* 默认：`10 GiB`
-
-#### kv
-
-目前 Pump 的存储是基于 [GoLevelDB](https://github.com/syndtr/goleveldb) 实现的。`storage` 下还有一个 kv 子分组可以用于调整 GoLevelDB 的配置，支持的配置项包括：
-
-* block-cache-capacity
-* block-restart-interval
-* block-size
-* compaction-L0-trigger
-* compaction-table-size
-* compaction-total-size
-* compaction-total-size-multiplier
-* write-buffer
-* write-L0-pause-trigger
-* write-L0-slowdown-trigger
-
-配置具体含义可在 [GoLevelDB 文档](https://godoc.org/github.com/syndtr/goleveldb/leveldb/opt#Options)中查看。
-
-## Drainer
-
-本节介绍 Drainer 的配置项。可以在 [Drainer Configuration](https://github.com/pingcap/tidb-binlog/blob/master/cmd/drainer/drainer.toml) 中查看完整的配置文件示例。
-
-### addr
-
-* HTTP API 的监听的地址，格式为 `host:port`。
-* 默认：`"127.0.0.1:8249"`
-
-### advertise-addr
-
-* 对外可访问的 HTTP API 地址，这个地址会被注册到 PD，格式为 `host:port`。
-* 默认：设定成与 `addr` 相同的配置
-
-### log-file
-
-* 日志的文件保存路径。如果为空，日志不会被保存。
-* 默认：`""`
-
-### log-level
-
-* Log 等级。
-* 默认：`"info"`
-
-### node-id
-
-* Drainer 节点 ID，用于在集群中识别这个进程。
-* 默认：`主机名:端口号`，例如 `node-1:8249`。
-
-### data-dir
-
-* 用于存放 Drainer 运行中需要保存的文件的目录。
-* 默认：`"data.drainer"`
-
-### detect-interval
-
-* 每隔指定秒数从 PD 更新一次 Pumps 信息，以获取节点加入或离开等事件。
-* 默认：`5`
-
-### pd-urls
-
-* 由逗号分隔的 PD URL 列表。如果指定了多个地址，PD 客户端在连接一个地址出错时会自动尝试连接另一个地址。
-* 默认：`"http://127.0.0.1:2379"`
-
-### initial-commit-ts
-
-* 指定从哪个事务提交时间点（事务的 commit ts） 之后开始同步。这个配置仅适用于初次开始同步的 Drainer 节点。如果下游已经有 checkpoint 存在，则会根据 checkpoint 里记录的时间进行同步。
-* commit ts（即 commit timestamp）是 TiDB [事务](/transaction-overview.md)的提交时间点。该时间点是从 PD 获取的全局唯一递增的时间戳，作为当前事务的唯一 ID。典型的 `initial-commit-ts` 配置可以通过以下方式获得：
- - BR 备份的元信息（即 backupmeta）中记录的 backup TS
- - Dumpling 备份的元信息（即 metadata）中记录的 Pos
- - PD Control 中 `tso` 命令返回的结果
-* 默认：`-1`。Drainer 会从 PD 得到一个最新的 timestamp 作为初始时间。即从当前的时间点开始同步。
-
-### synced-check-time
-
-* 通过 HTTP API 访问 `/status` 路径可以查询 Drainer 同步的状态。`synced-check-time` 指定距离上次成功同步的时间超过多少分钟可以认为是 `synced`，即同步完成。
-* 默认：`5`
-
-### compressor
-
-* 指定 Pump 与 Drainer 间的数据传输所用的压缩算法。目前仅支持一种算法，即 `gzip`。
-* 默认：`""`，表示不压缩。
-
-### security
-
-以下是与 Drainer 安全相关的配置。
-
-#### ssl-ca
-
-* 包含可信 SSL 证书或 CA 证书列表的文件路径，例如 `/path/to/ca.pem`。
-* 默认：`""`
-
-#### ssl-cert
-
-* 包含 PEM 格式编码的 X509 证书文件路径，例如 `/path/to/drainer.pem`。
-* 默认：`""`
-
-#### ssl-key
-
-* 包含 PEM 格式编码的 X509 Key 文件路径，例如 `/path/to/drainer-key.pem`。
-* 默认：`""`
-
-### syncer
-
-syncer 分组包含一些与同步下游相关的配置项。
-
-#### db-type
-
-下游类型，目前支持的选项有：
-
-* `mysql`
-* `tidb`
-* `kafka`
-* `file`
-
-默认：`mysql`
-
-#### sql-mode
-
-* 当下游为 `mysql`/`tidb` 类型时，可以指定 SQL mode，如果超过一个 mode，则用逗号隔开。
-* 默认：`""`
-
-#### ignore-txn-commit-ts
-
-* 同步时，该项所指定的 commit timestamp 的 binlog 会被忽略，例如 `[416815754209656834, 421349811963822081]`。
-* 默认：`[]`
-
-#### ignore-schemas
-
-* 同步时忽略指定数据库的变更。如果超过一个需忽略的数据库，则用逗号隔开。如果一个 binlog 中的变更全部被过滤掉，则忽略整个 binlog。
-* 默认：`"INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql"`
-
-#### ignore-table
-
-同步时忽略指定表格的变更。在 `toml` 中可以用以下方式指定多个需忽略的表格：
-
-{{< copyable "" >}}
-
-```toml
-[[syncer.ignore-table]]
-db-name = "test"
-tbl-name = "log"
-
-[[syncer.ignore-table]]
-db-name = "test"
-tbl-name = "audit"
-```
-
-如果一个 binlog 中的变更全部被过滤掉，则忽略整个 binlog。
-
-默认：`[]`
-
-#### replicate-do-db
-
-* 指定要同步的数据库，例如 `[db1, db2]`。
-* 默认：`[]`
-
-#### replicate-do-table
-
-指定要同步的表格，示例如下：
-
-{{< copyable "" >}}
-
-```toml
-[[syncer.replicate-do-table]]
-db-name ="test"
-tbl-name = "log"
-
-[[syncer.replicate-do-table]]
-db-name ="test"
-tbl-name = "~^a.*"
-```
-
-默认：`[]`
-
-#### txn-batch
-
-* 当下游为 `mysql`/`tidb` 类型时，会将 DML 分批执行。这个配置可以用于设置每个事务中包含多少个 DML。
-* 默认：`20`
-
-#### worker-count
-
-* 当下游为 `mysql`/`tidb` 类型时，会并发执行 DML，`worker-count` 可以指定并发数。
-* 默认：`16`
-
-#### disable-dispatch
-
-* 关掉并发，强制将 `worker-count` 置为 `1`。
-* 默认：`false`
-
-#### safe-mode
-
-如果打开 Safe mode，Drainer 会对同步的变更作以下修改，使其变成可重入的操作：
-
-* `Insert` 变为 `Replace Into`
-* `Update` 变为 `Delete` 和 `Replace Into`
-
-默认：`false`
-
-### syncer.to
-
-不同类型的下游配置都在 `syncer.to` 分组。以下按配置类型进行介绍。
-
-#### mysql/tidb
-
-用于连接下游数据库的配置项：
-
-* `host`：如果没有设置，会尝试检查环境变量 `MYSQL_HOST`，默认值为 `"localhost"`。
-* `port`：如果没有设置，会尝试检查环境变量 `MYSQL_PORT`，默认值为 `3306`。
-* `user`：如果没有设置，会尝试检查环境变量 `MYSQL_USER`，默认值为 `"root"`。
-* `password`：如果没有设置，会尝试检查环境变量 `MYSQL_PSWD`，默认值为 `""`。
-* `read-timeout`：指定下游数据库连接的 IO 读取超时时间，默认值为 `1m`。如果 drainer 在一些耗时长的 DDL 上不断失败，你可以将这个变量设置为更大的值。
-
-#### file
-
-* `dir`：指定用于保存 binlog 的目录。如果不指定该项，则使用 `data-dir`。
-
-#### kafka
-
-当下游为 `kafka` 时，有效的配置包括：
-
-* `zookeeper-addrs`
-* `kafka-addrs`
-* `kafka-version`
-* `kafka-max-messages`
-* `kafka-max-message-size`
-* `topic-name`
-
-### syncer.to.checkpoint
-
-* `type`：指定用哪种方式保存同步进度，目前支持的选项为 `mysql`、`tidb` 和 `file`。
-
- 该配置选项默认与下游类型相同。例如 `file` 类型的下游 checkpoint 进度保存在本地文件 `/savepoint` 中，`mysql` 类型的下游进度保存在下游数据库。当明确指定要使用 `mysql` 或 `tidb` 保存同步进度时，需要指定以下配置项：
-
-* `schema`：默认为 `"tidb_binlog"`。
-
- > **注意：**
- >
- > 在同个 TiDB 集群中部署多个 Drainer 时，需要为每个 Drainer 节点指定不同的 checkpoint schema，否则两个实例的同步进度会互相覆盖。
-
-* `host`
-* `user`
-* `password`
-* `port`
diff --git a/tidb-binlog/tidb-binlog-faq.md b/tidb-binlog/tidb-binlog-faq.md
deleted file mode 100644
index 698f34651c0c..000000000000
--- a/tidb-binlog/tidb-binlog-faq.md
+++ /dev/null
@@ -1,239 +0,0 @@
----
-title: TiDB Binlog 常见问题
-aliases: ['/docs-cn/dev/tidb-binlog/tidb-binlog-faq/','/docs-cn/dev/reference/tidb-binlog/faq/','/docs-cn/dev/faq/tidb-binlog/','/docs-cn/dev/reference/tools/tidb-binlog/faq/']
-summary: TiDB Binlog 常见问题解决方案：性能影响、同步延迟、Drainer 权限、Pump 磁盘处理、同步中断处理、同步慢处理、Pump crash 处理、checkpoint 作用、Drainer 故障处理、全量+binlog 备份恢复、ignore-error 处理、DDL 执行错误处理、Pump/Drainer 暂停和下线处理。
----
-
-# TiDB Binlog 常见问题
-
-本文介绍 TiDB Binlog 使用过程中的常见问题及解决方案。
-
-## 开启 binog 对 TiDB 的性能有何影响？
-
-- 对于查询无影响。
-
-- 对于有写入或更新数据的事务有一点性能影响。延迟上，在 Prewrite 阶段要并发写一条 p-binlog 成功后才可以提交事务，一般写 binlog 比 KV Prewrite 快，所以不会增加延迟。可以在 Pump 的监控面板看到写 binlog 的响应时间。
-
-## TiDB Binlog 的同步延迟一般为多少？
-
-TiDB Binlog 的同步延迟为秒级别，在非业务高峰时延迟一般为 3 秒左右。
-
-## Drainer 同步下游 TiDB/MySQL 的账号需要哪些权限？
-
-Drainer 同步账号需要有如下权限：
-
-* Insert
-* Update
-* Delete
-* Create
-* Drop
-* Alter
-* Execute
-* Index
-* Select
-* Create View
-
-## Pump 磁盘快满了怎么办？
-
-确认 GC 正常：
-
-- 确认 pump 监控面板 **gc_tso** 时间是否与配置一致。
-
-如 gc 正常以下调整可以降低单个 pump 需要的空间大小：
-
-- 调整 pump **GC** 参数减少保留数据天数。
-- 添加 pump 结点。
-
-## Drainer 同步中断怎么办？
-
-使用以下 binlogctl 命令查看 Pump 状态是否正常，以及是否全部非 `offline` 状态的 Pump 都在正常运行。
-
-{{< copyable "shell-regular" >}}
-
-```bash
-binlogctl -cmd pumps
-```
-
-查看 Drainer 监控与日志是否有对应报错，根据具体问题进行处理。
-
-## Drainer 同步下游 TiDB/MySQL 慢怎么办？
-
-特别关注以下监控项：
-
-- 通过 Drainer 监控 **drainer event**，可以看到 Drainer 当前每秒同步 Insert/Update/Delete 事件到下游的速度。
-- 通过 Drainer 监控 **sql query time**，可以看到 Drainer 在下游执行 SQL 的响应时间。
-
-同步慢的可能原因与解决方案：
-
-- 同步的数据库包含没有主键或者唯一索引的表，需要给表加上主键。
-- Drainer 与下游之间延迟大，可以调大 Drainer `worker-count` 参数（跨机房同步建议将 Drainer 部署在下游）。
-- 下游负载不高，可以尝试调大 Drainer `worker-count` 参数。
-
-## 假如有一个 Pump crash 了会怎样？
-
-Drainer 会因为获取不到这个 Pump 的数据没法同步数据到下游。如果这个 Pump 能恢复，Drainer 就能恢复同步。
-
-如果 Pump 没法恢复，可采用以下方式进行处理：
-
-1. 使用 [binlogctl 将该 Pump 状态修改为 `offline`](/tidb-binlog/maintain-tidb-binlog-cluster.md)（丢失这个 Pump 的数据）
-2. Drainer 获取到的数据会丢失这个 Pump 上的数据，下游跟上游数据会不一致，需要重新做全量 + 增量同步。具体步骤如下：
- 1. 停止当前 Drainer。
- 2. 上游做全量备份。
- 3. 清理掉下游数据，包括 checkpoint 表 `tidb_binlog.checkpoint`。
- 4. 使用上游的全量备份恢复下游数据。
- 5. 部署 Drainer，使用 `initialCommitTs`= {从全量备份获取快照的时间戳}。
-
-## 什么是 checkpoint？
-
-Checkpoint 记录了 Drainer 同步到下游的 commit-ts，Drainer 重启时可以读取 checkpoint 接着从对应 commit-ts 同步数据到下游。Drainer 日志 `["write save point"] [ts=411222863322546177]` 表示保存对应时间戳的 checkpoint。
-
-下游类型不同，checkpoint 的保存方式也不同：
-
-- 下游 MySQL/TiDB 保存在 `tidb_binlog.checkpoint` 表。
-- 下游 kafka/file 保存在对应配置目录里的文件。
-
-因为 kafka/file 的数据内容包含了 commit-ts，所以如果 checkpoint 丢失，可以消费下游最新的一条数据看写到下游数据的最新 commit-ts。
-
-Drainer 启动的时候会去读取 checkpoint，如果读取不到，就会使用配置的 `initial-commit-ts` 做为初次启动开始的同步时间点。
-
-## Drainer 机器发生故障，下游数据还在，如何在新机器上重新部署 Drainer？
-
-如果下游数据还在，只要保证能从对应 checkpoint 接着同步即可。
-
-假如 checkpoint 还在，可采用以下方式进行处理：
-
-1. 部署新的 Drainer 并启动即可（参考 checkpoint 介绍，Drainer 可以读取 checkpoint 接着同步）。
-2. 使用 [binlogctl 将老的 Drainer 状态修改成 `offline`](/tidb-binlog/maintain-tidb-binlog-cluster.md)。
-
-假如 checkpoint 不在，可以如下处理：
-
-1. 获取之前 Drainer 的 checkpoint `commit-ts`，做为新部署 Drainer 的 `initial-commit-ts` 配置来部署新的 Drainer。
-2. 使用 [binlogctl 将老的 Drainer 状态修改成 `offline`](/tidb-binlog/maintain-tidb-binlog-cluster.md)。
-
-## 如何用全量 + binlog 备份文件来恢复一个集群？
-
-1. 清理集群数据并使用全部备份恢复数据。
-2. 使用 reparo 设置 `start-tso` = {全量备份文件快照时间戳+1}，`end-ts` = 0（或者指定时间点），恢复到备份文件最新的数据。
-
-## 主从同步开启 `ignore-error` 触发 critical error 后如何重新部署？
-
-TiDB 配置开启 `ignore-error` 写 binlog 失败后触发 critical error 告警，后续都不会再写 binlog，所以会有 binlog 数据丢失。如果要恢复同步，需要如下处理：
-
-1. 停止当前 Drainer。
-2. 重启触发 critical error 的 `tidb-server` 实例重新开始写 binlog（触发 critical error 后不会再写 binlog 到 pump）。
-3. 上游做全量备份。
-4. 清理掉下游数据包括 checkpoint 表 `tidb_binlog.checkpoint`。
-5. 使用上游的全量备份恢复下游。
-6. 部署 Drainer，使用 `initialCommitTs`= {从全量备份获取快照的时间戳}。
-
-## 同步时出现上游数据库支持但是下游数据库执行会出错的 DDL，应该怎么办？
-
-1. 查看 drainer.log 日志，查找 `exec failed` 找到 Drainer 退出前最后一条执行失败的 DDL。
-2. 将 DDL 改为下游兼容支持的版本，在下游数据库中手动执行。
-3. 查看 drainer.log 日志，查找执行失败的 DDL 语句，可以查询到该 DDL 的 commit-ts。例如：
-
- ```
- [2020/05/21 09:51:58.019 +08:00] [INFO] [syncer.go:398] ["add ddl item to syncer, you can add this commit ts to `ignore-txn-commit-ts` to skip this ddl if needed"] [sql="ALTER TABLE `test` ADD INDEX (`index1`)"] ["commit ts"=416815754209656834]。
- ```
-
-4. 编辑 `drainer.toml` 配置文件，在 `ignore-txn-commit-ts` 项中添加该 commit-ts，重启 Drainer。
-
-在绝大部分情况下，TiDB 和 MySQL 的语句都是兼容的。用户需要注意的是上下游的 `sql_mode` 应当保持一致。
-
-## 在什么情况下暂停和下线 Pump/Drainer？
-
-首先需要通过以下内容来了解 Pump/Drainer 的状态定义和启动、退出的流程。
-
-暂停主要针对临时需要停止服务的场景，例如：
-
-- 版本升级：停止进程后使用新的 binary 启动服务。
-- 服务器维护：需要对服务器进行停机维护。退出进程，等维护完成后重启服务。
-
-下线主要针对永久（或长时间）不再使用该服务的场景，例如：
-
-- Pump 缩容：不再需要那么多 Pump 服务了，所以下线部分服务。
-- 同步任务取消：不再需要将数据同步到某个下游，所以下线对应的 Drainer。
-- 服务器迁移：需要将服务迁移到其他服务器。下线服务，在新的服务器上重新部署。
-
-## 可以通过哪些方式暂停 Pump/Drainer？
-
-- 直接 kill 进程。
-
- >**注意：**
- >
- > 不能使用 `kill -9` 命令，否则 Pump/Drainer 无法对信号进行处理。
-
-- 如果 Pump/Drainer 运行在前台，则可以通过按下 Ctrl+C 来暂停。
-- 使用 binlogctl 的 `pause-pump` 或 `pause-drainer` 命令。
-
-## 可以使用 binlogctl 的 `update-pump`/`update-drainer` 命令来下线 Pump/Drainer 服务吗？
-
-不可以。使用 `update-pump`/`update-drainer` 命令会直接修改 PD 中保存的状态信息，并且不会通知 Pump/Drainer 做相应的操作。使用不当时，可能会干扰数据同步，某些情况下还可能会造成**数据不一致**的严重后果。例如：
-
-- 当 Pump 正常运行或者处于暂停状态时，如果使用 `update-pump` 将该 Pump 设置为 `offline`，那么 Drainer 会放弃获取处于 `offline` 状态的 Pump 的 binlog 数据，导致该 Pump 最新的 binlog 数据没有同步到 Drainer，造成上下游数据不一致。
-- 当 Drainer 正常运行时，使用 `update-drainer` 命令将该 Drainer 设置为 `offline`。如果这时启动一个 Pump 节点，Pump 只会通知 `online` 状态的 Drainer，导致该 Drainer 没有及时获取到该 Pump 的 binlog 数据，造成上下游数据不一致。
-
-## 可以使用 binlogctl 的 `update-pump`/`update-drainer` 命令来暂停 Pump/Drainer 服务吗？
-
-不可以。`update-pump`/`update-drainer` 命令直接修改 PD 中保存的状态信息。执行这个命令并不会通知 Pump/Drainer 做相应的操作，**而且使用不当会使数据同步中断，甚至造成数据丢失。**
-
-## 什么情况下使用 binlogctl 的 `update-pump` 命令设置 Pump 状态为 `paused`？
-
-在某些异常情况下，Pump 没有正确维护自己的状态，实际上状态应该为 `paused`。这时可以使用 `update-pump` 对状态进行修正，例如：
-
-- Pump 异常退出（可能由 panic 或者误操作执行 `kill -9` 命令直接 kill 掉进程导致），Pump 保存在 PD 中的状态仍然为 `online`。如果暂时不需要重启 Pump 恢复服务，可以使用 `update-pump` 把该 Pump 状态设置为 `paused`，避免对 TiDB 写 binlog 和 Drainer 获取 binlog 造成干扰。
-
-## 什么情况下使用 binlogctl 的 `update-drainer` 命令设置 Drainer 状态为 `paused`？
-
-在某些异常情况下，Drainer 没有正确维护自己的状态，，对数据同步造成了影响，实际上状态应该为 `paused`。这时可以使用 `update-drainer` 对状态进行修正，例如：
-
-- Drainer 异常退出（出现 panic 直接退出进程，或者误操作执行 `kill -9` 命令直接 kill 掉进程），Drainer 保存在 PD 中的状态仍然为 `online`。当 Pump 启动时无法正常通知该 Drainer（报错 `notify drainer ...`），导致 Pump 无法正常运行。这个时候可以使用 `update-drainer` 将 Drainer 状态更新为 `paused`，再启动 Pump。
-
-## 可以通过哪些方式下线 Pump/Drainer？
-
-目前只可以使用 binlogctl 的 `offline-pump` 和 `offline-drainer` 命令来下线 Pump 和 Drainer。
-
-## 什么情况下使用 binlogctl 的 `update-pump` 命令设置 Pump 状态为 `offline`?
-
-> **警告：**
->
-> 仅在可以容忍 binlog **数据丢失、上下游数据不一致**或者确认不再需要使用该 Pump 存储的 binlog 数据的情况下，才能使用 `update-pump` 修改 Pump 状态为 `offline`。
-
-可以使用 `update-pump` 修改 Pump 状态为 `offline` 的情况有：
-
-- 在某些情况下，Pump 异常退出进程，且无法恢复服务，同步就会中断。如果希望恢复同步且可以容忍部分 binlog 数据丢失，可以使用 `update-pump` 命令将该 Pump 状态设置为 `offline`，则 Drainer 会放弃拉取该 Pump 的 binlog 然后继续同步数据。
-- 有从历史任务遗留下来且不再使用的 Pump 且进程已经退出（例如测试使用的服务），之后不再需要使用该服务，使用 `update-pump` 将该 Pump 设置为 `offline`。
-
-在其他情况下一定要使用 `offline-pump` 命令让 Pump 走正常的下线处理流程。
-
-## Pump 进程已经退出，且状态为 `paused`，现在不想使用这个 Pump 节点了，能否用 binlogctl 的 `update-pump` 命令设置节点状态为 `offline`？
-
-Pump 以 `paused` 状态退出进程时，不保证所有 binlog 数据被下游 Drainer 消费。所以这样做会有上下游数据不一致的风险。正确的做法是重新启动 Pump，然后使用 `offline-pump` 下线该 Pump。
-
-## 什么情况下使用 binlogctl 的 `update-drainer` 命令设置 Drainer 状态为 `offline`？
-
-- 有从历史任务遗留下来且不再使用的 Drainer 且进程已经退出（例如测试使用的服务），之后不再需要使用该服务，使用 `update-drainer` 将该 Drainer 设置为 `offline`。
-
-## 可以使用 `change pump`、`change drainer` 等 SQL 操作来暂停或者下线 Pump/Drainer 服务吗？
-
-目前还不支持。这种 SQL 操作会直接修改 PD 中保存的状态，在功能上等同于使用 binlogctl 的 `update-pump`、`update-drainer` 命令。如果需要暂停或者下线，仍然要使用 binlogctl。
-
-## TiDB 写入 binlog 失败导致 TiDB 卡住，日志中出现 `listener stopped, waiting for manual stop`
-
-在 TiDB v3.0.12 以及之前，binlog 写入失败会导致 TiDB 报 fatal error。但是 TiDB 不会自动退出只是停止服务，看起来像服务卡住。TiDB 日志中可看到 `listener stopped, waiting for manual stop`。
-
-遇到该问题需要根据具体情况判断是什么原因导致 binlog 写入失败。如果是 binlog 写入下游缓慢导致的，可以考虑扩容 Pump 或增加写 binlog 的超时时间。
-
-TiDB 在 v3.0.13 版本中已优化此逻辑，写入 binlog 失败将使事务执行失败返回报错，而不会导致 TiDB 卡住。
-
-## TiDB 向 Pump 写入了重复的 binlog？
-
-TiDB 在写入 binlog 失败或者超时的情况下，会重试将 binlog 写入到下一个可用的 Pump 节点直到写入成功。所以如果写入到某个 Pump 节点较慢，导致 TiDB 超时（默认 15s），此时 TiDB 判定写入失败并尝试写入下一个 Pump 节点。如果超时的 Pump 节点实际也写入成功，则会出现同一条 binlog 被写入到多个 Pump 节点。Drainer 在处理 binlog 的时候，会自动去重 TSO 相同的 binlog，所以这种重复的写入对下游无感知，不会对同步逻辑产生影响。
-
-## 在使用全量 + 增量方式恢复的过程中，Reparo 中断了，可以使用日志里面最后一个 TSO 恢复同步吗？
-
-可以。Reparo 不会在启动时自动开启 safe-mode 模式，需要手动操作：
-
-1. Reparo 中断后，记录日志中最后一个 TSO，记为 `checkpoint-tso`。
-2. 修改 Reparo 配置文件，将配置项 `start-tso` 设为 `checkpoint-tso + 1`，将 `stop-tso` 设为 `checkpoint-tso + 80,000,000,000`（大概是 `checkpoint-tso` 延后 5 分钟），将 `safe-mode` 设置为 `true`。启动 Reparo，Reparo 会将数据同步到 `stop-tso` 后自动停止。
-3. Reparo 自动停止后，将 `start-tso` 设置为 `checkpoint tso + 80,000,000,001`，将 `stop-tso` 设置为 `0`，将 `safe-mode` 设为 `false`。启动 Reparo 继续同步。
diff --git a/tidb-binlog/tidb-binlog-glossary.md b/tidb-binlog/tidb-binlog-glossary.md
deleted file mode 100644
index cd41400cd13e..000000000000
--- a/tidb-binlog/tidb-binlog-glossary.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: TiDB Binlog 术语表
-summary: 学习 TiDB Binlog 相关术语
-aliases: ['/docs-cn/dev/tidb-binlog/tidb-binlog-glossary/','/docs-cn/dev/reference/tidb-binlog/glossary/']
----
-
-# TiDB Binlog 术语表
-
-本文档介绍 TiDB Binlog 相关术语。
-
-## Binlog
-
-在 TiDB Binlog 中，Binlog 通常指 TiDB 写的二进制日志数据，也指 Drainer 写到 Kafka 或者文件的二进制日志数据，前者与后者的格式不同。此外，TiDB 的 binlog 格式与 MySQL 的 binlog 格式也不同。
-
-## Binlog event
-
-TiDB 写的 DML Binlog 有 3 种 event，分别为：`INSERT`、`UPDATE` 和 `DELETE`。在 Drainer 监控面板上可以看到同步数据对应的不同 event 的个数。
-
-## Checkpoint
-
-Checkpoint 指保存的断点信息，记录了 Drainer 同步到下游的 commit-ts。Drainer 重启时可以读取 checkpoint，并从对应的 commit-ts 开始同步数据到下游。
-
-## Safe mode
-
-Safe mode 指增量复制过程中，当表结构中存在主键或唯一索引时，用于支持幂等导入 DML 的模式。
-
-该模式将来自上游的 `INSERT` 改写为 `REPLACE`，将 `UPDATE` 改写为 `DELETE` 与 `REPLACE`，然后再向下游执行。在 Drainer 启动的前 5 分钟，会自动启动 Safe mode；另外也可以在配置文件中通过 `safe-mode` 参数手动开启，但该配置仅在下游是 MySQL 或 TiDB 时有效。
diff --git a/tidb-binlog/tidb-binlog-overview.md b/tidb-binlog/tidb-binlog-overview.md
deleted file mode 100644
index d634c5c03818..000000000000
--- a/tidb-binlog/tidb-binlog-overview.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: TiDB Binlog 简介
-aliases: ['/docs-cn/dev/tidb-binlog/tidb-binlog-overview/','/docs-cn/dev/reference/tidb-binlog/overview/','/docs-cn/dev/reference/tidb-binlog-overview/','/docs-cn/dev/reference/tools/tidb-binlog/overview/']
-summary: TiDB Binlog 是用于收集 TiDB 的 binlog 并提供实时备份和同步功能的商业工具。它支持数据同步和实时备份恢复功能。从 v8.3.0 开始，TiDB Binlog 被完全废弃。
----
-
-# TiDB Binlog 简介
-
-TiDB Binlog 是一个用于收集 TiDB 的 binlog，并提供准实时备份和同步功能的商业工具。
-
-> **警告：**
->
-> - 从 v7.5.0 开始，TiDB Binlog 的数据同步功能被废弃。从 v8.3.0 开始，TiDB Binlog 被完全废弃，并计划在未来版本中移除。如需进行增量数据同步，请使用 [TiCDC](/ticdc/ticdc-overview.md)。如需按时间点恢复 (point-in-time recovery, PITR)，请使用 [PITR](/br/br-pitr-guide.md)。
-> - TiDB Binlog 与 TiDB v5.0 开始引入的一些特性不兼容，无法一起使用，详情参照[注意事项](#注意事项)。
-
-TiDB Binlog 支持以下功能场景：
-
-- **数据同步**：同步 TiDB 集群数据到其他数据库。
-- **实时备份和恢复**：备份 TiDB 集群数据，同时可以用于 TiDB 集群故障时恢复。
-
-要快速了解 Binlog 的基本原理和使用方法，建议先观看下面的培训视频（时长 32 分钟）。注意本视频只为学习参考，具体操作步骤和最新功能，请以文档内容为准。
-
-
-
-## TiDB Binlog 整体架构
-
-
-
-TiDB Binlog 集群主要分为 Pump 和 Drainer 两个组件，以及 binlogctl 工具：
-
-### Pump
-
-[Pump](https://github.com/pingcap/tidb-binlog/blob/master/pump) 用于实时记录 TiDB 产生的 Binlog，并将 Binlog 按照事务的提交时间进行排序，再提供给 Drainer 进行消费。
-
-### Drainer
-
-[Drainer](https://github.com/pingcap/tidb-binlog/tree/master/drainer) 从各个 Pump 中收集 Binlog 进行归并，再将 Binlog 转化成 SQL 或者指定格式的数据，最终同步到下游。
-
-### binlogctl 工具
-
-[`binlogctl`](https://github.com/pingcap/tidb-binlog/tree/master/binlogctl) 是一个 TiDB Binlog 配套的运维工具，具有如下功能：
-
-* 获取 TiDB 集群当前的 TSO
-* 查看 Pump/Drainer 状态
-* 修改 Pump/Drainer 状态
-* 暂停/下线 Pump/Drainer
-
-## 主要特性
-
-* 多个 Pump 形成一个集群，可以水平扩容。
-* TiDB 通过内置的 Pump Client 将 Binlog 分发到各个 Pump。
-* Pump 负责存储 Binlog，并将 Binlog 按顺序提供给 Drainer。
-* Drainer 负责读取各个 Pump 的 Binlog，归并排序后发送到下游。
-* Drainer 支持 [relay log](/tidb-binlog/tidb-binlog-relay-log.md) 功能，通过 relay log 保证下游集群的一致性状态。
-
-## 注意事项
-
-* TiDB Binlog 和 TiDB 在 v5.1 版本中解决了 v5.0 版本中引入的聚簇索引与 TiDB Binlog 不兼容问题。在升级 TiDB Binlog 和 TiDB Server 到 v5.1 版本后：开启 TiDB Binlog 后，TiDB 支持创建聚簇索引表；聚簇索引表的数据插入、删除和更新操作支持通过 TiDB Binlog 同步到下游。对于同步聚簇索引表时需注意：
-
- - 如果从 v5.0 版本手动控制组件升级顺序进行升级，请确保先将 TiDB Binlog 升级至 v5.1 版本后再将 TiDB Server 升级至 v5.1 版本。
- - 推荐将上下游的 TiDB 系统变量 [`tidb_enable_clustered_index`](/system-variables.md#tidb_enable_clustered_index-从-v50-版本开始引入) 配置为一致的值来保证上下游 TiDB 聚簇索引表结构一致。
-
-* TiDB Binlog 与 TiDB v5.0 版本开始引入的以下特性不兼容，无法一起使用：
-
- - [TiDB 聚簇索引特性](/clustered-indexes.md#限制)：开启 TiDB Binlog 后 TiDB 不允许创建非单个整数列作为主键的聚簇索引；已创建的聚簇索引表的数据插入、删除和更新动作不会通过 TiDB Binlog 同步到下游。如需同步聚簇索引表，请升级至 v5.1 版本或使用 [TiCDC](/ticdc/ticdc-overview.md)；
- - TiDB 系统变量 [tidb_enable_async_commit](/system-variables.md#tidb_enable_async_commit-从-v50-版本开始引入)：启用 TiDB Binlog 后，开启该选项无法获得性能提升。要获得性能提升，建议使用 [TiCDC](/ticdc/ticdc-overview.md) 替代 TiDB Binlog。
- - TiDB 系统变量 [tidb_enable_1pc](/system-variables.md#tidb_enable_1pc-从-v50-版本开始引入)：启用 TiDB Binlog 后，开启该选项无法获得性能提升。要获得性能提升，建议使用 [TiCDC](/ticdc/ticdc-overview.md) 替代 TiDB Binlog。
-
-* Drainer 支持将 Binlog 同步到 MySQL、TiDB、Kafka 或者本地文件。如果需要将 Binlog 同步到其他 Drainer 不支持的类型的系统中，可以设置 Drainer 将 Binlog 同步到 Kafka，然后根据 binlog consumer protocol 进行定制处理，参考 [Binlog Consumer Client 用户文档](/tidb-binlog/binlog-consumer-client.md)。
-
-* 如果 TiDB Binlog 用于增量恢复，可以设置配置项 `db-type="file"`，Drainer 会将 binlog 转化为指定的 [proto buffer 格式](https://github.com/pingcap/tidb-binlog/blob/master/proto/pb_binlog.proto)的数据，再写入到本地文件中。这样就可以使用 [Reparo](/tidb-binlog/tidb-binlog-reparo.md) 恢复增量数据。
-
- 关于 `db-type` 的取值，应注意：
-
- - 如果 TiDB 版本 < 2.1.9，则 `db-type="pb"`。
- - 如果 TiDB 版本 > = 2.1.9，则 `db-type="file"` 或 `db-type="pb"`。
-
-* 如果下游为 MySQL/TiDB，数据同步后可以使用 [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md) 进行数据校验。
diff --git a/tidb-binlog/tidb-binlog-relay-log.md b/tidb-binlog/tidb-binlog-relay-log.md
deleted file mode 100644
index b09733cb698e..000000000000
--- a/tidb-binlog/tidb-binlog-relay-log.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: TiDB Binlog Relay Log
-aliases: ['/docs-cn/dev/tidb-binlog/tidb-binlog-relay-log/','/docs-cn/dev/reference/tidb-binlog/relay-log/','/docs-cn/dev/reference/tools/tidb-binlog/relay-log/']
-summary: TiDB Binlog Relay Log 是用于确保下游集群与上游集群数据一致的工具。Drainer 同步时会拆分上游事务并并发同步到下游，使用 relay log 来恢复下游集群到一致状态。Drainer 会将 binlog event 写入磁盘并同步给下游，同时会清理已完成同步的 relay log 文件。配置中需指定保存 relay log 的目录和单个文件大小限制。
----
-
-# TiDB Binlog Relay Log
-
-Drainer 同步 binlog 时会拆分上游的事务，并将拆分的事务并发同步到下游。在极端情况下，上游集群不可用并且 Drainer 异常退出后，下游集群（MySQL 或 TiDB）可能处于数据不一致的中间状态。在此场景下，Drainer 借助 relay log 可以确保将下游集群同步到一个一致的状态。
-
-## Drainer 同步时的一致性状态
-
-下游集群达到一致的状态是指：下游集群的数据等同于上游设置了 `tidb_snapshot = ts` 的快照。
-
-checkpoint 状态一致性是指：Drainer checkpoint 通过 `consistent` 保存了同步的一致性状态。Drainer 运行时 `consistent` 为 `false`，Drainer 正常退出后 `consistent` 更新为 `true`。
-
-查询下游 checkpoint 表的示例如下：
-
-```
-mysql> select * from tidb_binlog.checkpoint;
-+---------------------+----------------------------------------------------------------+
-| clusterID | checkPoint |
-+---------------------+----------------------------------------------------------------+
-| 6791641053252586769 | {"consistent":false,"commitTS":414529105591271429,"ts-map":{}} |
-+---------------------+----------------------------------------------------------------+
-```
-
-## 工作原理
-
-Drainer 开启 relay log 后会先将 binlog event 写到磁盘上，然后再同步给下游集群。如果上游集群不可用，Drainer 可以通过读取 relay log 把下游集群恢复到一个一致的状态。
-
-> **注意：**
->
-> 若同时丢失 relay log 数据，该方法将不可用，不过这是概率极小的事件。此外可以使用 NFS 等网络文件系统来保证 relay log 的数据安全。
-
-### Drainer 从 relay log 消费 binlog 的触发场景
-
-如果 Drainer 启动时无法连接到上游集群的 PD，并且探测到 checkpoint 的 `consistent = false`，此时会尝试读取 relay log，并将下游集群恢复到一致的状态。然后 Drainer 进程将 checkpoint 的 `consistent` 设置为 `true` 后主动退出。
-
-### Relay log 的清理（GC）机制
-
-Drainer 在将数据同步到下游之前，会先将数据写入到 relay log 文件中。当一个 relay log 文件大小达到 10MB（默认）并且当前事务的 binlog 数据被写入完成后，Drainer 就会开始将数据写入到下一个 relay log 文件中。当 Drainer 将数据成功同步到下游后，就会自动清除当前正在写入的 relay log 文件以外其他已完成同步的 relay log 文件。
-
-## 配置
-
-在 Drainer 中添加以下配置来开启 relay log 功能：
-
-{{< copyable "" >}}
-
-```
-[syncer.relay]
-# 保存 relay log 的目录，空值表示不开启。
-# 只有下游是 TiDB 或 MySQL 时该配置才有生效。
-log-dir = "/dir/to/save/log"
-# 单个 relay log 文件大小限制（单位：字节）。
-# 超出该值后会将 binlog 数据写入到下一个 relay log 文件。
-max-file-size = 10485760
-```
diff --git a/tidb-binlog/tidb-binlog-reparo.md b/tidb-binlog/tidb-binlog-reparo.md
deleted file mode 100644
index 1728b0528363..000000000000
--- a/tidb-binlog/tidb-binlog-reparo.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: Reparo 使用文档
-aliases: ['/docs-cn/dev/tidb-binlog/tidb-binlog-reparo/','/docs-cn/dev/reference/tidb-binlog/reparo/','/docs-cn/dev/reference/tools/tidb-binlog/reparo/']
-summary: Reparo 是 TiDB Binlog 的配套工具，用于增量恢复。通过 Drainer 将 binlog 输出到文件，使用 Reparo 解析并应用到 TiDB／MySQL 中。安装包位于 TiDB 离线工具包中。使用命令行参数设置日志输出信息等级、同步下游的并发数等。配置文件可设置存储路径、日志等级、恢复时间范围、下游服务类型等。启动示例为 ./reparo -config reparo.toml。
----
-
-# Reparo 使用文档
-
-Reparo 是 TiDB Binlog 的一个配套工具，用于增量的恢复。使用 TiDB Binlog 中的 Drainer 将 binlog 按照 protobuf 格式输出到文件，通过这种方式来备份增量数据。当需要恢复增量数据时，使用 Reparo 解析文件中的 binlog，并将其应用到 TiDB／MySQL 中。
-
-Reparo 的安装包 `reparo` 位于 TiDB 离线工具包中。下载方式，请参考 [TiDB 工具下载](/download-ecosystem-tools.md)。
-
-## Reparo 使用
-
-### 命令行参数说明
-
-```
-Usage of Reparo:
--L string
- 日志输出信息等级设置：debug, info, warn, error, fatal（默认值：info）。
--V 打印版本信息。
--c int
- 同步下游的并发数，该值设置越高同步的吞吐性能越好（默认 16）。
--config string
- 配置文件路径，如果指定了配置文件，Reparo 会首先读取配置文件的配置；如果对应的配置在命令行参数里面也存在，Reparo 就会使用命令行参数的配置来覆盖配置文件里面的。
--data-dir string
- Drainer 输出的 protobuf 格式 binlog 文件的存储路径 (默认值： data.drainer)。
--dest-type string
- 下游服务类型。 取值为 print, mysql（默认值：print）。当值为 print 时，只做解析打印到标准输出，不执行 SQL；如果为 mysql，则需要在配置文件内配置 host、port、user、password 等信息。
--log-file string
- log 文件路径。
--log-rotate string
- log 文件切换频率，取值为 hour、day。
--start-datetime string
- 用于指定开始恢复的时间点，格式为 “2006-01-02 15:04:05”。如果不设置该参数则从最早的 binlog 文件开始恢复。
--stop-datetime string
- 用于指定结束恢复的时间点，格式同上。如果不设置该参数则恢复到最后一个 binlog 文件。
--safe-mode bool
- 指定是否开启安全模式，开启后可支持反复同步。
--txn-batch int
- 输出到下游数据库一个事务的 SQL 语句数量（默认 20）。
-```
-
-### 配置文件说明
-
-```toml
-# Drainer 输出的 protobuf 格式 binlog 文件的存储路径。
-data-dir = "./data.drainer"
-
-# 日志输出信息等级设置：debug, info, warn, error, fatal (默认值：info)。
-log-level = "info"
-
-# 使用 start-datetime 和 stop-datetime 来选择恢复指定时间范围内的 binlog，格式为 “2006-01-02 15:04:05”。
-# start-datetime = ""
-# stop-datetime = ""
-
-# start-tso、stop-tso 分别对应 start-datetime 和 stop-datetime，也是用于恢复指定时间范围内的 binlog，用 tso 的值来设置。如果已经设置了 start-datetime 和 stop-datetime，就不需要再设置 start-tso 和 stop-tso。
-# 在从全量或者上次增量位置继续同步时，start-tso 应当指定为全量 tso + 1 或者上次增量的 stop-tso + 1
-# start-tso = 0
-# stop-tso = 0
-
-# 下游服务类型。 取值为 print, mysql（默认值：print）。当值为 print 时，只做解析打印到标准输出，不执行 SQL；如果为 mysql，则需要在 [dest-db] 中配置 host、port、user、password 等信息。
-dest-type = "mysql"
-
-# 输出到下游数据库一个事务的 SQL 语句数量（默认 20）。
-txn-batch = 20
-
-# 同步下游的并发数，该值设置越高同步的吞吐性能越好（默认 16）。
-worker-count = 16
-
-# 安全模式配置。取值为 true 或 false（默认值：false）。当值为 true 时，Reparo 会将 update 语句拆分为 delete + replace 语句。
-safe-mode = false
-
-# replicate-do-db 和 replicate-do-table 用于指定恢复的库和表，replicate-do-db 的优先级高于 replicate-do-table。支持使用正则表达式来配置，需要以 '~' 开始声明使用正则表达式。
-# 注：replicate-do-db 和 replicate-do-table 使用方式与 Drainer 的使用方式一致。
-# replicate-do-db = ["~^b.*","s1"]
-# [[replicate-do-table]]
-# db-name ="test"
-# tbl-name = "log"
-# [[replicate-do-table]]
-# db-name ="test"
-# tbl-name = "~^a.*"
-
-# 如果 dest-type 设置为 mysql, 需要配置 dest-db。
-[dest-db]
-host = "127.0.0.1"
-port = 3309
-user = "root"
-password = ""
-```
-
-### 启动示例
-
-{{< copyable "shell-regular" >}}
-
-```bash
-./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 用于指定要恢复的表，不指定的话，则全部都恢复。
diff --git a/tidb-binlog/troubleshoot-tidb-binlog.md b/tidb-binlog/troubleshoot-tidb-binlog.md
deleted file mode 100644
index d636d5a30e50..000000000000
--- a/tidb-binlog/troubleshoot-tidb-binlog.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: TiDB Binlog 故障诊断
-aliases: ['/docs-cn/dev/tidb-binlog/troubleshoot-tidb-binlog/','/docs-cn/dev/reference/tidb-binlog/troubleshoot/binlog/','/docs-cn/dev/how-to/troubleshoot/tidb-binlog/']
-summary: TiDB Binlog 故障诊断总结了使用过程中遇到问题的诊断流程，并指引用户通过监控、状态、日志等信息查找解决方案。排查问题的方式包括查看监控指标、使用 binlogctl 工具查看 Pump、Drainer 状态，以及查看日志中的 ERROR 和 WARN 信息。定位到问题后，在 FAQ 和常见错误及修复中查找解决方案，如无法解决问题可提交 issue 或获取支持。
----
-
-# TiDB Binlog 故障诊断
-
-本文总结了在 TiDB Binlog 的使用过程中遇到问题的诊断流程，并指引用户通过监控、状态、日志等信息查找相应的解决方案。
-
-如果你在使用 TiDB Binlog 时出现了异常，请尝试以下方式排查问题：
-
-1. 查看各个监控指标是否异常，参见[TiDB Binlog 集群监控](/tidb-binlog/monitor-tidb-binlog-cluster.md)。
-
-2. 使用 [binlogctl 工具](/tidb-binlog/binlog-control.md)查看各个 Pump、Drainer 的状态是否有异常。
-
-3. 查看 Pump、Drainer 日志中是否有 `ERROR`、`WARN`，并根据详细的日志信息初步判断问题原因。
-
-通过以上方式定位到问题后，在 [FAQ](/tidb-binlog/tidb-binlog-faq.md) 以及[常见错误及修复](/tidb-binlog/handle-tidb-binlog-errors.md) 中查找解决方案，如果没有查找到解决方案或者提供的解决方案无法解决问题，请提交 [issue](https://github.com/pingcap/tidb-binlog/issues)，或从 PingCAP 官方或 TiDB 社区[获取支持](/support.md)。
diff --git a/tidb-binlog/upgrade-tidb-binlog.md b/tidb-binlog/upgrade-tidb-binlog.md
deleted file mode 100644
index c6a633336cb7..000000000000
--- a/tidb-binlog/upgrade-tidb-binlog.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: TiDB Binlog 版本升级方法
-aliases: ['/docs-cn/dev/tidb-binlog/upgrade-tidb-binlog/','/docs-cn/dev/reference/tidb-binlog/upgrade/','/docs-cn/dev/how-to/upgrade/tidb-binlog/','/docs-cn/dev/reference/tools/tidb-binlog/upgrade/']
-summary: TiDB Binlog 版本升级方法介绍了手动部署的步骤，包括升级 Pump 和 Drainer。同时，还介绍了从 Kafka/Local 版本升级到 Cluster 版本的流程，以及如何确认数据同步完成后启动新版本的 Drainer。从 v8.3.0 开始，TiDB Binlog 被完全废弃。
----
-
-# TiDB Binlog 版本升级方法
-
-如未特别指明，文中出现的 TiDB Binlog 均指最新的 [Cluster](/tidb-binlog/tidb-binlog-overview.md) 版本。
-
-> **警告：**
->
-> - 从 v7.5.0 开始，[TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md) 的数据同步功能被废弃。从 v8.3.0 开始，TiDB Binlog 被完全废弃，并计划在未来版本中移除。如需进行增量数据同步，请使用 [TiCDC](/ticdc/ticdc-overview.md)。如需按时间点恢复 (point-in-time recovery, PITR)，请使用 [PITR](/br/br-pitr-guide.md)。
-> - TiDB Binlog 与 TiDB v5.0 开始引入的一些特性不兼容，无法一起使用，详情参照[注意事项](/tidb-binlog/tidb-binlog-overview.md#注意事项)。
-
-本文介绍通过手动部署的 TiDB Binlog 的版本升级方法，另外有一小节介绍如何从更早的不兼容版本（Kafka/Local 版本）升级到最新版本。
-
-## 手动部署
-
-### 升级 Pump
-
-对集群里的每个 Pump 逐一升级，确保集群中总有 Pump 可以接收 TiDB 发来的 Binlog。
-
-1. 用新版本的 `pump` 替换原来的文件
-2. 重启 Pump 进程
-
-### 升级 Drainer
-
-1. 用新版本的 `drainer` 替换原来的文件
-2. 重启 Drainer 进程
-
-## 从 Kafka/Local 版本升级到 Cluster 版本
-
-新版本的 TiDB（v2.0.8-binlog、v2.1.0-rc.5 及以上版本）不兼容 [Kafka 版本](https://docs.pingcap.com/zh/tidb/v2.1/tidb-binlog-kafka-deployment/)以及 [Local 版本](https://docs.pingcap.com/zh/tidb/v2.1/tidb-binlog-local-deployment/)的 TiDB Binlog，集群升级到新版本后只能使用 Cluster 版本的 TiDB Binlog。如果在升级前已经使用了 Kafka／Local 版本的 TiDB Binlog，必须将其升级到 Cluster 版本。
-
-TiDB Binlog 版本与 TiDB 版本的对应关系如下：
-
-| TiDB Binlog 版本 | TiDB 版本 | 说明 |
-|---|---|---|
-| Local | TiDB 1.0 及更低版本 ||
-| Kafka | TiDB 1.0 ~ TiDB 2.1 RC5 | TiDB 1.0 支持 local 版本和 Kafka 版本的 TiDB Binlog。 |
-| Cluster | TiDB v2.0.8-binlog，TiDB 2.1 RC5 及更高版本 | TiDB v2.0.8-binlog 是一个支持 Cluster 版本 TiDB Binlog 的 2.0 特殊版本。 |
-
-### 升级流程
-
-> **注意：**
->
-> 如果能接受重新导全量数据，则可以直接废弃老版本，按 [TiDB Binlog 集群部署](/tidb-binlog/deploy-tidb-binlog.md)中的步骤重新部署。
-
-如果想从原来的 checkpoint 继续同步，使用以下升级流程：
-
-1. 部署新版本 Pump。
-2. 暂停 TiDB 集群业务。
-3. 更新 TiDB 以及配置，写 Binlog 到新的 Pump Cluster。
-4. TiDB 集群重新接入业务。
-5. 确认老版本的 Drainer 已经将老版本的 Pump 的数据完全同步到下游。
-
- 查询 Drainer 的 `status` 接口，示例命令如下：
-
- {{< copyable "shell-regular" >}}
-
- ```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 和 ZooKeeper。
diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md
index a7fff3c342f9..21ba7652a44a 100644
--- a/tidb-configuration-file.md
+++ b/tidb-configuration-file.md
@@ -504,7 +504,7 @@ TiDB 配置文件比命令行参数支持更多的选项。你可以在 [config/
+ TiDB 单个事务大小限制
+ 默认值：104857600
+ 单位：Byte
-+ 单个事务中，所有 key-value 记录的总大小不能超过该限制。该配置项的最大值不超过 `1099511627776`（表示 1TB）。注意，如果使用了以 `Kafka` 为下游消费者的 `binlog`，如：`arbiter` 集群，该配置项的值不能超过 `1073741824`（表示 1GB），因为这是 `Kafka` 的处理单条消息的最大限制，超过该限制 `Kafka` 将会报错。
++ 单个事务中，所有 key-value 记录的总大小不能超过该限制。该配置项的最大值不超过 `1099511627776`（表示 1TB）。
+ 在 v6.5.0 及之后的版本中，不再推荐使用该配置项，事务的内存大小会被累计计入所在会话的内存使用量中，并由 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 变量在单个会话内存超阈值时采取控制行为。为了向前兼容，由低版本升级至 v6.5.0 及更高版本时，该配置项的行为如下所述:
+ 若该配置项未设置，或设置为默认值 (`104857600`)，升级后事务内存大小将会计入所在会话的内存使用中，由 `tidb_mem_quota_query` 变量控制。
+ 若该配置项未设为默认值 (`104857600`)，升级前后该配置项仍生效，对单个事务大小的限制行为不会发生变化，事务内存大小不由 `tidb_mem_quota_query` 控制。
@@ -806,37 +806,6 @@ opentracing.reporter 相关的设置。
- Hash 对应的 slot 数量，自动向上调整为 2 的指数倍。每个 slot 占用 32 字节内存。如果设置过小，在数据写入范围较大的场景（如导入数据），可能会导致运行速度变慢，性能变差。
- 默认值：`2048000`
-## binlog
-
-TiDB Binlog 相关配置。
-
-### `enable`
-
-+ binlog 开关。
-+ 默认值：false
-
-### `write-timeout`
-
-+ 写 binlog 的超时时间，推荐不修改该值。
-+ 默认值：15s
-+ 单位：秒
-
-### `ignore-error`
-
-+ 忽略写 binlog 发生的错误时处理开关，推荐不修改该值。
-+ 默认值：false
-+ 如果设置为 `true`，发生错误时，TiDB 会停止写入 binlog，并且在监控项 `tidb_server_critical_error_total` 上计数加 1；如果设置为 `false`，写入 binlog 失败，会停止整个 TiDB 的服务。
-
-### `binlog-socket`
-
-+ binlog 输出网络地址。
-+ 默认值：""
-
-### `strategy`
-
-+ binlog 输出时选择 pump 的策略，仅支持 hash，range 方法。
-+ 默认值："range"
-
## status
TiDB 服务状态相关配置。
diff --git a/tidb-monitoring-framework.md b/tidb-monitoring-framework.md
index c80c0c2547ac..cefd129a0eeb 100644
--- a/tidb-monitoring-framework.md
+++ b/tidb-monitoring-framework.md
@@ -29,7 +29,6 @@ Grafana 是一个开源的 metric 分析及可视化系统。TiDB 使用 Grafana
- {TiDB_Cluster_name}-Backup-Restore：备份恢复相关的监控项。
-- {TiDB_Cluster_name}-Binlog：TiDB Binlog 相关的监控项。
- {TiDB_Cluster_name}-Blackbox_exporter：网络探活相关监控项。
- {TiDB_Cluster_name}-Disk-Performance：磁盘性能相关监控项。
- {TiDB_Cluster_name}-Kafka-Overview：Kafka 相关监控项。
diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md
index a6064b45b573..1df51432ac79 100644
--- a/tidb-troubleshooting-map.md
+++ b/tidb-troubleshooting-map.md
@@ -357,81 +357,11 @@ TiDB 支持完整的分布式事务，自 v3.0 版本起，提供乐观事务与
## 6. 生态 Tools 问题
-### 6.1 TiDB Binlog 问题
+### 6.1 DM 问题
-- 6.1.1 [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md)（已废弃）是将 TiDB 的修改同步给下游 TiDB 或者 MySQL 的工具，见 [TiDB Binlog on GitHub](https://github.com/pingcap/tidb-binlog)。
+- 6.1.1 TiDB Data Migration (DM) 是能将 MySQL/MariaDB 的数据迁移到 TiDB 的迁移工具，详情见 [DM 简介](/dm/dm-overview.md)。
-- 6.1.2 Pump/Drainer Status 中 Update Time 正常更新，日志中也没有异常，但下游没有数据写入。
-
- - TiDB 配置中没有开启 binlog，需要修改 TiDB 配置 `[binlog]`。
-
-- 6.1.3 Drainer 中的 sarama 报 `EOF` 错误。
-
- - Drainer 使用的 Kafka 客户端版本和 Kafka 版本不匹配，需要修改配置 `[syncer.to] kafka-version` 来解决。
-
-- 6.1.4 Drainer 写 Kafka 失败然后 panic，Kafka 报 `Message was too large` 错误。
-
- - binlog 数据太大，造成写 Kafka 的单条消息太大，需要修改 Kafka 的下列配置来解决：
-
- ```properties
- message.max.bytes=1073741824
- replica.fetch.max.bytes=1073741824
- fetch.message.max.bytes=1073741824
- ```
-
- 见案例 [case-789](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case789.md)。
-
-- 6.1.5 上下游数据不一致
-
- - 部分 TiDB 节点没有开启 binlog。v3.0.6 及之后的版本可以通过访问 接口可以检查所有节点的 binlog 状态。之前的版本可以通过查看配置文件来确认是否开启了 binlog。
-
- - 部分 TiDB 节点进入 ignore binlog 状态。v3.0.6 及之后的版本可以通过访问 接口可以检查所有节点的 binlog 状态。之前的版本需要看 TiDB 的日志中是否有 ignore binlog 关键字来确认是该问题。
-
- - 上下游 Timestamp 列的值不一致：
-
- - 时区问题，需要确保 Drainer 和上下游数据库时区一致，Drainer 通过 `/etc/localtime` 获取时区，不支持 `TZ` 环境变量，见案例 [case-826](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case826.md)。
-
- - TiDB 中 Timestamp 的默认值为 `null`，MySQL 5.7 中 Timestamp 默认值为当前时间（MySQL 8 无此问题），因此当上游写入 `null` 的 Timestamp 且下游是 MySQL 5.7 时，Timestamp 列数据不一致。在开启 binlog 前，在上游执行 `set @@global.explicit_defaults_for_timestamp=on;` 可解决此问题。
-
- - 其他情况[需报 bug](https://github.com/pingcap/tidb-binlog/issues/new?labels=bug&template=bug-report.md)。
-
-- 6.1.6 同步慢
-
- - 下游是 TiDB/MySQL，上游频繁进行 DDL 操作，见案例 [case-1023](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case1023.md)。
-
- - 下游是 TiDB/MySQL，需要同步的表中存在没有主键且没有唯一索引的表，这种情况会导致 binlog 性能下降，建议加主键或唯一索引。
-
- - 下游输出到文件，检查目标磁盘/网络盘是否慢。
-
- - 其他情况[需报 bug](https://github.com/pingcap/tidb-binlog/issues/new?labels=bug&template=bug-report.md)。
-
-- 6.1.7 Pump 无法写 binlog，报 `no space left on device` 错误。
-
- - 本地磁盘空间不足，Pump 无法正常写 binlog 数据。需要清理磁盘空间，然后重启 Pump。
-
-- 6.1.8 Pump 启动时报错 `fail to notify all living drainer`。
-
- - Pump 启动时需要通知所有 Online 状态的 Drainer，如果通知失败则会打印该错误日志。
-
- - 可以使用 binlogctl 工具查看所有 Drainer 的状态是否有异常，保证 Online 状态的 Drainer 都在正常工作。如果某个 Drainer 的状态和实际运行情况不一致，则使用 binlogctl 修改状态，然后再重启 Pump。见案例 [fail-to-notify-all-living-drainer](/tidb-binlog/handle-tidb-binlog-errors.md#pump-启动时报错-fail-to-notify-all-living-drainer)。
-
-- 6.1.9 Drainer 报错 `gen update sqls failed: table xxx: row data is corruption []`。
-
- - 触发条件：上游做 Drop Column DDL 的时候同时在做这张表的 DML。已经在 v3.0.6 修复，见 [case-820](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case820.md)。
-
-- 6.1.10 Drainer 同步卡住，进程活跃但 checkpoint 不更新。
-
- - 已知 bug 在 v3.0.4 修复，见案例 [case-741](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case741.md)。
-
-- 6.1.11 任何组件 `panic`。
-
- - [需报 bug](https://github.com/pingcap/tidb-binlog/issues/new?labels=bug&template=bug-report.md)。
-
-### 6.2 DM 问题
-
-- 6.2.1 TiDB Data Migration (DM) 是能将 MySQL/MariaDB 的数据迁移到 TiDB 的迁移工具，详情见 [DM 简介](/dm/dm-overview.md)。
-
-- 6.2.2 执行 `query-status` 或查看日志时出现 `Access denied for user 'root'@'172.31.43.27' (using password: YES)`。
+- 6.1.2 执行 `query-status` 或查看日志时出现 `Access denied for user 'root'@'172.31.43.27' (using password: YES)`。
- 在所有 DM 配置文件中，数据库相关的密码都必须使用经 dmctl 加密后的密文（若数据库密码为空，则无需加密）。在 v1.0.6 及以后的版本可使用明文密码。
@@ -439,7 +369,7 @@ TiDB 支持完整的分布式事务，自 v3.0 版本起，提供乐观事务与
- 同一套 DM 集群，混合部署不同版本的 DM-worker/DM-master/dmctl，见案例 [AskTUG-1049](https://asktug.com/t/dm1-0-0-ga-access-denied-for-user/1049/5)。
-- 6.2.3 DM 同步任务中断并包含 `driver: bad connection` 错误。
+- 6.1.3 DM 同步任务中断并包含 `driver: bad connection` 错误。
- 发生 `driver: bad connection` 错误时，通常表示 DM 到下游 TiDB 的数据库连接出现了异常（如网络故障、TiDB 重启等）且当前请求的数据暂时未能发送到 TiDB。
@@ -447,7 +377,7 @@ TiDB 支持完整的分布式事务，自 v3.0 版本起，提供乐观事务与
- 1.0.0 GA 版本，增加对此类错误的自动重试机制，见 [#265](https://github.com/pingcap/dm/pull/265)。
-- 6.2.4 同步任务中断并包含 `invalid connection` 错误。
+- 6.1.4 同步任务中断并包含 `invalid connection` 错误。
- 发生 `invalid connection` 错误时，通常表示 DM 到下游 TiDB 的数据库连接出现了异常（如网络故障、TiDB 重启、TiKV busy 等）且当前请求已有部分数据发送到了 TiDB。由于 DM 中存在同步任务并发向下游复制数据的特性，因此在任务中断时可能同时包含多个错误（可通过 `query-status` 或 `query-error` 查询当前错误）：
@@ -455,7 +385,7 @@ TiDB 支持完整的分布式事务，自 v3.0 版本起，提供乐观事务与
- 如果 DM 由于版本问题（v1.0.0-rc.1 后引入自动重试）等未自动进行重试或自动重试未能成功，则可尝试先使用 `stop-task` 停止任务，然后再使用 `start-task` 重启任务。
-- 6.2.5 Relay 处理单元报错 `event from * in * diff from passed-in event *` 或同步任务中断并包含 `get binlog error ERROR 1236 (HY000)`、`binlog checksum mismatch, data may be corrupted` 等 binlog 获取或解析失败错误。
+- 6.1.5 Relay 处理单元报错 `event from * in * diff from passed-in event *` 或同步任务中断并包含 `get binlog error ERROR 1236 (HY000)`、`binlog checksum mismatch, data may be corrupted` 等 binlog 获取或解析失败错误。
- 在 DM 进行 relay log 拉取与增量同步过程中，如果遇到了上游超过 4 GB 的 binlog 文件，就可能出现这两个错误。原因是 DM 在写 relay log 时需要依据 binlog position 及文件大小对 event 进行验证，且需要保存同步的 binlog position 信息作为 checkpoint。但是 MySQL binlog position 官方定义使用 uint32 存储，所以超过 4 GB 部分的 binlog position 的 offset 值会溢出，进而出现上面的错误。
@@ -463,7 +393,7 @@ TiDB 支持完整的分布式事务，自 v3.0 版本起，提供乐观事务与
- 对于 binlog replication 处理单元，可通过官网步骤进行[手动处理](/dm/dm-error-handling.md)。
-- 6.2.6 DM 同步中断，日志报错 `ERROR 1236 (HY000) The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.`。
+- 6.1.6 DM 同步中断，日志报错 `ERROR 1236 (HY000) The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.`。
- 检查 master 的 binlog 是否被 purge。
@@ -473,15 +403,15 @@ TiDB 支持完整的分布式事务，自 v3.0 版本起，提供乐观事务与
- relay.meta 中记录的 binlog event 不完整触发 recover 流程后记录错误的 GTID 信息，该问题可能会在 1.0.2 之前的版本遇到，已在 1.0.2 版本修复。
-- 6.2.7 DM 同步报错 `Error 1366: incorrect utf8 value eda0bdedb29d(\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd)`。
+- 6.1.7 DM 同步报错 `Error 1366: incorrect utf8 value eda0bdedb29d(\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd)`。
- 该值 MySQL 8.0 和 TiDB 都不能写入成功，但是 MySQL 5.7 可以写入成功。可以开启 TiDB 动态参数 `tidb_skip_utf8_check` 参数，跳过数据格式检查。
-### 6.3 TiDB Lightning 问题
+### 6.2 TiDB Lightning 问题
-- 6.3.1 TiDB Lightning 是快速的全量数据导入工具，见 [TiDB Lightning on GitHub](https://github.com/pingcap/tidb/tree/master/lightning)。
+- 6.2.1 TiDB Lightning 是快速的全量数据导入工具，见 [TiDB Lightning on GitHub](https://github.com/pingcap/tidb/tree/master/lightning)。
-- 6.3.2 导入速度太慢。
+- 6.2.2 导入速度太慢。
- `region-concurrency` 设定太高，线程间争用资源反而减低了效率。排查方法如下：
@@ -493,7 +423,7 @@ TiDB 支持完整的分布式事务，自 v3.0 版本起，提供乐观事务与
- TiDB Lightning 版本太旧。尝试使用最新的版本，可能会有改善。
-- 6.3.3 `checksum failed: checksum mismatched remote vs local`
+- 6.2.3 `checksum failed: checksum mismatched remote vs local`
- 原因 1：这张表可能本身已有数据，影响最终结果。
@@ -506,19 +436,19 @@ TiDB 支持完整的分布式事务，自 v3.0 版本起，提供乐观事务与
- 解决办法：参考[官网步骤处理](/tidb-lightning/troubleshoot-tidb-lightning.md#checksum-failed-checksum-mismatched-remote-vs-local)。
-- 6.3.4 `Checkpoint for … has invalid status:(错误码)`
+- 6.2.4 `Checkpoint for … has invalid status:(错误码)`
- 原因：断点续传已启用。TiDB Lightning 或 TiKV Importer 之前发生了异常退出。为了防止数据意外损坏，TiDB Lightning 在错误解决以前不会启动。错误码是小于 25 的整数，可能的取值是 0、3、6、9、12、14、15、17、18、20、21。整数越大，表示异常退出所发生的步骤在导入流程中越晚。
- 解决办法：参考[官网步骤](/tidb-lightning/troubleshoot-tidb-lightning.md#checkpoint-for--has-invalid-status错误码)处理。
-- 6.3.5 `cannot guess encoding for input file, please convert to UTF-8 manually`
+- 6.2.5 `cannot guess encoding for input file, please convert to UTF-8 manually`
- 原因：TiDB Lightning 只支持 UTF-8 和 GB-18030 编码的表架构。此错误代表数据源不是这里任一个编码。也有可能是文件中混合了不同的编码，例如在不同的环境运行过 `ALTER TABLE`，使表架构同时出现 UTF-8 和 GB-18030 的字符。
- 解决办法：参考[官网步骤](/tidb-lightning/troubleshoot-tidb-lightning.md#cannot-guess-encoding-for-input-file-please-convert-to-utf-8-manually)处理。
-- 6.3.6 `[sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 0 45 0 0}'`
+- 6.2.6 `[sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 0 45 0 0}'`
- 原因：一个 timestamp 类型的时间戳记录了不存在的时间值。时间值不存在是由于夏令时切换或超出支持的范围（1970 年 1 月 1 日至 2038 年 1 月 19 日）。
diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md
index 63f9e8b1afa3..8d2c2c9419f5 100644
--- a/tiup/tiup-cluster-topology-reference.md
+++ b/tiup/tiup-cluster-topology-reference.md
@@ -24,8 +24,6 @@ summary: 介绍通过 TiUP 部署或扩容 TiDB 集群时提供的拓扑文件
- [tikv_servers](/tiup/tiup-cluster-topology-reference.md#tikv_servers)：TiKV 实例的配置，用来指定 TiKV 组件部署到哪些机器上
- [tiflash_servers](/tiup/tiup-cluster-topology-reference.md#tiflash_servers)：TiFlash 实例的配置，用来指定 TiFlash 组件部署到哪些机器上
- [tiproxy_servers](#tiproxy_servers)：TiProxy 实例的配置，用来指定 TiProxy 组件部署到哪些机器上
-- [pump_servers](/tiup/tiup-cluster-topology-reference.md#pump_servers)：Pump 实例的配置，用来指定 Pump 组件部署到哪些机器上
-- [drainer_servers](/tiup/tiup-cluster-topology-reference.md#drainer_servers)：Drainer 实例的配置，用来指定 Drainer 组件部署到哪些机器上
- [cdc_servers](/tiup/tiup-cluster-topology-reference.md#cdc_servers)：CDC 实例的配置，用来指定 CDC 组件部署到哪些机器上
- [tispark_masters](/tiup/tiup-cluster-topology-reference.md#tispark_masters)：TiSpark Master 实例的配置，用来指定 TiSpark Master 组件部署到哪台机器上，仅允许部署一个 TiSpark Master 节点
- [tispark_workers](/tiup/tiup-cluster-topology-reference.md#tispark_workers)：TiSpark Worker 实例的配置，用来指定 TiSpark Worker 组件部署到哪些机器上
@@ -108,8 +106,6 @@ monitored:
- `tiflash`：TiFlash 服务的相关配置，支持的完整配置请参考 [TiFlash 配置参数](/tiflash/tiflash-configuration.md)
- `tiflash_learner`：每个 TiFlash 中内置了一个特殊的 TiKV，该配置项用于配置这个特殊的 TiKV，一般不建议修改这个配置项下的内容
- `tiproxy`：TiProxy 服务的相关配置，支持的完整配置请参考 [TiProxy 参数配置](/tiproxy/tiproxy-configuration.md)
-- `pump`：Pump 服务的相关配置，支持的完整配置请参考 [TiDB Binlog 配置说明](/tidb-binlog/tidb-binlog-configuration-file.md#pump)
-- `drainer`：Drainer 服务的相关配置，支持的完整配置请参考 [TiDB Binlog 配置说明](/tidb-binlog/tidb-binlog-configuration-file.md#drainer)
- `cdc`：CDC 服务的相关配置，支持的完整配置请参考 [TiCDC 安装部署](/ticdc/deploy-ticdc.md)
- `tso`：`tso` 微服务的相关配置，支持的完整配置请参考 [TSO 配置文件描述](/tso-configuration-file.md)
- `scheduling`：`scheduling` 微服务的相关配置，支持的完整配置请参考 [Scheduling 配置文件描述](/scheduling-configuration-file.md)
@@ -149,8 +145,6 @@ server_configs:
- `tiflash`：TiFlash 组件的版本
- `pd`：PD 组件的版本
- `tidb_dashboard`：独立部署的 TiDB Dashboard 组件的版本
-- `pump`：Pump 组件的版本
-- `drainer`：Drainer 组件的版本
- `cdc`：CDC 组件的版本
- `kvcdc`：TiKV-CDC 组件的版本
- `tiproxy`：TiProxy 组件的版本
@@ -371,90 +365,6 @@ tiproxy_servers:
- host: 10.0.1.22
```
-### `pump_servers`
-
-`pump_servers` 约定了将 TiDB Binlog 组件的 Pump 服务部署到哪些机器上，同时可以指定每台机器上的服务配置。`pump_servers` 是一个数组，每个数组元素包含以下字段：
-
-- `host`：指定部署到哪台机器，字段值填 IP 地址，不可省略
-- `ssh_port`：指定连接目标机器进行操作的时候使用的 SSH 端口，若不指定，则使用 `global` 区块中的 `ssh_port`
-- `port`：Pump 服务的监听端口，默认 8250
-- `deploy_dir`：指定部署目录，若不指定，或指定为相对目录，则按照 `global` 中配置的 `deploy_dir` 生成
-- `data_dir`：指定数据目录，若不指定，或指定为相对目录，则按照 `global` 中配置的 `data_dir` 生成
-- `log_dir`：指定日志目录，若不指定，或指定为相对目录，则按照 `global` 中配置的 `log_dir` 生成
-- `numa_node`：为该实例分配 NUMA 策略，如果指定了该参数，需要确保目标机装了 [numactl](https://linux.die.net/man/8/numactl)，在指定该参数的情况下会通过 [numactl](https://linux.die.net/man/8/numactl) 分配 cpubind 和 membind 策略。该字段参数为 string 类型，字段值填 NUMA 节点的 ID，例如 "0,1"
-- `config`：该字段配置规则和 `server_configs` 里的 `pump` 配置规则相同，若配置了该字段，会将该字段内容和 `server_configs` 里的 `pump` 内容合并（若字段重叠，以本字段内容为准），然后生成配置文件并下发到 `host` 指定的机器
-- `os`：`host` 字段所指定的机器的操作系统，若不指定该字段，则默认为 `global` 中的 `os`
-- `arch`：`host` 字段所指定的机器的架构，若不指定该字段，则默认为 `global` 中的 `arch`
-- `resource_control`：针对该服务的资源控制，如果配置了该字段，会将该字段和 `global` 中的 `resource_control` 内容合并（若字段重叠，以本字段内容为准），然后生成 systemd 配置文件并下发到 `host` 指定机器。`resource_control` 的配置规则同 `global` 中的 `resource_control`
-
-以上所有字段中，部分字段部署完成之后不能再修改。如下所示：
-
-- `host`
-- `port`
-- `deploy_dir`
-- `data_dir`
-- `log_dir`
-- `arch`
-- `os`
-
-`pump_servers` 配置示例：
-
-```yaml
-pump_servers:
- - host: 10.0.1.21
- config:
- gc: 7
- - host: 10.0.1.22
-```
-
-### `drainer_servers`
-
-`drainer_servers` 约定了将 TiDB Binlog 组件的 Drainer 服务部署到哪些机器上，同时可以指定每台机器上的服务配置，`drainer_servers` 是一个数组，每个数组元素包含以下字段：
-
-- `host`：指定部署到哪台机器，字段值填 IP 地址，不可省略
-- `ssh_port`：指定连接目标机器进行操作的时候使用的 SSH 端口，若不指定，则使用 `global` 区块中的 `ssh_port`
-- `port`：Drainer 服务的监听端口，默认 8249
-- `deploy_dir`：指定部署目录，若不指定，或指定为相对目录，则按照 `global` 中配置的 `deploy_dir` 生成
-- `data_dir`：指定数据目录，若不指定，或指定为相对目录，则按照 `global` 中配置的 `data_dir` 生成
-- `log_dir`：指定日志目录，若不指定，或指定为相对目录，则按照 `global` 中配置的 `log_dir` 生成
-- `commit_ts`：[已废弃]Drainer 启动的时候会去读取 checkpoint，如果读取不到，就会使用该字段做为初次启动开始的同步时间点，该字段默认为 -1（从 PD 总获取最新时间戳作为 commit_ts）
-- `numa_node`：为该实例分配 NUMA 策略，如果指定了该参数，需要确保目标机装了 [numactl](https://linux.die.net/man/8/numactl)，在指定该参数的情况下会通过 [numactl](https://linux.die.net/man/8/numactl) 分配 cpubind 和 membind 策略。该字段参数为 string 类型，字段值填 NUMA 节点的 ID，例如 "0,1"
-- `config`：该字段配置规则和 `server_configs` 里的 `drainer` 配置规则相同，若配置了该字段，会将该字段内容和 `server_configs` 里的 `drainer` 内容合并（若字段重叠，以本字段内容为准），然后生成配置文件并下发到 `host` 指定的机器
-- `os`：`host` 字段所指定的机器的操作系统，若不指定该字段，则默认为 `global` 中的 `os`
-- `arch`：`host` 字段所指定的机器的架构，若不指定该字段，则默认为 `global` 中的 `arch`
-- `resource_control`：针对该服务的资源控制，如果配置了该字段，会将该字段和 `global` 中的 `resource_control` 内容合并（若字段重叠，以本字段内容为准），然后生成 systemd 配置文件并下发到 `host` 指定机器。`resource_control` 的配置规则同 `global` 中的 `resource_control`
-
-以上所有字段中，部分字段部署完成之后不能再修改。如下所示：
-
-- `host`
-- `port`
-- `deploy_dir`
-- `data_dir`
-- `log_dir`
-- `arch`
-- `os`
-
-其中 `commit_ts` 字段自 tiup cluster v1.9.2 开始已经废弃，不再被记录到 drainer 的启动脚本中。如果你仍需要配置该参数，请参照下面的示例在 `config` 中配置 `initial-commit-ts` 字段。
-
-`drainer_servers` 配置示例：
-
-```yaml
-drainer_servers:
- - host: 10.0.1.21
- config:
- initial-commit-ts: -1
- syncer.db-type: "mysql"
- syncer.to.host: "127.0.0.1"
- syncer.to.user: "root"
- syncer.to.password: ""
- syncer.to.port: 3306
- syncer.ignore-table:
- - db-name: test
- tbl-name: log
- - db-name: test
- tbl-name: audit
-```
-
### `cdc_servers`
`cdc_servers` 约定了将 TiCDC 服务部署到哪些机器上，同时可以指定每台机器上的服务配置，`cdc_servers` 是一个数组，每个数组元素包含以下字段：
diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md
index c901de28de56..693270544bb0 100644
--- a/tiup/tiup-cluster.md
+++ b/tiup/tiup-cluster.md
@@ -237,11 +237,11 @@ Status 列用 `Up` 或者 `Down` 表示该服务是否正常。对于 PD 组件
缩容即下线服务，最终会将指定的节点从集群中移除，并删除遗留的相关文件。
-由于 TiKV、TiFlash 和 TiDB Binlog 组件的下线是异步的（需要先通过 API 执行移除操作）并且下线过程耗时较长（需要持续观察节点是否已经下线成功），所以对 TiKV、TiFlash 和 TiDB Binlog 组件做了特殊处理：
+由于 TiKV 和 TiFlash 组件的下线是异步的（需要先通过 API 执行移除操作）并且下线过程耗时较长（需要持续观察节点是否已经下线成功），所以对 TiKV 和 TiFlash 组件做了特殊处理：
-- 对 TiKV、TiFlash 及 Binlog 组件的操作
+- 对 TiKV 和 TiFlash 组件的操作
- TiUP cluster 通过 API 将其下线后直接退出而不等待下线完成
- - 等之后再执行集群操作相关的命令时，会检查是否存在已经下线完成的 TiKV、TiFlash 或者 Binlog 节点。如果不存在，则继续执行指定的操作；如果存在，则执行如下操作：
+ - 等之后再执行集群操作相关的命令时，会检查是否存在已经下线完成的 TiKV 或者 TiFlash 节点。如果不存在，则继续执行指定的操作；如果存在，则执行如下操作：
1. 停止已经下线掉的节点的服务
2. 清理已经下线掉的节点的相关数据文件
3. 更新集群的拓扑，移除已经下线掉的节点
@@ -607,7 +607,7 @@ tiup cluster exec test-cluster --command='ls /tmp'
```bash
Usage:
- tiup ctl:v {tidb/pd/tikv/binlog/etcd} [flags]
+ tiup ctl:v {tidb/pd/tikv/etcd} [flags]
Flags:
-h, --help help for tiup
@@ -619,7 +619,6 @@ Flags:
tidb-ctl [args] = tiup ctl tidb [args]
pd-ctl [args] = tiup ctl pd [args]
tikv-ctl [args] = tiup ctl tikv [args]
-binlogctl [args] = tiup ctl bindlog [args]
etcdctl [args] = tiup ctl etcd [args]
```
diff --git a/tiup/tiup-component-cluster-patch.md b/tiup/tiup-component-cluster-patch.md
index 95be6a84d2de..1bd26758a592 100644
--- a/tiup/tiup-component-cluster-patch.md
+++ b/tiup/tiup-component-cluster-patch.md
@@ -8,7 +8,7 @@ summary: tiup cluster patch 命令用于在集群运行过程中动态替换某
在集群运行过程中，如果需要动态替换某个服务的二进制文件（即替换过程中保持集群可用），那么可以使用 `tiup cluster patch` 命令，它会完成以下几件事情：
- 将用于替换的二进制包上传到目标机器
-- 如果目标服务是 TiKV、TiFlash 或者 TiDB Binlog 之类的存储服务，则先通过 API 下线节点
+- 如果目标服务是 TiKV 或者 TiFlash 之类的存储服务，则先通过 API 下线节点
- 停止目标服务
- 解压二进制包，替换服务
- 启动目标服务
diff --git a/tiup/tiup-component-cluster-scale-in.md b/tiup/tiup-component-cluster-scale-in.md
index d91defbe96d6..90c7496fb188 100644
--- a/tiup/tiup-component-cluster-scale-in.md
+++ b/tiup/tiup-component-cluster-scale-in.md
@@ -1,6 +1,6 @@
---
title: tiup cluster scale-in
-summary: tiup cluster scale-in 命令用于集群缩容，包括下线 TiKV、TiFlash 和 TiDB Binlog 组件，以及其他组件。特殊处理包括通过 API 执行移除操作，并清理相关数据文件。命令语法为 tiup cluster scale-in ，必须指定要缩容的节点。其他选项包括 --force 用于强制移除宕机节点，--transfer-timeout 设置最长等待时间，-h 输出帮助信息。输出为缩容日志。
+summary: tiup cluster scale-in 命令用于集群缩容，包括下线 TiKV 和 TiFlash 组件，以及其他组件。特殊处理包括通过 API 执行移除操作，并清理相关数据文件。命令语法为 tiup cluster scale-in ，必须指定要缩容的节点。其他选项包括 --force 用于强制移除宕机节点，--transfer-timeout 设置最长等待时间，-h 输出帮助信息。输出为缩容日志。
---
# tiup cluster scale-in
@@ -9,9 +9,9 @@ summary: tiup cluster scale-in 命令用于集群缩容，包括下线 TiKV、Ti
## 下线特殊处理
-由于 TiKV，TiFlash 和 TiDB Binlog 组件的下线是异步的（需要先通过 API 执行移除操作）并且下线过程耗时较长（需要持续观察节点是否已经下线成功），所以对 TiKV，TiFlash 和 TiDB Binlog 组件做了特殊处理：
+由于 TiKV 和 TiFlash 组件的下线是异步的（需要先通过 API 执行移除操作）并且下线过程耗时较长（需要持续观察节点是否已经下线成功），所以对 TiKV 和 TiFlash 组件做了特殊处理：
-- 对 TiKV，TiFlash 及 TiDB Binlog 组件的操作:
+- 对 TiKV 和 TiFlash 组件的操作
- tiup-cluster 通过 API 将其下线后直接退出而不等待下线完成
- 执行 `tiup cluster display` 查看下线节点的状态，等待其状态变为 Tombstone
- 执行 `tiup cluster prune` 命令清理 Tombstone 节点，该命令会执行以下操作：
diff --git a/tiup/tiup-playground.md b/tiup/tiup-playground.md
index 9b1e5bd40670..13291e6d362a 100644
--- a/tiup/tiup-playground.md
+++ b/tiup/tiup-playground.md
@@ -34,9 +34,6 @@ Flags:
--db.binpath string 指定 TiDB 二进制文件的位置（开发调试用，可忽略）
--db.config string 指定 TiDB 的配置文件（开发调试用，可忽略）
--db.timeout int 指定 TiDB 最长等待超时时间，单位为秒。若配置为 0，则永不超时。
- --drainer int 设置集群中 Drainer 数据
- --drainer.binpath string 指定 Drainer 二进制文件的位置（开发调试用，可忽略）
- --drainer.config string 指定 Drainer 的配置文件
-h, --help 打印帮助信息
--host string 设置每个组件的监听地址（默认为 127.0.0.1），如果要提供给别的电脑访问，可设置为 0.0.0.0
--kv int 设置集群中 TiKV 节点的数量（默认为1）
@@ -48,9 +45,6 @@ Flags:
--pd.binpath string 指定 PD 二进制文件的位置（开发调试用，可忽略）
--pd.config string 指定 PD 的配置文件（开发调试用，可忽略）
--pd.mode string 指定 PD 的工作模式，取值选项为 'ms'。指定该参数代表启用 PD 微服务模式。
- --pump int 设置集群中 Pump 节点的数量（非 0 的时候 TiDB 会开启 TiDB Binlog）
- --pump.binpath string 指定 Pump 二进制文件的位置（开发调试用，可忽略）
- --pump.config string 指定 Pump 的配置文件（开发调试用，可忽略）
--scheduling int 设置集群中 Scheduling 节点的数量（默认为 1），只能在 pd.mode 为 'ms' 的时候设置
--scheduling.host host 指定 Scheduling 节点的监听地址
--scheduling.binpath string 指定 Scheduling 节点上二进制文件的位置（开发调试用，可忽略）
@@ -175,10 +169,8 @@ Pid Role Uptime
--- ---- ------
84518 pd 35m22.929404512s
84519 tikv 35m22.927757153s
-84520 pump 35m22.92618275s
86189 tidb exited
86526 tidb 34m28.293148663s
-86190 drainer 35m19.91349249s
```
## 扩容集群
diff --git a/transaction-overview.md b/transaction-overview.md
index a0bb8969cccb..b98531f19c82 100644
--- a/transaction-overview.md
+++ b/transaction-overview.md
@@ -297,12 +297,6 @@ TiDB 中，单个事务的总大小默认不超过 100 MB，这个默认值可
在 4.0 以前的版本，TiDB 限制了单个事务的键值对的总数量不超过 30 万条，从 4.0 版本起 TiDB 取消了这项限制。
-> **注意：**
->
-> 通常，用户会开启 [TiDB Binlog](/tidb-binlog/tidb-binlog-overview.md)（已废弃）将数据向下游进行同步。某些场景下，用户会使用消息中间件来消费同步到下游的 binlog，例如 Kafka。
->
-> 以 Kafka 为例，Kafka 的单条消息处理能力的上限是 1 GB。因此，当把 `txn-total-size-limit` 设置为 1 GB 以上时，可能出现事务在 TiDB 中执行成功，但下游 Kafka 报错的情况。为避免这种情况出现，请用户根据最终消费者的限制来决定 `txn-total-size-limit` 的实际大小。例如：下游使用了 Kafka，则 `txn-total-size-limit` 不应超过 1 GB。
-
## 因果一致性事务
> **注意：**
diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md
index 1437ad9b92d5..4f7daf42bac6 100644
--- a/upgrade-tidb-using-tiup.md
+++ b/upgrade-tidb-using-tiup.md
@@ -62,7 +62,7 @@ summary: TiUP 可用于 TiDB 升级。升级过程中需注意不支持 TiFlash
2. 然后按照 [4.0 版本文档的说明](https://docs.pingcap.com/zh/tidb/v4.0/upgrade-tidb-using-tiup)，使用 TiUP (`tiup cluster`) 将 TiDB Ansible 配置导入。
3. 将集群升级至 v4.0 版本。
4. 按本文档说明将集群升级到 v8.3.0 版本。
-- 支持 TiDB Binlog（已废弃），TiCDC，TiFlash 等组件版本的升级。
+- 支持 TiCDC，TiFlash 等组件版本的升级。
- 将 v6.3.0 之前的 TiFlash 升级至 v6.3.0 及之后的版本时，需要特别注意：在 Linux AMD64 架构的硬件平台部署 TiFlash 时，CPU 必须支持 AVX2 指令集。而在 Linux ARM64 架构的硬件平台部署 TiFlash 时，CPU 必须支持 ARMv8 架构。具体请参考 [6.3.0 版本 Release Notes](/releases/release-6.3.0.md#其他) 中的描述。
- 具体不同版本的兼容性说明，请查看各个版本的 [Release Note](/releases/release-notes.md)。请根据各个版本的 Release Note 的兼容性更改调整集群的配置。
- 升级 v5.3 之前版本的集群到 v5.3 及后续版本时，默认部署的 Prometheus 生成的 Alert 存在时间格式变化。该格式变化是从 Prometheus v2.27.1 开始引入的，详情见 [Prometheus commit](https://github.com/prometheus/prometheus/commit/7646cbca328278585be15fa615e22f2a50b47d06)。
@@ -221,7 +221,6 @@ tiup cluster upgrade v8.3.0
> - 使用 `--force` 参数可以在不驱逐 leader 的前提下快速升级集群至新版本，但是该方式会忽略所有升级中的错误，在升级失败后得不到有效提示，请谨慎使用。
> - 如果希望保持性能稳定，则需要保证 TiKV 上的所有 leader 驱逐完成后再停止该 TiKV 实例，可以指定 `--transfer-timeout` 为一个更大的值，如 `--transfer-timeout 3600`，单位为秒。
> - 如需将 TiFlash 从 v5.3.0 之前的版本升级到 v5.3.0 及之后的版本，必须进行 TiFlash 的停机升级，且 TiUP 版本小于 v1.12.0。具体升级步骤，请参考[使用 TiUP 升级](/tiflash-upgrade-guide.md#使用-tiup-升级)。
-> - 在对使用 TiDB Binlog 的集群进行滚动升级过程中，请避免新创建聚簇索引表。
#### 升级时指定组件版本