diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md
index 556fe574ecb7..5c625a51e75b 100644
--- a/ticdc/ticdc-faq.md
+++ b/ticdc/ticdc-faq.md
@@ -489,4 +489,20 @@ UPDATE data_table SET value = 'v1' WHERE id = 2;
 mysql://user:password@host:port/?safe-mode=true
 ```
 
-在安全模式下，TiCDC 会将 `UPDATE` 操作拆分为 `DELETE + REPLACE INTO` 进行执行，从而避免唯一键冲突错误。
\ No newline at end of file
+在安全模式下，TiCDC 会将 `UPDATE` 操作拆分为 `DELETE + REPLACE INTO` 进行执行，从而避免唯一键冲突错误。
+
+## 为什么 TiCDC 同步到 Kafka 的任务经常因为 “broken pipe” 报错而失败？
+
+TiCDC 同步数据到 Kafka 时使用了 Sarama 客户端。出于防止数据乱序的考虑，TiCDC 禁用了 Sarama 的自动重试机制（将重试次数设为 0）。这样一来，如果 TiCDC 和 Kafka 之间的连接在空闲一段时间后被 Kafka 主动关闭，后续写入数据时就会报 `write: broken pipe` 错误，导致同步任务失败。
+
+虽然 Changefeed 会因为报错而失败，但 TiCDC 会自动重启该 Changefeed，任务仍可继续正常运行。需要注意的是，在重启的过程中，Changefeed 的同步延迟（lag）可能会出现一次性的小幅增加，通常在 30 秒以内，之后会自动恢复正常。
+
+如果用户对 Changefeed 的延迟非常敏感的话，建议将 Kafka 的连接空闲超时时间调大，例如配置：
+
+```properties
+connections.max.idle.ms=86400000  # 设置为 1 天
+```
+
+然后重启 Kafka 以使配置生效，从而避免连接被提前关闭，减少 broken pipe 报错。
+
+具体设置多长时间，建议根据业务实际的数据同步情况进行调整：如果 TiCDC Changefeed 在几十分钟内一定会有数据同步发生，那么可以将 `connections.max.idle.ms` 设置为几十分钟即可，无需设置过大。
diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md
index 4f211638d80e..d10020377bc4 100644
--- a/ticdc/ticdc-sink-to-kafka.md
+++ b/ticdc/ticdc-sink-to-kafka.md
@@ -111,6 +111,7 @@ URI 中可配置的的参数如下：
 * TiCDC 推荐用户自行创建 Kafka Topic，你至少需要设置该 Topic 每次向 Kafka broker 发送消息的最大数据量和下游 Kafka partition 的数量。在创建 changefeed 的时候，这两项设置分别对应 `max-message-bytes` 和 `partition-num` 参数。
 * 如果你在创建 changefeed 时，使用了尚未存在的 Topic，那么 TiCDC 会尝试使用 `partition-num` 和 `replication-factor` 参数自行创建 Topic，建议明确指定这两个参数。
 * 在大多数情况下，建议使用 `canal-json` 协议。
+* 如果消息量很少，比如可能会出现超过 10 分钟没有数据变更的情况，建议在 Kafka Broker 的配置中加上 `connections.max.idle.ms=86400000`，具体细节可参看[为什么 TiCDC 同步到 Kafka 的任务经常因为 “broken pipe” 报错而失败？](/ticdc/ticdc-faq.md#为什么-TiCDC-同步到-Kafka-的任务经常因为-“broken-pipe”-报错而失败？)
 
 > **注意：**
 >