【磐维数据库】某客户-PanWeiDB_V2.0-S3.1.0_B01-业务update和delete操作报错分析处理
2025-03-28 11:57 狂澜与玉昆0950 阅读(262) 评论(0) 收藏 举报中国移动磐维数据是基于openGauss定制开发的中国移动自用版OLTP数据库。自去2023年年12月发布以来，受到广泛关注，目前已成功上线百余套。 在产品落地的过程中，我们积累了大量的迁移、适配，以及问题分析诊断的经验。 北京海量数据技术股份有限公司，作为移动磐维集中式数据库外协厂商，对集中式磐维数据库的运维、管理、开发等均有深入了解。在江西移动现场运维整理汇总经验。
影响版本
| 属性 | |
|---|---|
| 产品 | 磐维数据库 |
| 模块 | 对象管理 |
| 影响版本 | PanWeiDB_V2.0-S3.1.0_B01 + B模式 |
| 影响平台 | x86_64 + Hygon + BCLinux 8.2 |
修复版本
| 确认修复版本 | 重新发包解决：PanWeiDB_V2.0-S3.1.0_B01-install-bclinux_8.2-x86_64_hygon-no_mot.tar.gz |
|---|
Bug描述
主要是有两个问题：
- gs_initdb 错误检测机制失效。原因是 single 模式的 exit_on_error 功能行为异常，sql 执行异常时不退出并返回异常错误码。
- mysql_object.so 库加载失败。原因是之前在打包容器编译打包有问题，研发已复现。
问题现象
数据库初始化时，元数据定义的SQL脚本全部没有跑。导致数据库基础DML操作报错:ERROR: schema"information schema" does not exist
触发条件
使用第一版安装包，该环境下理论上必现：x86_64 + Hygon + BCLinux8.2 + V2.0-S3.1.0_B01 + B模式
复现用例
delete from test0303 where id =1;
定位分析
错误现象
基础dml操作delete异常报错
gs_dump、gs_dumpall异常终止
分析思路
检查schema
select * from pg_namespace;
出现BUG的集群上没有该schema
其他操作系统上集群存在该schema
查找源码
information_schema 有一个单独的 sql 文件
重新初始化实例
怀疑是安装错误导致的问题，重新初始化后，改端口再查看schema
依旧不存在information_schema的schema
架构信息
单独安装内核测试
#!/bin/bash
export GAUSSHOME=/home/cuixiaoyuan/workspace/panweidb/app
export LD_LIBRARY_PATH=$GAUSSHOME/lib:$GAUSSHOME/jre/lib/amd64:$GAUSSHOME/jre/lib/amd64/server:$LD_LIBRARY_PATH
export PATH=$GAUSSHOME/bin:$PATH
正常集群的shcema
出现BUG集群的schema
在错误的数据库里查询，发现不止一个初始化SQL文件没执行，后面的mysql_object 也没有执行，影响较广泛。
select * from pg_proc where proname = 'get_all_locks'; select * from pg_extension;
符号表定位问题
p mysql_object_file
p info_schema_file
p bki_file
p lines
p cmd
p *line
ctl+d
create schema information_schema;\
研发结论
在内部测试的环境，发现了报错的语句，在对比其他 os 平台和模式情况。
确认是这个语句报错了，但是，initdb 的错误检测机制，在这个平台的情况下没有生效导致的，具体原因还没有找到。
之前发布适配的包是 hygon 的，但是因为 initdb 错误检测机制失效，当时测试没有发现这个问题，而且只有 B 模式有问题。
这个 mysql_object.so 本身编译方式是有点问题的，跟 oracle_object.so 不一样，所以只有 B 模式有问题，ldd -r 可以看到报错。
这两个问题都解决后，重新编译，hygon 的适配包才能正常使用。
简易检测确认方式
如果呈现出来是这种，就会有问题，symbol 缺失或者乱码了。
nm -D mysql_object.so > test.log
正常情况如下
根因
无法规避，报错路径大概是这样的：
update\delete --> information_schema --> mysql_object.sql --> mysql_object.so --> 动态链接库问题
因此，如果手动创建 information_schema ，最后还是会走到后面 mysql_object.so 那块错误。
详细：
- update\delete 失败，表现为依赖 information_schema 的内容缺失
- information_schema 的内容缺失是在 initdb 时, 创建时这个 schema 报错，需要使用 mysql_object.sql 中定义的操作符 ^，这个操作符没有
- 第2点操作符没有是因为，在initdb时，创建 mysql_object.sql 中的元数据对象，需要依赖 mysql_object.so 中的 C 函数，但是 mysql_object.so 这个动态链接库有问题，无法使用。
第2点和第3点，initdb 过程报错，由于错误检测失效，未报错退出，表现为初始化成功，实际缺失元数据。
是当时打包选择的镜像有问题，是非hygon的镜像，虽然编译出来的，但是实际使用会有这个问题，更换镜像之后可以了。
其他问题（dump）：是 mysql_object.so 里面的函数，这个动态库加载不了，直接更换新的动态库即可。
Workaround
规避方案
替换新的 mysql_object.so
通过 single 模式启动补 mysql_object.sql + information_schema.sql 的元数据对象，补充跑一下。
但是这个每个数据实例需要单独跑一下（集群只需要主节点跑）
具体操作说明：磐维海光元数据丢失补充方式
最终解决方案
新的安装包
PanWeiDB_V2.0-S3.1.0_B01-install-bclinux_8.2-x86_64_hygon-no_mot.tar.gz
验证通过，更新删除没问题。
参考文档
【ID1055502】【某客户】海光cpu+BClinux8.2系统安装panwei310 B模式后缺少information_schema，导致无法正常执行update和delete操作**
浙公网安备 33010602011771号