wangxiaoliang001 opened a new issue, #8785: URL: https://github.com/apache/seatunnel/issues/8785
项目是好项目，无奈问题实在是太多，从24.12-25.02挣扎了近3个月，从入坑到放弃 TiDB 6.1.3 ： 1、仅能用来同步静态数据，无法进行增量（Region分裂合/并后增量异常，已修复） 2、增量过程任务持续一段时间后停止（sync同步锁导致 tikv grpc连接池不可用，Check for unhealthy stores， 已修复） 3、表字段存在默认值，sink后为 null （组装 SeaTunnelRow 实例时缺少 schema default value检查， 已修复） 4、大表全量阶段内存溢出 （load完大表之后才sink数据，已修复） 5、分区表无法同步 （已修复） 6、联合主键表无法同步 （缺失主键字段数据，已修复） 7、部分表增量同步异常，表现为 tikv有推送数据，但非常少，与实际变更条数不匹配 （未找到原因） **TiDB组件完全没办法使用，该组件应当从官方宣传的支持列表中删除，以避免对需求方造成较大的决策损失** Kafka 2.8 ： 1、Kafka 增量无法消费 （偏移量设置错误） 2、Kafka 任务重启无法从上次的偏移量消费，只有 group_offset 支持（其它语义已全部支持，已修复） 3、Kafka 不支持JSON字段 （已修复） 4、Kafka 消费大量数据内存溢出 （已修复） 5、Kafka Sink 统计不准，已增加 AT_LEAST_ONCE 语义，实际跟统计结果相差较大，且未提供丢失日志 （未修复） 6、Kafka Sink tinyint(1) 类型，null => 0、true => 0 转换错误 （已修复） 7、Kafka 支持按分区 Sink ，但不支持按分区 Source （已修复） Mysql： 1、Mysql 大表全量阶段非常慢（使用场景不多，尚未发现太多问题） Zeta 2.3.8 引擎缺陷： 1、未按资源使用情况进行调度，实际使用过程中，部分负载较高的节点依然会被调度，空闲节点依然空闲 2、任务缺乏隔离机制，部分任务异常导致节点重启，任务重新漂移，进而影响整个集群接连重启 3、引擎组件中大量使用无界队列，该问题在大多数组件中普遍存在，因此对当前宣传的投产项目持怀疑态度 4、开发调试难度较高，屏蔽了 main 函数启动方式，除非适配 spi 的启动方式，同一组件倘若对接各种数据源，其调试难度将大大增加 5、应当提供默认的，并且较好的GC策略，任务阶段GC时间过长，容器环境下易探测失败被动重启 监控： 监控模板较为粗糙，没有任务监控，已完善  -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
