【 使用环境 】 测试环境
【 OB or 其他组件 】
【 使用版本 】oceanbase 4.0.0社区版
【问题描述】批量操作后,数据库无法连接,查日志发现报错clog disk is almost full
【复现路径】kill集群(单节点)进程后,启动在cluster initial 这一步报错,尝试调大log_disk_utilization_threshold等参数,重新尝试启动一样失败
【附件及日志】应该是共性问题了,除非集群铲了重新部署外,是不是无解,数据还能找回吗
不需要重新部署,可以先带参数启动下看看,这里的log_disk_size根据实际情况设置为memory_limit的3~4倍,另外要保证物理磁盘空间大小足够
./bin/observer -o "log_disk_size=18G,log_disk_utilization_threshold=95,log_disk_utilization_limit_threshold=98"
clog盘满建议分析一下根因,如果不明确根因铲了重建还有出问题的风险。
诊断工具obdiag 就支持这种场景的根因分析:https://www.oceanbase.com/docs/common-obdiag-cn-1000000001768204
贴一下你使用的obdiag命令以及报错的信息。另外使用obdiag 的时候~/.obdiag/config.yml需要配置的是sys租户的信息
你登陆sys租户查看一下有这张oceanbase.DBA_OB_SERVERS表吗。另外你这个sys租户登陆密码是空的是吧?
如果obdiag config 受阻,
方式一:可以直接手动编辑~/.obdiag/config.yml文件,参照这个文档:https://www.oceanbase.com/docs/common-obdiag-cn-1000000001768176
方式二:还可以无配置文件使用,比如:
obdiag rca run --scene=clog_disk_full \
--config obcluster.db_host=xx.xx.xx.1 \
--config obcluster.db_port=2881 \
--config obcluster.tenant_sys.user=root@sys \
--config obcluster.tenant_sys.password="" \
--config obcluster.servers.nodes[0].ip=xx.xx.xx.1 \
--config obcluster.servers.nodes[1].ip=xx.xx.xx.2 \
--config obcluster.servers.nodes[2].ip=xx.xx.xx.3 \
--config obcluster.servers.global.ssh_username=**** \
--config obcluster.servers.global.ssh_password=**** \
--config obcluster.servers.global.ssh_port=22 \
--config obcluster.servers.global.home_path=/root/observer \
--config obcluster.servers.global.data_dir=/root/observer/store \
--config obcluster.servers.global.redo_dir=/root/observer/store
我昨天把observer进程kill了,在集群配置文件config.yaml的加了log_disk_utilization_threshold/log_disk_utilization_limit_threshold配置项,后面用白屏命令obd启动集群就没成功过,但是observer进程是在的,用原来的密码obclient连接数据库被拒绝,用空密码能连接成功
密码项为空是我后面发现可以空密码连接observer后改的,原来不为空时带密码访问是被拒绝的
这个问题有进展吗,另外400版本不建议使用了,
目前TP场景推荐推荐4.2.5版本,AP场景建议使用4.3.4。