Cause: java.sql.SQLException: other error: Storage engine DeltaMerge doesn't support lossy data type modify from Int64 to Int32

🪐 TiDB 技术问题 部署&运维管理
1

Cause: java.sql.SQLException: other error: Storage engine DeltaMerge doesn’t support lossy data type modify from Int64 to Int32

java 调用查询出这个错误 count 改成long也不行
select corporate_id,user_id,opera_id,sum(count) count

2

select count(*) from 出现的问题，观察发现是 使用 TIFlash造成的。不知道如何解决

3

你好，

tiup 部署吗？
可以提供下 display 结果，看下当前 tiflash 的状态是否正常，因为 tiflash 没有故障转移功能，如果仅部署一个 tiflash，故障之后查询是不能自动切换回 tikv 的，可以检查下。

另外提供下 explain sql 的完整信息，感谢。

4

sql 在navicat 里能查询出结果，但是在java里会报这个错误。没添加tiflash时，没有问题。

5

仅为现象，请提供上面信息

6

image
image1402×598 24.1 KB

7

截图不全那行是 ge(sms.sms_returnreport.send_time, 2020-12-08 00:00:00.000000), le(sms.sms_returnreport.send_time, 2020-12-08 23:59:59.000000)

9

image
image1859×690 57.8 KB
4.0.4v

10

查询出来以后用map接收的。

11

程序使用这边不敢置评，请问 tidb 使用上有疑问吗

从这报错来看，程序使用 int 32 处理了 int 64，及时换成 log，也是类型不统一，换成 int 64 处理试下？

12

我试一下。tidb目前就是OOM的问题，始终没有妥善的解决办法。内存溢出导致服务重启。不管多大的内存，多个大查询并发总归会死掉。

13

so，到底是啥问题

解决 oom 问题可以参照

14

@sunlide

Hi，从错误日志推测，这张表应该是有过 DDL 操作，把某个字段从 Int64 修改成了 Int32。（这个操作其实是非法操作，但是目前版本的 TiDB 没有阻止这类操作，在 4.0.9 之后会禁止这类操作。）
而 TiFlash 这边的检查比 TiDB 更严格，所以发生了报错。

你可以升级到 v4.0.6，并避免类似的 DDL 操作

  • 如果这张表没有 TiFlash 副本，则把集群升级到 v4.0.6 以上，可以避免报错
  • 如果有 TiFlash 副本，且需要使用，目前没有特别好的处理方式。可以在升级版本后，truncate 表重建然后重新导入数据。
15

谢谢，是这个问题，我 tiup update --all 升级后还是 4.0.4

16

tiup update --all 只是升级的 tiup 工具包，不是升级 TiDB 集群，升级集群可以参考官方文档：
https://docs.pingcap.com/zh/tidb/stable/upgrade-tidb-using-tiup#4-滚动升级-tidb-集群