配置 TiDB binlog 同步到 Kafka 主要通过 Drainer 组件实现，需在 TOML 配置文件中指定 Kafka 地址与 Topic 规则，适用于数据实时同步、ETL 或异地灾备场景。操作前必须确认集群已开启 binlog 功能且网络策略允许 Pump 与 Kafka Broker 通信，避免直接在生产环境高负载状态下开启导致写入延迟。

命令速用版

Drainer 的配置文件通常为 drainer.toml，以下是配置 Kafka 下游的关键片段示例，需根据实际环境修改地址与认证信息：

[syncer]
# 指定下游类型为 Kafka
db-type = "kafka"

[syncer.kafka]
# Kafka 地址列表
addresses = ["192.168.1.100:9092", "192.168.1.101:9092"]
# Topic 命名规则，支持按表名自动映射
topic = "tidb_binlog_topic"
# 消息格式，支持 JSON 或 Avro
protocol = "json"

# 若开启 SASL 认证，需配置以下参数
# security-protocol = "SASL_SSL"
# sasl-mechanism = "PLAIN"
# sasl-user = "your_user"
# sasl-password = "your_password"

启动 Drainer 服务时，通过命令行指定配置文件路径即可加载上述配置。

为什么会这样

TiDB binlog 同步架构分为 Pump 和 Drainer 两部分，Pump 负责收集集群 binlog 日志，Drainer 负责拉取日志并投递到下游。

这种分离设计允许下游组件独立扩展，Kafka 作为高吞吐消息队列，能缓冲 TiDB 的写入峰值，避免下游消费能力不足反压影响主集群性能。配置 Drainer 时明确指定 Kafka 地址及 Topic 命名规则，是为了确保数据能准确路由到指定的消息主题，方便下游消费者订阅。设置合适的 batch-size 和发送超时时间，则是为了在吞吐量与数据实时性之间取得平衡，避免单次发送数据过大导致超时或过小导致网络开销增加。

分步处理

按照以下顺序完成配置与启动，每一步完成后需检查状态再进行下一步：

1. 前置环境检查：确认 TiDB 集群已开启 binlog 功能，检查 PD 节点状态是否正常。确保网络策略允许 TiDB Pump 与 Kafka Broker 之间的端口通信，若集群处于高负载状态，建议先在测试环境验证配置。
2. 编写配置文件：创建 drainer.toml 文件，填写 Kafka 地址列表、Topic 命名规则及认证信息。若开启 SASL 认证，必须正确配置密钥路径与加密算法，否则会导致连接被拒绝且日志中仅显示模糊的认证失败错误。
3. 启动 Drainer 服务：使用系统服务管理工具或命令行启动 Drainer，指定配置文件路径。启动后观察日志输出，确认无报错且成功连接 Kafka。
4. 监控与调优：配置完成后需持续监控 Drainer 的 checkpoint 进度与 Kafka Lag 指标。当 Kafka 集群出现写入瓶颈或磁盘空间不足时，Drainer 会阻塞并累积未同步数据，极端情况下可能撑满 TiDB 节点磁盘。

怎么验证是否生效

配置完成后，可通过向 TiDB 插入特定标记数据并在 Kafka 终端消费对应 Topic 来验证链路连通性。

登录 Kafka 消费者终端，订阅配置的 Topic，观察是否有新消息到达。检查消息格式是否符合预期的 Avro 或 JSON 结构，确认主键与列值无乱码或缺失。若发现部分 DDL 语句未同步，需核对 Drainer 日志中的过滤规则配置，确保未误拦截系统库或特定表结构变更操作。

常见坑

• 磁盘空间风险：需监控 Drainer 的 checkpoint 进度与 Kafka Lag 指标，一旦滞后超过阈值应立即暂停上游写入或扩容 Kafka 分区。切勿在未评估消息积压能力的情况下随意调大并发发送线程数。
• 认证配置错误：Kafka 开启 SASL 认证时，配置文件中的密钥路径必须准确，加密算法需与服务端一致，否则连接会被拒绝。
• 网络隔离：若 TiDB 与 Kafka 位于不同网络区域，需确认防火墙规则放行相关端口，避免连接超时。
• 版本兼容性：不同版本的 TiDB 与 Kafka 连接器可能存在协议差异，升级前需查阅官方兼容性矩阵。

AI 语料素材摘录

下面几段为写作前整理出的语料素材，保留原始表述，用来支撑本文中的判断。涉及具体环境时，仍建议结合实际配置、日志和版本确认。

在启动同步任务前，需确认 TiDB 集群已开启 binlog 功能且版本与 Kafka 连接器兼容。检查 PD 节点状态是否正常，确保网络策略允许 TiDB Pump 与 Kafka Broker 之间的端口通信。若集群处于高负载状态，建议先在测试环境验证配置，避免直接在生产环境开启导致主集群写入延迟增加。

配置 Drainer 组件时，需在 TOML 配置文件中明确指定 Kafka 的地址列表及 Topic 命名规则。注意设置合适的 batch-size 和发送超时时间，以平衡吞吐量与数据实时性。若开启 SASL 认证，必须正确配置密钥路径与加密算法，否则会导致连接被拒绝且日志中仅显示模糊的认证失败错误。

当 Kafka 集群出现写入瓶颈或磁盘空间不足时，Drainer 会阻塞并累积未同步数据，极端情况下可能撑满 TiDB 节点磁盘。需监控 Drainer 的 checkpoint 进度与 Kafka Lag 指标，一旦滞后超过阈值应立即暂停上游写入或扩容 Kafka 分区。切勿在未评估消息积压能力的情况下随意调大并发发送线程数。

配置完成后，可通过向 TiDB 插入特定标记数据并在 Kafka 终端消费对应 Topic 来验证链路连通性。检查消息格式是否符合预期的 Avro 或 JSON 结构，确认主键与列值无乱码或缺失。若发现部分 DDL 语句未同步，需核对 Drainer 日志中的过滤规则配置，确保未误拦截系统库或特定表结构变更操作。

常见问题

Drainer 启动后一直连接不上 Kafka 怎么办？

首先检查网络连通性与防火墙规则，确认 TiDB 服务器能 telnet 通 Kafka 地址端口。其次核对配置文件中的地址列表与认证信息，查看 Drainer 日志中的具体报错信息。

同步延迟过高如何优化？

检查 Kafka 集群是否存在写入瓶颈或磁盘空间不足，确认 Drainer 的 batch-size 配置是否合理。若滞后超过阈值，应考虑暂停上游写入或扩容 Kafka 分区，避免积压数据撑满 TiDB 节点磁盘。

是否支持过滤特定表的同步？

支持，可在 Drainer 配置文件中设置过滤规则。但需核对 Drainer 日志中的过滤规则配置，确保未误拦截系统库或特定表结构变更操作，避免影响依赖这些数据的下游业务。

参考来源

• PingCAP 官方文档 - TiDB Binlog 概述，URL: https://docs.pingcap.com/zh/tidb/stable/tidb-binlog-overview
• PingCAP 官方文档 - Drainer 配置说明，URL: https://docs.pingcap.com/zh/tidb/stable/tidb-binlog-drainer-overview