ticdc 从库数据被截断

🪐 TiDB 技术问题
1

一个好的问题描述有利于社区小伙伴更快帮你定位到问题，高效解决你的问题

【TiDB 使用环境】生产环境 /测试环境
【TiDB 版本】
【部署方式】云上部署（什么云）/机器部署
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
上下游表结构，A字段长度不一致，上游长度10，下游长度5，输入长度为10的字符串，下游截断为5,ticdc有没有严格模式，让直接报错。
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】

2

SELECT @@sql_mode; 检查是否包含严格模式标识

3

建议检查下游MySQL的sql_mode设置，开启STRICT_TRANS_TABLES模式。TiCDC本身没有严格模式参数，但下游数据库的严格模式会阻止截断插入。

4

默认就包含严格模式。ticdc好像强制设置会话级的sql_mode了。
[2026/07/30 08:57:15.403 +08:00] [INFO] [helper.go:277] [“sink uri is configured”] [dsn=“my_sync:******@tcp(10.0.40.122:4001)/?interpolateParams=true&multiSt
atements=true&allow_auto_random_explicit_insert=1&charset=utf8mb4&foreign_key_checks=0&maxAllowedPacket=0&readTimeout=2m&sql_mode=%22NO_ENGINE_SUBSTITUTION%2
CALLOW_INVALID_DATES%2CIGNORE_SPACE%2CONLY_FULL_GROUP_BY%2CNO_AUTO_VALUE_ON_ZERO%22&tidb_cdc_write_source=1&tidb_enable_external_ts_read=%22OFF%22&tidb_place
ment_mode=%22ignore%22&tidb_txn_mode=optimistic&timeout=2m&transaction_isolation=%22READ-COMMITTED%22&writeTimeout=2m”]
MySQL [test]> SELECT @@sql_mode;
±------------------------------------------------------------------------------------------------------------------------------------------+
| @@sql_mode |
±------------------------------------------------------------------------------------------------------------------------------------------+
| ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
±------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.000 sec)

5
  • TiCDC 自身没有独立的 “字段超长严格校验开关”，是否截断 / 报错，由下游数据库的 sql_mode + TiCDC 默认行为共同决定；
  • TiCDC 默认写入下游时主动剔除 STRICT_TRANS_TABLES / STRICT_ALL_TABLES，下游即便开了严格模式，CDC 会话依然是宽松模式 → 超长字符串自动截断、不报 1406 错误（你当前现象的根本原因）；
  • 想要超长直接报错、阻断同步、不允许截断，有两套落地方案：强制 CDC 会话使用下游原生严格模式（推荐） + 搭配 CDC 错误处理策略。
6

这个如何强制，好像在changefeed的配置文件里写safe-mode严格模式也没生效吧？

7

是否可以修改下游的 SQL 模式

8

下游本身就是严格模式。
在changefeed的config文件里设置严格模式，也没有生效，日志里还是上面的信息。

9

报错同步就停了

10

sink uri 追加sql_mode=完整严格模式，强制下游连接开启严格超长校验，超长直接报错、同步阻塞

11

TiCDC 是一个数据搬运工,应该不知道下游情况?

12

是否可以修改下游的SQL模式

13

tidb遇到超长数据不拦截，直接扔给下游处理了。

14

感谢老师分享

15

image
image1584×371 34.1 KB

好像在uri设置的sql_mode参数并不生效，后面被ticdc给覆盖了。

16

是的，而且还在ticdc的会话将sql_mode 改成非严格模式，就导致数据被截断了，没找到不截断直接报错的方式。

17

tidb遇到超长数据不拦截，直接扔给下游处理了

18

TiCDC 默认按下游表结构写入，字段更短时下游会截断/按 SQL mode 处理，没有类似 MySQL 同步那种全局「严格模式一刀切报错」开关。要避免静默截断：1）上下游字段长度对齐；2）下游开 STRICT_TRANS_TABLES 并确认写入路径会因超长报错；3）用校验工具定期对账。根治仍是 schema 一致。

19

目前看应该就只有使用校验工具定期对比表结构了，下游本身就是STRICT_TRANS_TABLES 模式，看着像是无论如何设置，ticdc建立的会话的时候按照内部的sql_mode来处理，和uri以及下游的sql_mode无关。