Bug Description
1.3.3.3.0 ,通过服务器镜像迁移到新的服务器上,启动。
2.升级到3.3.6.13 版本,也就是现在的稳定版本
3.升级之后,跑了一段时间,发现string类型被jdbc内部转换成了byte[],处于性能考虑,查看稳定,发现最新版本是ws协议的时候,可以添加参数,内部转换
4.然后直接升级到3.4.1.13.community,跑了一段时间出现了
问题1:客户端内存异常频繁OOM,
我的解决方案:查询官方jdbc稳定,修改了部分代码:
AbsWSPreparedStatement.java
在101 行添加了个代码
if (this.resultSet != null && !this.resultSet.isClosed()) {
this.resultSet.close();
}
重新构建了jdbc 的jar
晚上7点左右使用了最新的jdbc包,刚开始一切正常,到了凌晨5点左右,taosd 挂了
下面这个是日志
分析的结果
vnode12 的 TSDB/cache 数据格式异常,导致 taosd 在恢复提交阶段直接 FATAL 退出。
还有最后一点,不得不吐槽一点,
你的每个版本升级,都像是安装一个新的数据库,不是这里有问题,就是哪里不兼容,
为什么要搞这种毁灭性的升级。
Bug Description
1.3.3.3.0 ,通过服务器镜像迁移到新的服务器上,启动。
2.升级到3.3.6.13 版本,也就是现在的稳定版本
3.升级之后,跑了一段时间,发现string类型被jdbc内部转换成了byte[],处于性能考虑,查看稳定,发现最新版本是ws协议的时候,可以添加参数,内部转换
4.然后直接升级到3.4.1.13.community,跑了一段时间出现了
问题1:客户端内存异常频繁OOM,
我的解决方案:查询官方jdbc稳定,修改了部分代码:
AbsWSPreparedStatement.java
在101 行添加了个代码
重新构建了jdbc 的jar
晚上7点左右使用了最新的jdbc包,刚开始一切正常,到了凌晨5点左右,taosd 挂了
下面这个是日志
分析的结果
vnode12 的 TSDB/cache 数据格式异常,导致 taosd 在恢复提交阶段直接 FATAL 退出。
还有最后一点,不得不吐槽一点,
你的每个版本升级,都像是安装一个新的数据库,不是这里有问题,就是哪里不兼容,
为什么要搞这种毁灭性的升级。