是的，已经让研发改了。

另，看mysql5.7介绍，comment长度是1024字符，是不是计算有问题 maxLen := MaxCommentLength // The maximum length of table comment in MySQL 5.7 is 2048 // Other comment is 1024 switch errTooLongComment { case dbterror.ErrTooLongTableComment: maxLen *= 2 https://dev.mysql.com/doc/refman/5.7/en/create-table.html#creat…

看代码是计算的 len(comment)，是按着字节截断的。 实际按字节、字符计算都没关系，但是要与官网介绍的varchar一致（charset=utf8mb4） mysql> show create table information_schema.columns\G *************************** 1. row *************************** Table: COLUMNS Create Table: CREATE TABLE `COLUMNS` ( `TABLE_CATALOG` varchar(512) DEFAU…

辛苦帮发一下 这段话的说明文档。

实际看应该是超bit了，不是超字符。

341+1个乱码 黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱黄河大合唱…

另，您这个2048是参数配置的么？

是的，正常情况业务不需要这么长，就是发现这个问题了，怀疑是字符、字节 搞混了。

性能压测对比，应该比不过MySQL，博客中的延迟抖动、尖峰，可能跟MySQL的参数有关，可以发MySQL参数出来一起看看，再压一次。

感觉，这个还是很严重啊，天天宕机，会降低信任度。

1、tidb—>flink cdc—>ES 这样可以？ 2、tidb → mysqldump导出数据到S3（csv格式）-> Logstash → es

没做过前置性能评估， 新版本很多新特性，看自己业务是否用到，或者抽取生产AP的SQL，放到研发环境，对比升级前后性能对比。 当然如果有架构能搞定流量收集问题，也可以重放，类似美团那边流量回放。

马克围观下

申请测一下呢？ 这样也能产出成本投入情况（这个在选架构时候，通常比较重要）。

了解，get。谢谢

明白，您有办法复现么，我想小版本7.1.0 → 7.1.6，担心引入更大故障。

比如：集群开启cdc后，drop1张表，但region没GC；其他表又复用这个region，随着表数据写入，region split了。这就会导致 tikv 挂了。 或者两个小表共用一个region，随着数据增长region split？

请问，v7.1.7什么时候发布，另这个问题是哪些场景稳定触发。

get！！ 我是通过关闭gc.compactioin 的，不太清楚打开有啥问题，snapshort正常推进，数据不gc。