1.三台机器部署这么多节点，几乎不可避免会有资源挤兑的问题。请确认一下出现问题时，机器的各项资源使用情况。
2.确认集群热力图情况，在Dashboard 面板可以查看。
3.针对访问慢的语句，重点分析慢查询情况。
排查集群访问日志和监控图表，对上面几个方向一一确认一下。
2 天前
这个确实是有点猝不及防，TiCDC的同步原理是获取tikv的行变更来进行同步，上游修改表字段类型的时候会触发数据重新调整，应该是这个过程导致了整个表的KV数据都有变更，所以重新同步了一遍。这个在新版本应该是修复了 。
4 天前
从 Lock Resolve OPS这里可以确认执行任务时遇到的锁比较多，导致内部 backoff 重试次数多，这个过程会相比较耗资源，业务侧也会感知到SQL变慢的。
现在集中看看为啥要锁这么久，是读取数据的过程比较慢，还是要检查的MVCC版本比较多。
楼主重点搜索和排查下tikv面板 和 tikv的日志情况，。
5 天前
从热力图看着是有比较集中的写情况。
可以到 Grafana的 TiDB 面板，查看下 KV Error 和 DistSQL 面板的情况，检查锁冲突或者backoff是否较多。
5 天前
楼主看看Dashboard的热力图情况呢，贴下集群访问的热力情况。
prewrite 是2PC的提交阶段，这个阶段主要是在做MVCC的多版本检查、以及是锁冲突检测，说明这个事情花了较多的时间。
5 天前
sql_mode 一般是检查数据是否符合要求，如果设置了在不符合时会报错，不设置就会打印warning而不报错，但是数据会被截断插入。如：
mysql> select version();
+--------------------+
| version() |
+--------------------+
| 5.7.25-TiDB-v5.4.0 |
+--------------------+
1 row in set (0.00 sec)
mysql> show variables like '%sql_mode%';
+---------------+-------…
6 天前
出现这个问题，一般都是实际数据长度不符合表结构的定义长度所导致的。
鉴于楼主你这个是测试环境，看看能否在原表再插入相同的字段数据，先尝试复现问题。
也可以把表和数据脱敏后提供上来，大家一起看看。
6 天前
v5.4版本，VARCHAR 的空间占用大小不得超过 65535 字节。在选择 VARCHAR 长度时，应当根据最长的行的大小和使用的字符集确定。
utf8mb4下VARCHAR 最大列长度的取值范围是(0, 16383] 。
https://docs.pingcap.com/zh/tidb/v5.4/data-type-string
6 天前
没有更多内容了