8.5 没问题，看来是已知问题。7.5的小版本修复了吗

可以不用新建任务重新开始 1、 停止异常的任务 stop-task 任务名 2、找到最接近异常binlog 的position， 这里就是mysql-bin.018513，position 4。 3、在下游tidb修改dm_meta.任务名_syncer_checkpoint, 在schema和table为空的行，修改binlog_name和binlog_pos为你希望的起始点。 同时删除 exit_safe_binlog_name和exit_safe_binlog_pos 记录 [image] 4、启动任务，start-task

o ,现在就是这么处理的。 我还以为是别的方法，在原有的任务进行修改。 比如怎么修改dm_meta库的数据，来指定binlog 和position

咋跳啊，能帮忙指导下吗

设置的每个binlog大小是1G, 所以这个512肯定是损坏了。该怎么修复dm同步呢

设置engine 为tidb，tiflash，就会走tiflash [image] [image] 如果用hint的话就是报错 [image] 走tikv 看到warnings [image]

可能我没描述清楚，这个bug可以复现。 1、建立表board_material_rebate_daily_fox和dept_level_fox 2、添加board_material_rebate_daily_fox表 tiflash副本数为2 3、tiflash副本数正常后，用样例SQL查询，可以看到board_material_rebate_daily_fox表走的tiflash 4、 对表board_material_rebate_daily_fox 进行analyze 之后，再用SQL查询，执行计划就走了tikv 5、样例SQL添加 hint，/*+ read_from_st…

【PingCAP 10周年祝福语 】 下个十年见 【你对TiDB 印象最深刻的事情】 开源和社区环境非常棒！

[image] 正常

[image] 嗯，是升级上来的。当时改这个是因为7.5 刚开始不稳定 mpp老崩。 后面我再验证下吧。

你tidb版本新一点的话（好像是7.3之后 集群版本是7.5.4 [image] 其他的感觉也不会加太多的cast 查了一下，基本都是bigint 和varchar转义，典型的一时找不出。找到了再发帖吧。 再次感谢回复

感谢回答。 1、加了group by 确实会去走mpp [image] 2、关于优化器问题， 有排查的建议吗 3、关于tiflash的类型推导，是不是为了兼容mysql，来确保行为一致。这边业务大量依赖tiflash，现在有很多的cast，导致优化的时候比较茫然（应该重新设计字段类型，还是显式的cast）。最好有文档能详细描述tikv和tiflash的差异。目前的文档还是不够详细。 [image]

[image] 我这不行， 就算走mpp，tiflash也是转义成decimal啊，为什么bigint类型不是直接求和呢

关闭 tidb_enable_historical_stats drop stats 之后重新analyze，还是报错 [image]

集群是4版本开始 慢慢升上来的， 这次7.5 是从6.1 升上来的。 这个分区表都有2020年的数据，所以基本没有变更，操作就是把历史分区合并 tidb 错误日志 analyze-tidb.log.gz (1.3 MB) [image] 错误表iD 是分区 209616 [image] 2879028 [image] 健康度 [image]

我这里环境是稳定复现，换个集群或者复现步骤 就不行了 [image] [image]

尝试建新表 analyze之后没有复现出来

老版本的kill 如果不好使， 可以找owner 去kill 或者重启 1、找出 DDL owner 节点： 通过 curl http://{TiDBIP}:10080/info/all 获取当前集群的 Owner， 2、如果 Owner 不存在，尝试手动触发 Owner 选举： curl -X POST http://{TiDBIP}:10080/ddl/owner/resign

对，你要先扩容tikv，然后再下掉。tikv至少保证3个可用