OceanBase 社区版1.5天蹦一次【紧急】【重要】

【 使用环境 】生产环境
【 OB or 其他组件 】
【 使用版本 】

系统centeros 7.9
ob版本 4.1.0.1 
ocp用的是ocp-express版本的

【问题描述】4台java springboot去连接 OceanBase sys租户中的库 xxxA
【复现路径】 刚开始是连接的ocp地址 192.168.1.23:2883 使用了20个小时没什么问题晚上springboot直接报错无法连接了,我以为是ocp负载问题。就修改成了 集群主的地址192.168.1.20:2881 过了一天 今天大概6-8点之间蹦了 不上了
【问题现象及影响】

1、用户的订单无法下单
2、集群无法启动业务无法恢复
3、用了5天宕机了3次

springboot日志

【附件】

这是/home/oceanbase/obs/ocpexpress/log  ocp日志

ocp-express.log.2023-07-20.0.gz (4.8 MB)

这是odb日志/root/.obd/log/log

obd.zip (102.9 KB)

补充
服务器 A 192.168.1.20  ob 4.1  64核128G 1T SSD     主
服务器 B 192.168.1.21  ob 4.1  64核128G 1T SSD
服务器 C192.168.1.22  ob 4.1  64核128G 1T SSD
服务器 D 192.168.1.23 ob 4.1  64核128G 1.2T SSD

连接方式
7.18号连接方式
租户sys  数据库 shop_prod   192.168.1.20:2881
7.19号连接方式
租户sys  数据库 shop_prod   192.168.1.23:2883

springboot连接
spring:
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
  datasource:
    type: com.zaxxer.hikari.HikariDataSource
    driver-class-name: com.mysql.jdbc.Driver
    url: jdbc:mysql://192.168.1.20:2881/shop_prod?useSSL=false&useServerPrepStmts=true&useUnicode=true&characterEncoding=utf8&serverTimezone=UTC
    username: root
    password: ************
    hikari:
      # 是客户端等待连接池连接的最大毫秒数
      connection-timeout: 30000
      # 最小连接池数量
      minimum-idle: 20
      # 配置最大池大小
      maximum-pool-size: 64
      # 是允许连接在连接池中空闲的最长时间(以毫秒为单位)
      idle-timeout: 60000
      # 池中连接关闭后的最长生命周期(以毫秒为单位)
      max-lifetime: 600000
      # 配置从池返回的连接的默认自动提交行为。默认值为true。
      auto-commit: true
      # 连接池的名称
      pool-name: MyHikariCP
      # 开启连接监测泄露
      leak-detection-threshold: 20000
      # 测试连接数据库
      connection-test-query: SELECT 1

这里spring连接还有问题 我之前连接池maximum-pool-size配置的是1000 开了4个 项目同时去连接 启动了两个以后就 另外两个无法连接

看描述是数据库宕机 不是express吧 可以提供下出问题时间observer.log

springboot直接报错无法连接 的具体报错信息也贴一下

observer.zip (8.8 MB)

麻烦把你的搭建架构和业务sql schema和常见查询,另外32u 52g的配置很奇怪的,你的yaml文件怎么写的,首先sys租户不是用来做业务的,另外你的yaml怎么写的,分配给sys租户多少资源


这里更正下 服务器 D 192.168.1.23 ocp 4.1 64核128G 1.2T SSD

关联同问题

@AntTech_LTEW4O

关联回复分支问题中提到的路径,原文中redlog目录为对应的日志盘,可以自行更改为对应路径

执行cpp的结果
test.log (6.3 KB)

资源和yml我都放在下面了

有core文件生成么

core.zip (56.7 KB)
youde

有结果后,辛苦贴子上更新下原因

sys租户不适合当业务使用,可以先考虑新建业务租户,数据导出再导入到业务租户里,应用程序使用新的业务租户连接。

补充一个问题 我把这个 major_freeze_duty_time 合并定时任务执行时间改成了6点 合并就出现访问不了

@AntTech_LTEW4O @tianya
基本确定为同类型问题,可执行文件也发下吧,这边看下用gdb二次验证下。
解决方案:
可以参考原问题中 HaHaJeff 给的方案,

或者是参考用户自身探索的方案,

2 个赞

这边请教一个问题,我这边大量的insert操作能否均衡一下到其他两个zone2 zone3 节点上 感觉现在除了zone1的主节点 其他两个节点在空跑。还有我数据库链接主节点192.168.1.20:2881 和我链接192.168.1.23:2883 有什么区别 后者能够负载吗? 如果他是负载的话那是不是瓶颈就是他 因为我之前没上线的时候做了压力测试 4台 容器每个线程池跑1000 只能开启两台

通过proxy,再加上你配置的primary zone随机打散,会把sql均衡打散到不同的zone上,当然是前提你的表的主分区不能都在同一个节点上

这块可以参考下 xuyu 给的建议

这边的访问不了是指本次问题关联的操作条件么,可以看下对应时间的日志反应