为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。
- 【TiDB 版本】：4.0.0
- 【问题描述】：drainer服务如果碰到错误，会不会drainer自己跳过这个错误，开始同步下一条数据，还是说会停留在原地，等待人工处理？
图片上面前面出错了，后面怎么继续同步了？
图片上面前面出错了，后面怎么继续同步了？
你好，
当前日志中看到的错误信息为 ‘invalid connection’ 确认下下游链接是否正常，如果链接异常，为了保证数据一致性，目前不会自动跳过。
下游连接还在确认，就是我在想，drainer碰到错误，应该反复报错同一个sql才对，怎么还报错不同的sql，所以我怀疑，它是不是自己跳过了那个错误开始执行下一个committs了
如果下游异常，drainer 会有重试机制，下游恢复后，可以继续同步。 当前还有其他报错吗？
之后还报了主键冲突的错误，我们去查看下游tidb那个时候 tidb报
，重试机制为什么会切换不同的sql，是否和我们有三个pump有关系。
主键冲突，这个错误我感觉不应该有这个错误，因为数据可以正常进入上游tidb，就不应该在同步到下游的时候报主键冲突，我感觉是不是pump集群里面会产生重复的binlog放在不同pump节点
从您的截图里，我没有看到主键冲突，麻烦上传drainer这段报错时间的 文本文件，多谢。
辛苦確認下游 seeyii_assets_database.* 是否只會由 binlog drainer 寫入？
duplicate entry 有 835 條但全都是 29757450…29757477, 应该是 drainer 在 retry 同一個 transaction。
可以上传下 ｓｈｏｗ ｆｕｌｌ ｐｒｏｃｅｓｓｌｉｓｔ； 到文件并上传下
现在执行show full processlist；已经看不到结果了。确认只有drainer写入下游数据库。出现这个现象不知道是不是和我pump集群有关系，不同节点保存了相同的binlog日志
你好，
多个 pump 不是连接一个 mysql 上游嘛