【 使用环境 】 测试环境
【 OB or 其他组件 】OB
【 使用版本 】社区版4.0.0(docker部署)
【问题描述】
更新sql报错:Error 1235 (0A000): Not supported feature or function
app_icon该字段类型为longblob,保存的是图片的字节流。
manager.go:744: error update t_app_list set app_icon=? where app_key=? err: Error 1235 (0A000): Not supported feature or function
数据库字符集是utf8mb4_general_ci
有的图片可以上传成功,有的又报错。
【复现路径】问题出现前后相关操作
【问题现象及影响】
【附件】
刘彻
2023 年9 月 26 日 19:32
#3
不成功的图能找出来了吗?和成功的对比一下,在大小上是否存在差异?
另外看一下这张表是否存在触发器,报错会不会是触发器引起的
没有触发器。大小看了下,也没有超过longblob的最大值,也没什么规律。
图片的格式有png、jpg、gif等格式的。
我这边是golang接入的,使用的是mysql的驱动。
图标字段app_icon(longblob),后续跟其他参数更新就报错,但是如果只更新该字段就成功。
是不是字节流长度太长了,影响sql绑定了?
query := “update t_app_list set app_icon=? where app_key= ‘56fbd9314def2c2d02e24cb7’”
result, err := db.Exec(query, imageBytes)
–这个sql可以执行成功(imageBytes是图片字节流)
appkey := “56fbd9314def2c2d02e24cb7”
query := “update t_app_list set app_icon=? where app_key=?”
result, err := db.Exec(query, imageBytes, appkey)
–这个sql执行失败(imageBytes是图片字节流),报错Error 1235 (0A000): Not supported feature or function
是不是字节流长度太长了,导致后续参数绑定不完整?
刘彻
2023 年9 月 28 日 10:07
#7
vitoguo:
这边是golang接入的,使用的是mysql的驱动。
图标字段app_icon(longblob),后续跟其他参数更新就报错,但是如果只更新该字段就成功。
是不是字节流长度太长了,影响sql绑定了?
query := “update t_app_list set app_icon=? where app_key= ‘56fbd9314def2c2d02e24cb7’”
result, err := db.Exec(query, imageBytes)
–这个sql可以执行成功(imageBytes是图片字节流)
appkey := “56fbd9314def2c2d02e24cb7”
query := “update t_app_list set app_icon=? where app_key=?”
result, err := db.Exec(query, imageBytes, appkey)
–这个sql执行失败(imageBytes是图片字节流),报错Error 1235 (0A000): Not supported feature or function
是不是字节流长度太长了,导致后续参数绑定不完整?
如果数据库换成mysql,这段代码是否有问题,帮忙试一下,这样可以确认一下问题是出在驱动上,还是数据库服务端
mysql是没问题的。我们原来业务是用mysql实现的,后续准备兼容ob。
刘彻
2023 年9 月 28 日 10:12
#9
好的,我找这边专业的同事来看一下这个问题
您那边mysql驱动版本,golang的版本麻烦提供一下
这两个驱动都试过,都有类似问题
menteslibres.net/gosexy/db/mysql
我这边go的版本是
go version go1.16.14 linux/amd64
麻烦老师帮忙试试。(目前自测的图片是15K左右)
我现在是用镜像4.0.0社区版部署,执行这个命令不对:
渠磊
2023 年9 月 28 日 11:06
#13
不是直接给trace_id哈,应该是–trace_id ${上一步所拿到的trace id}
完整的命令例如obd obdiag gather plan_monitor deploy_test_cluster --trace_id YB4264586CAD-000605D9FB0BD1C0-0-0
渠磊
2023 年9 月 28 日 11:07
#14
抱歉刚刚没有注意是docker部署的
流程需要做下更改,前两步保留
3.下载诊断工具https://github.com/oceanbase/oceanbase-diagnostic-tool/releases,并解压
4. 进入对应目录,更改这两个地方
配置成实际的值即可
5.执行
./obdiag gather plan_monitor --trace_id ${上一步所拿到的trace id}
完整的命令例如./obdiag gather plan_monitor --trace_id YB4264586CAD-000605D9FB0BD1C0-0-0
6.上传日志包到帖子
渠磊
2023 年9 月 28 日 11:29
#17
麻烦按新的步骤执行下,刚刚是我没有注意这个部署方式
渠磊
2023 年9 月 28 日 11:53
#19
在解压完成后进目录,理论上配置了OBCLUSTER那里面的目录即可
cluster_name可以通过查集群配置项获取SHOW PARAMETERS LIKE ‘cluster’; 然后取对应value列的值即可
这个用户名和密码在哪看呢? 我看镜像中的boot.yaml是这个admin/root
渠磊
2023 年9 月 28 日 14:02
#21
OBCLUSTER里的那个user和pd是对于集群的,user填root@sys pw如果不存在可以直接用两个单引号括号起来(猜测应该是这个原因所以报错)
配置可以参考
渠磊
2023 年9 月 28 日 14:42
#22
配置完以后,重新执行完对应的go的程序
拿到tranid后执行
./obdiag gather log --scope observer --grep=${上一步所拿到的trace id} --ob_install_dir=${远程主机上的ob_home地址} --since 10m
远程主机上的ob_home地址需要在容器上拿,进容器后看下对应observer的路径,比如为/work/obwork/bin/observer,就填/work/obwork/
另外,在改配置中private_key,这个参数需要使用绝对路径,否则容易报错