[image] 我突然发现你在同一个机器上面挂在同一个地址，同一个IP，同一个端口号 ,这个能起来就神奇了

赶快试试向量特性，先吃肉

你查一下20160 端口是否被占用了，看报错 time out waiting for port 20160 ，使用netstat -nlp | grep 20160

不水才能不拉垮

【最符合预期的功能有哪些】索引优化 【哪些功能还需要继续改进】分区表分区字段必须为主键，有的时候分区字段不是主键，如果可以创建非主键分区表，对查询效率来说很有帮助 【哪些功能对你帮助不大】tiflash ，首先都是个人主观观点，如果你觉得我说的不对，完全是我的问题。这个产品很尴尬，处于一个鸡肋产品，写入受tidb 写入控制，也就是受tidb 写入多快，他就能多快，tidb 关系型数据库，写入本身不是强项。另外不像doris,starRocks 有优化聚合模型，还有查询优化，所以很难成功。

SQL查询不到， 当你的表是单个主键的时候 主键是整数数字类型，的时候row_id 是主键的数字，当不是的时候是自动生成数字，这个数字不和主键有直接关系，但是可以通过代码解析出来。其逻辑应该是生成一个row_id ，key(table_id ，row_id)——》value(主键) ，可以通过tikv client 查询出来。 当你的表不是单个主键， rowid 随机生成，保存再tikv 中，逻辑大概可以表示为（table_id,row_id）->(value1(主键1)。。。。valueN（主键N）)

从tidb5走到tidb8，我们是使用者，见证者，肉眼可见tidb越来越好。看到未来规划规划部分，相信tidb能走在国内乃至世界的数据库前列！

支持同步ddl，根据ddl然后自己处理一下再处理变更

太有必要了，我要严重呼吁增加物化视图 场景描述： 目前做实时数据开发，基于tidb+flink 如果有物化视图，基本不需要搭建ticdc ,kafka，flink ， 还有flink ck 存储的hadoop 。 目前基表很多，但是一般join 需要2-6张表这样子 ，这些表全部是持续写入。 更新延迟秒级别。 单个物化数据量不足TB级别，到几兆（维度表）到几百G(多事实聚合) 都有。 表均存在更新，删除比较少，我们这里目前将删除进行打flag 软删除。 痛点描述： 系统目前通过基于ticdc+kafka+flink+tidb 实时 开发处理，由于flink sq…

ticdc的定位是什么？tidb之间的数据同步吗？因为没有增量加全量同步，所以有这个疑问。同时未来的定位会变化吗？

这里提供一下之前的更新：

有文档的，看我发的文章里面就有

删除重建，名字命名不一致看下，感觉这个事件非常诡异

我有个更快的方式，用tikv scan直接读取，不过单线程读，读出来写可以多线程写，不过要写代码

不光这个问题，数据合并，增加列有默认值都会报错，如果必须依赖Maxwell 格式cdc我劝你退到5.4.1如果不强制更改为canal 下面给你我的两个异常记录 ticdc 增加有默认值字段后异常… tidb cdc 同步数据异常…

是Maxwell格式吧😂，兄弟7.已经不维护了，之前测试Maxwell格式7.，8.都有问题，我用5.，目前没有遇到问题

这边看到执行用户名kfzdba，这个用户是谁在用?如果可以， 尝试一下删掉这个用户，再看下

MySQL 不同，TiCDC 则实时监听上游 TiKV 各个 Region Raft Log 的信息，并根据每个事务前后数据的差异生成对应多条 SQL 语句的数据变更信息。TiCDC 只保证输出的变更事件和上游 TiDB 的变更是等价的，不保证能准确还原上游 TiDB 引起数据变更的 SQL 语句。 来自ticdc简介， 不可能完全还原上游变更的SQL语句，因为ticdc与MySQL Binlog不一样，MySQL Binlog有直接记录上游SQL的协议，ticdc是直接读取tikv的日志，行级别滴哦🙄