GridDB出现LM_WRITE_LOG_FAILED ERROR 80000的原因与排查咨询

你遇到的80000 LM_WRITE_LOG_FAILED ERROR是GridDB日志写入失败的典型报错，以下针对你的需求逐一说明：

1. 该错误的常见原因 #

• 权限不足：GridDB运行进程（默认是griddb系统用户）没有日志目录/var/log/griddb的读写权限，即使磁盘有剩余空间也无法写入。
• 磁盘IO异常：存储磁盘存在坏道、IO响应超时，或者集群使用的共享存储（如SAN/NAS）连接不稳定，导致日志写入操作失败。
• inode耗尽：磁盘剩余空间充足，但日志目录下的文件数量过多，耗尽了inode资源，无法创建新的日志文件。
• 集群节点配置不一致：5节点集群中，部分节点的日志目录实际空间不足、权限异常，或者存储挂载配置有差异，导致单节点写入失败触发集群报错。
• 日志轮转失效：未配置或日志轮转规则不合理，日志文件持续增大未被切割，超过系统文件大小限制或磁盘IO承载能力。

2. GridDB日志存储最佳实践 #

• 权限固化：确保griddb用户拥有日志目录的完整权限：

  chown -R griddb:griddb /var/log/griddb
  chmod -R 750 /var/log/griddb
  

• 配置日志轮转：通过logrotate自动切割日志，避免文件过大。创建/etc/logrotate.d/griddb配置文件：

  /var/log/griddb/*.log {
      daily
      rotate 7
      compress
      delaycompress
      missingok
      notifempty
      create 640 griddb griddb
      postrotate
          systemctl reload griddb
      endscript
  }
  

• 存储分离：将日志目录与GridDB数据目录挂载到不同磁盘分区，避免数据IO高峰影响日志写入，同时防止数据分区满溢波及日志存储。
• 集群统一配置：所有5个节点的日志路径、权限、存储配置保持完全一致，定期巡检节点状态避免差异。
• 日志级别优化：根据运维需求调整GridDB日志级别（默认是INFO），关闭DEBUG级别的冗余日志，降低IO写入压力。

3. 问题定位的诊断方法 #

• 权限与inode检查：

  # 检查日志目录权限
  ls -ld /var/log/griddb
  # 检查inode使用情况
  df -i /var/log/griddb
  # 切换到griddb用户测试写入
  su - griddb -c "touch /var/log/griddb/test_write.log && rm /var/log/griddb/test_write.log"
  

• 磁盘健康与IO诊断：

  # 检查磁盘健康状态（需安装smartmontools）
  smartctl -a /dev/sda # 替换为你的磁盘设备
  # 实时监控磁盘IO使用率
  iostat -x 1 10
  # 查看系统层面的磁盘IO错误
  dmesg | grep -E 'IO error|disk failure'
  

• 集群节点巡检：登录每个集群节点，重复上述检查步骤，确认所有节点的日志目录状态一致；查看节点本地的GridDB日志/var/log/griddb/gs_log，获取更详细的错误堆栈信息。
• 安全策略检查：查看SELinux或AppArmor是否阻止了GridDB的写入操作：

  # SELinux日志检查
  ausearch -m avc -ts recent | grep griddb
  # AppArmor状态检查
  aa-status | grep griddb
  

内容的提问来源于stack exchange，提问作者omar esawy