ITPub博客

首页 > 数据库 > Oracle > 【YashanDB知识库】服务端是GBK编码,导致从22.2.12.100升级到22.2.13.100失败问题

【YashanDB知识库】服务端是GBK编码,导致从22.2.12.100升级到22.2.13.100失败问题

原创 Oracle 作者:崖山数据库系统YashanDB 时间:2024-07-26 11:04:24 0 删除 编辑

问题现象

问题单:22.2.12.100升级到22.2.13.100失败

现象:如下图,从22.2.12.100升级到22.2.13.100失败,报错。

问题风险及影响

版本升级失败,影响上线

问题发生版本

客户版本:22.2.12.100

现在版本已经修改掉这个问题,升级比较时忽略掉"----"开头的分隔符和结果前后的空格。

问题发生原因

表现原因:执行升级脚本,/home/yashan2/yasdb_home/yashandb/22.2.13.100/upgrade_tmp/admin/upgrade/22.2.12/preupgrade.sql后,结果和preupgrade.out匹配失败,导致升级失败。

根因:服务端是gbk、客户端是utf-8编码。yasql对于gbk和utf打印格式不同,导致结果匹配失败

解决方式及规避方法

规避方法:

原生客户端和升级客户端编码格式都设置为GBK编码

1、vi 22.2.12.100/client/yasc_env.ini

CHARACTER_SET=GBK

2、vi 22.2.13.100/client/yasc_env.ini

CHARACTER_SET=GBK

3、./bin/yasboot cluster upgrade -c yashandb --package /home/yashan2/tmp_upgrade/yashandb-22.2.13.100-linux-x86_64.tar.gz

可以正常升级成功。

解决方式:提问题单修改

问题分析和处理过程

问题分析:

查看yasagent.log,发现是执行脚本后,报错。

对比preupgrade.out结果文件,发现是"----------"长度对比不上,导致的问题

代码分析:

  • asqlPrintColumnTitles打印列头信息,根据columns[i].colWidth长度来做

  • columnDesc->colWidth = (CodInt16)MIN(columnDesc->bindSize, ASQL_MAX_DISPLAY_WIDTH);

  • bindsize = column->size*maxRatio + 1

  • maxRatio 默认为1;当客户端和服务端编码不一致时,maxRatio = clientMaxWidth > serverMinWidth ? (clientMaxWidth - 1) / serverMinWidth + 1 : 1;

确认根因为编码不同导致的问题,然后定下规避方案

经验总结

yashandb版本升级流程中,会调用preupgrade.sql、postupgrade.sql脚本,并比较结果判断是否升级成功。

来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70028812/viewspace-3023453/ ,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
崖山数据库系统YashanDB是深圳计算科学研究院完全自主研发设计的新型数据库系统,融入原创理论,支持单机/主备、共享集群、分布式等多种部署方式,覆盖OLTP/HTAP/OLAP交易和分析混合负载场景,为客户提供一站式的企业级融合数据管理解决方案。

注册时间:2023-04-11

  • 博文量
    722
  • 访问量
    639749