binlog实例报错Failed flush to file ./log/binlog_instance.log: No space left on device

OceanBase 技术问题
,
#1

【 使用环境 】生产环境
【 OB or 其他组件 】binlog
【 使用版本 】4.3.1
【问题描述】binlog实例启动失败，提示Failed flush to file ./log/binlog_instance.log: No space left on device，但是binlog实例所在的服务器上磁盘空间还有较多空闲。

image
image1379×380 22 KB

请问这是什么原因导致的？
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

1 个赞
#3

根因分析场景: DDL过程中报磁盘空间不足的问题
根因分析命令: obdiag rca run --scene=ddl_disk_full
日志采集场景: 日志归档问题
日志采集命令: obdiag gather scene run --scene=observer.log_archive

为了更好地帮助您定位和解决问题，建议您使用上述命令进行日志采集和根因分析，并将采集到的日志提供给我们以便进一步确认问题所在。

另外，请您回答以下问题以提供更多有助于诊断的信息：

  1. 是否可以确认 binlog 实例所在的文件系统是否有配额限制（如 inode 或者 quota）？
  2. 服务器的磁盘空间是否分布在多个分区上？binlog 文件具体存储在哪一个分区？
  3. 是否有其他进程或任务在近期占用了大量磁盘空间？
  4. 您提到服务器磁盘空间充足，能否提供具体的磁盘使用情况（例如通过 df -h 和 df -i 命令输出）？
  5. 是否对 binlog 相关配置进行了修改？如果有，请说明具体的修改内容。
  6. 这个问题是一次性出现还是持续发生？如果是持续发生，请描述触发该问题的具体操作或条件。

附上敏捷诊断工具 obdiag 使用帮助链接

2 个赞
#4

binlog的版本是哪个？日志信息截图截取完整点

2 个赞
#5

binlog版本是4.2.3，日志如下
libobcdc.log.tar.gz (3.5 MB)

2 个赞
#6

binlog_instance.log logproxy.log 报错时间点的 这两个日志也提供一下

1 个赞
#7

image
image1396×106 11.2 KB

可以检查一下 这个文件下的磁盘空间 是否有问题

#8

根据您提供的信息和上传的日志文件，Failed flush to file ./log/binlog_instance.log: No space left on device 的问题可能与以下几种情况有关：

可能原因分析

  1. 磁盘配额限制（Quota）
    即使服务器整体磁盘空间充足，但如果 binlog 实例所在的目录设置了磁盘配额限制（quota），可能会导致写入失败。您可以检查是否有配额限制：

    quota -u <用户名>

    或者检查文件系统级别的配额：

    repquota -a

  2. inode 耗尽
    磁盘空间虽然有剩余，但如果 inode 已经耗尽，也会导致无法创建新文件或写入日志。可以通过以下命令检查 inode 使用情况：

    df -i

    如果某个分区的 IUsed% 接近 100%，则说明该分区的 inode 已经耗尽。

  3. 日志文件存储路径错误
    根据日志提示 ./log/binlog_instance.log，需要确认该路径是否正确，并且是否有足够的权限写入该路径。可以尝试手动创建一个文件测试：

    touch ./log/test.log

    如果无法创建，则可能是路径不存在或权限不足。

  4. 日志轮转配置问题
    如果日志文件没有及时轮转或清理，可能会导致日志文件过大，最终占用磁盘空间。请检查日志轮转配置，确保日志文件不会无限增长。参考文档 OceanBase Binlog 服务 中关于日志管理的部分。

  5. 其他进程占用磁盘空间
    检查是否有其他进程或任务占用了大量磁盘空间，可以通过以下命令查找大文件：

    du -sh ./* | sort -rh | head -n 10

解决建议

1. 检查磁盘配额

如果发现存在磁盘配额限制，可以尝试调整配额设置：

edquota -u <用户名>

或者联系系统管理员解决。

2. 检查 inode 使用情况

如果发现 inode 已经耗尽，可以尝试删除不必要的小文件释放 inode：

find ./log -type f -size -1M -delete

3. 验证日志路径和权限

确保日志路径存在并且有写入权限：

mkdir -p ./log
chmod 755 ./log
chown <用户>:<组> ./log

4. 清理旧日志文件

根据日志轮转策略，清理不再需要的旧日志文件。例如：

find ./log -name "binlog_instance.log.*" -mtime +7 -delete

5. 使用 obdiag 工具诊断

为了进一步排查问题，建议使用 OceanBase 提供的敏捷诊断工具 obdiag 收集相关日志和信息：

obdiag gather scene run --scene=observer.log_archive

并将生成的诊断包提供给我们以进一步分析。

总结

根据目前的信息，问题可能与磁盘配额、inode 耗尽、日志路径权限或日志轮转配置有关。建议按照上述步骤逐一排查，并在必要时提供更详细的日志信息以便进一步分析。如果仍有疑问，请随时联系我们。

具体信息可参考以下文档:

  1. 遇到问题如何向技术支持同学提问
  2. OceanBase Binlog 服务
  3. Alert 日志
  4. OBServer 节点安装目录结构
  5. syslog_level
  6. 日志
  7. 设置日志恢复源
  8. audit_log_max_size
  9. ob_admin 简介

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#9

log.tar.gz (798.4 KB)

#10

没有问题，默认部署在/home/ds目录下的，这个目录就是根目录，截图标红那个。

#11

你能刚报错的时候 这两个日志文件提供一下么？目前只能从cdc日志来看 确实刷新日志的时候 磁盘空间不足导致的

#12

刚刚提供的日志就是报错但是的日志。

#13

目前看不是最初的报错日志信息 没有办法去判断哪里出问题

#14

最初的日志被清理了。

#15

你把这个binlog实例删除以后 重新搭建一个binlog实例 看看是否还有问题 记得日志信息保留