最新信息： 和研发一起排查，发现数据有写入到kakfa，是从kafka消费时出错了。 不过问题再问下： 上述event feed resolve lock fail，event feed finds slow locked ranges 等，是否可能引起CDC同步丢数据？

CDC中日志： 1） 研发反馈有问题的写入时间的日志 02:31左右,feed-id: upload-pic CDC_机器A： [image] CDC机器B： 有些WARN: event feed finds slow locked ranges [image] 2)全部 02:00～03:00 warn信息 CDC机器A日志： cat ~/Downloads/cdc-20250723-10.28.232.3-backup_s.log |egrep “warn|error” -i |grep ‘upload-pic’ |grep -v ‘atpub-upload-pic’…

是通的。

用export AWS_ACCESS_KEY_ID=xx export AWS_SECRET_ACCESS_KEY=xx 。 进度为0%时 br日志情况： cat testtidb001_back20250708-bakck3.log |grep error -i [2025/07/08 20:16:38.228 +08:00] [INFO] [manager.go:292] [“failed to campaign”] [“owner info”=“[log-backup] /tidb/br-stream/owner ownerManager 28e0ed8d-dc32-4ba3-a…

1）有类似事件 [image] 2）研发改代码解决的。 Map<String, Object> item = Maps.newHashMap(); for(Map.Entry<String,Object> entry: item1.entrySet()){ String key = entry.getKey(); Object value = entry.getValue(); if (value != null && value instanceof byte){ value = new String((byte) value, StandardCharsets.UTF_8…

多谢，这种select version()是版本变了。 select version(); ±-------------------+ | version() | ±-------------------+ | 5.7.25-TiDB-v5.1.4 | ±-------------------+ 1 row in set (0.00 sec) 配置： server_configs: tidb: binlog.enable: false server-version: 5.7.25-TiDB-v5.1.4

https://docs.pingcap.com/zh/tidb/v7.5/system-variables/#version version 作用域：NONE 是否受 Hint SET_VAR 控制：否 默认值：8.0.11-TiDB-(tidb version) 这个变量的值是 MySQL 的版本和 TiDB 的版本，例如 ‘8.0.11-TiDB-v7.5.6’。 == version 好象是一个只读参数，无法修改。 [image]

<mysql-connector-java.version>5.1.38</mysql-connector-java.version> jdbcTemplate来自Spring-jdbc5.2.7 connection = Objects.requireNonNull(jdbcTemplate.getDataSource()).getConnection(); statement = connection.prepareStatement(sql, ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY); Map<Str…

使用Python， 及原生的mysql 客户端，查询TiDB5.1/TIDB7.5结果都是相同的，不存在研发反馈的问题。 MySQL: [image] [image] Python: SQL="SELECT ‘10.8.5’ AS se_version,‘0’ AS se_city,a.modified_stime,‘business’ AS se_business_type,a.ext_json ->>‘$.data_type’ as data_type FROM tb_car_pool a LEFT JOIN resource_pool_merge.uniq_nlp_tags…

问下Deep seek中的方法2，是可行的么？ [image]

多谢。 我也是这样做的。 tiup cluster stop xxcluster -N “xx:8249” 修改drainer.conf ignore-txn-commit-ts = [日志中的commit_ts] #skip txn关键字 tiup cluster start xxcluster -N “xx:8249”

[2025/03/12 20:41:25.722 +08:00] [INFO] [region_cache.go:961] [“switch region peer to next due to NotLeader with NULL leader”] [currIdx=2] [regionID=306397639] [2025/03/12 20:41:25.723 +08:00] [INFO] [region_range_lock.go:222] [“range locked”] [changefeed=jxs-to-jxsclusterlf] [lockID=1149] [regionI…

是漏了。

阈值与健康范围 正常场景： 理想值：TSO Wait Duration 应稳定在 ≤ 1ms（同一机房内 PD 与 TiDB 直连）。 可接受范围：若跨低延迟网络（如同城专线），建议控制在 ≤ 5ms。超过此值需排查。 风险阈值： 警告线：持续超过 10ms 可能导致事务冲突率升高、AP 查询排队堆积。 临界线：偶发尖峰超过 50ms 可能直接触发客户端超时（需紧急处理）。

时延情况： [image] [image]

Ticdc中日志信息： [2025/01/26 02:19:24.727 +08:00] [INFO] [region_worker.go:243] [“single region event feed disconnected”] [changefeed=auto-order] [regionID=277934170] [requestID=23125] [span=“[748000000000005aff295f72800000001aff87d4b60000000000fa, 748000000000005aff295f72800000001aff8b0dc80000000000fa)…

CDC中设置为10M，是否有可能会有大的SQL过来>10M ,而导致同步失败的情况？ max-batch-size=256 这个还要改不？

官方FAQ：https://docs.pingcap.com/zh/tidb/stable/ticdc-faq 另外有一个类似的贴： TICDC 同步 kafka 异常 - #8，来自 友利奈绪

您是哪个版本，我的是7.5.3