MySQL ndbinfo.logbuffers怎样查看日志缓冲区占用

查看 MySQL NDB 日志缓冲区占用，可以查询 ndbinfo.logbuffers，保留节点、日志类型、日志 ID 和分区，再用 used / total 计算每行占用率。不要先合并成集群平均值，也不要把某次占用率直接当作故障原因。以下 SQL 面向 NDB Cluster 8.4，不是普通 InnoDB 实例的日志监控方法。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/mysql-cluster-ndbinfo-logbuffers.html

写入规模扩大时，先明确要看哪种占用

考虑一个批量写入和定期备份共存的 NDB 集群：业务想知道“日志相关空间是否紧张”，但这个问题还需要缩小到缓冲区。本文只提供只读观测设计，不声称已经在某个生产集群执行，也不凭一张采样结果调整配置。

分布式环境下，统计对象的身份和数值同样重要。节点、日志类型、日志 ID、分区用于区分对象；total 和 used 描述该对象的容量与占用。MySQL 官方对这六列的定义及备份行出现条件见 logbuffers 表说明。

集群平均值为什么会掩盖局部压力

如果原先只保留一个“集群平均占用率”，节点之间的差异会被压平。算术平均还会让不同容量的缓冲区获得相同权重；把所有 used 与 total 相加则容易混合不同日志用途。两种汇总都无法代替明细。

更合适的观测模型是“行身份 + 原始容量 + 派生比例”。这里不是修改 NDB 的架构，而是改造监控数据的组织方式：先留下可以追溯的对象，再按需要汇总。代价是标签和记录更多，收益是能回答究竟哪一类、哪一个节点的对象值得继续关注。

保留行身份，建立只读占用视图

在连接到 NDB 集群的 SQL 节点、具备相应读取权限的会话中，可以使用下面的查询。保留完整限定表名，避免当前默认数据库改变查询对象。

-- 读取每个对象的原始容量和占用，不修改集群数据
SELECT node_id, log_type, log_id, log_part,
       total, used,
       -- 分母为零时保留 NULL，不能把未知比例伪装成零占用
       ROUND(100.0 * used / NULLIF(total, 0), 2) AS used_pct
FROM ndbinfo.logbuffers
-- 保留类型和身份字段，便于连续采样时对照同一对象
ORDER BY log_type, node_id, log_id, log_part;

used_pct 是查询新增的百分比，不是表中的原生字段。例如比例 0.25 对应 25%，这是算术解释，不是实测输出。保留 total 和 used，才能在比例变化时判断是容量变化还是占用变化。示例不额外假设容量单位，也不引入该表文档未列出的高水位字段。

若读者仅关注 REDO，可在同一查询中增加 WHERE log_type = 'REDO'。过滤应在理解全量类型之后使用，而不是把其他类型缺失误读成零占用。

细粒度采样的收益与代价

明细模式对定位更有帮助，但不是采样越频繁越好。采样周期需要兼顾业务峰值持续时间、记录成本和系统负担；没有一条对所有集群都适用的秒级设置。降低周期可能更容易捕捉短暂上升，也会增加查询和保存次数。

第一次接入时可以保留原始字段和采集时间，再根据实际用途裁剪。采集时间应由监控端明确记录；不要声称一次查询是跨所有节点、同一瞬间的完整事务快照。

备份期间新增的两类行怎么解释

log_type 可以出现 REDO、DD-UNDO、BACKUP-DATA 和 BACKUP-LOG。其中 BACKUP-DATA 反映备份复制分片到备份文件时的数据缓冲区，BACKUP-LOG 对应记录备份启动后变更的日志缓冲区。官方明确：备份正在执行时，每个数据节点才会出现这两类行；备份未执行时不会显示它们。

因此，“没有备份类型行”和“存在备份类型行且 used 为零”是两种不同的采样状态。前者不能补写成采到了零值。监控存储应保留缺失状态，不要为了图表连续而混淆对象不存在与对象空闲。

把占用记录变成可比较的观察

接入后的成果不应是一句“已经解决日志瓶颈”，而是同一对象在不同采样时点可以比较。占用率升高且随后回落，和持续保持较高占用值得采用不同的观察策略；这些判断仍须结合业务负载、备份状态和已有运行记录，不能单靠一列得出磁盘故障或容量配置不足的结论。

建议把环境标识、采集时间与四个身份字段一起保存。发生节点或配置变化时重新建立可比基线，避免将不再相同的对象接成一条曲线。告警阈值由实际基线和运行目标确定，本例不提供未经负载验证的通用阈值，也不包含重启或修改参数的操作。

为什么普通 MySQL 实例查不到这个表？

本文的适用对象是 NDB Cluster，而不是用同名查询替代 InnoDB 的监控。先确认连接的环境和权限，再判断表是否可读取；不存在不能解释成使用率为零。

查询里的 NULL 应不应该显示为 0%？

不应该直接替换。本例在 total 为零时主动返回 NULL，表达占用率无有效分母。显示层应标为不可计算，并保留原始字段供分析。

只存节点号能否关联前后采样？

不足以区分本文讨论的各类对象。至少连同日志类型、日志 ID 和分区一起记录，再加环境和采集时间；需要额外稳定标识时应由实际部署补充。

查询这张表的关键不是更复杂的 SQL，而是保留对象身份、解释分母、识别备份行的适用范围。把它作为观察入口，才不会把一张动态明细表误用成自动调整配置的依据。