YashanDB 知识库|服务端编码是 GBK，为什么升级失败了? 这其实是个字符集对齐问题

【问题分类】版本升级异常 / 字符编码兼容问题

【关键词】升级失败、GBK、UTF-8、preupgrade.sql、yasql、列宽不一致

一、问题背景

某客户在将 YashanDB 从版本 22.2.12.100 升级至 22.2.13.100 时，执行以下命令过程中发生升级失败：

./bin/yasboot cluster upgrade -c yashandb --package /path/yashandb-22.2.13.100-linux-x86_64.tar.gz

二、报错现象

升级中断，并提示 preupgrade.sql 脚本执行结果校验失败。查看日志发现，其实只是某行结果内容“长度对不上”，例如：

-----------(分隔线长度不一致)

看似小问题，却实实在在导致了版本升级失败。

三、问题原因分析

升级流程中包含对脚本结果的校验：

安装脚本会执行 preupgrade.sql;

结果输出记录在 preupgrade.out;

系统通过比对 .sql 执行输出与 .out 文件内容判断是否“通过校验”;

然而如果输出格式对不上，哪怕逻辑上无错，也会导致升级被阻断。

深层原因：字符集不一致引发“列宽”错位

服务端环境编码：GBK

客户端(运行 yasql 的终端)：UTF-8

因为字符宽度定义不同，导致同样的 - 分隔线，在不同编码下显示宽度不同，从而造成校验失败。

四、相关机制说明

在 yasql 打印输出列标题时，会依据列的显示宽度进行自动排版：

columnDesc->colWidth = (CodInt16)MIN(columnDesc->bindSize, ASQL_MAX_DISPLAY_WIDTH);bindsize = column->size * maxRatio + 1

其中 maxRatio 决定字符宽度转换：

maxRatio = clientMaxWidth > serverMinWidth? (clientMaxWidth - 1) / serverMinWidth + 1: 1;

当客户端使用 UTF-8.服务端使用 GBK 时，maxRatio 会变大，导致分隔线长度变长，输出错位。

五、影响版本

客户端版本：22.2.12.100

升级目标版本：22.2.13.100

已在后续版本优化处理，升级脚本不再比对 ----- 类分隔符或行首空格

六、规避方案（推荐操作）

为避免此问题，建议在升级前统一服务端与客户端编码为 GBK：

修改编码配置：

# 编辑客户端环境变量

vi 22.2.12.100/client/yasc_env.iniCHARACTER_SET=GBKvi 22.2.13.100/client/yasc_env.iniCHARACTER_SET=GBK

再次执行升级：

./bin/yasboot cluster upgrade -c yashandb --package /path/yashandb-22.2.13.100-linux-x86_64.tar.gz

升级即可顺利完成。

七、经验总结

YashanDB 升级流程中会自动执行 preupgrade.sql 和 postupgrade.sql，并比对结果输出是否一致;

即便功能无误，只要输出格式对不上(哪怕是一个 - 多一个字符)，也会导致升级失败;

字符集统一是跨版本升级中的细节关键项，建议提前规范客户端环境;

22.2.13.100 之后版本已优化该流程，忽略格式类差异项。