编程 MySQL 26.10 的 Health Monitor 进了社区版：默认只看不拦，磁盘快满也不会把你踢成只读

2026-11-06 21:05:06

MySQL 26.10 的 Health Monitor 进了社区版：默认只看不拦，磁盘快满也不会把你踢成只读

MySQL 26.10 Innovation 把 Health Monitor 组件放进了 Community Edition。此前这类系统资源监控与磁盘容量预测属于需要额外部署的能力，现在可以直接在 MySQL Server 内通过 Performance Schema 查看磁盘、内存、CPU 和 MySQL 进程信息，并配套错误日志消息与诊断报告。对没有独立监控栈的小团队来说，这是“装完就有”的那一层；对有 Prometheus 的团队来说，它是服务端视角的补充，不是替代。

组件暴露了什么

当前与历史资源数据：按 P_S 表结构组织，能用 SQL 直接查，做临时排障比翻 exporter 的时序数据快。
磁盘预测样本与预测汇总：给出的是“按当前增长速率，大概什么时候写满”这类结论，而不只是当前水位。
错误日志消息与诊断报告：资源压力事件会同时落到错误日志和诊断输出里，便于事后对齐时间线。

平台支持上，首个社区版覆盖 Linux 和基础 macOS 采集。macOS 只提供内存、文件系统用量和 CPU 三类信息，没有对应实现的指标以 NULL 暴露，不是 0，也不是缺行。Windows 不在本版范围内。

先确认组件在跑，再决定查哪张表

加载组件按官方发布文档的 INSTALL COMPONENT 语句执行，组件名与 SONAME 以文档为准。装完先确认状态：

SELECT COMPONENT_URN, COMPONENT_STATUS
FROM mysql.component;

P_S 里的表名与字段名以 Health Monitor 组件文档为准，不要凭猜测拼。定位方式是先列出候选表，再按文档前缀过滤：

SELECT TABLE_NAME
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'performance_schema'
  AND TABLE_NAME LIKE '%health%';   -- 前缀以文档为准，不是这个就换模式

找到表之后，常规查法是“当前值一张、历史一张、预测样本一张、预测汇总一张”，字段上区分指标名、采集时间、数值和单位。历史数据受组件自身的保留策略约束，排查长时间趋势前先确认保留窗口，否则会误判成“没有数据”。

fencing 默认关闭到底意味着什么

这是本版最容易被读错的一条。低磁盘 fencing 默认关闭：监控、告警、预测都继续工作，但组件不会因为磁盘将满把实例置为 offline 或 super-read-only。

也就是说，关闭状态下 Health Monitor 只做观察者。磁盘真的写满时，MySQL 该报错还是报错，该写失败还是写失败，redo、binlog、临时文件的写入不会因为组件在监控而变得安全。它给你的是提前量和证据链，不是保护动作。默认关闭本身是保守的选择，把“要不要让数据库自己变只读”这个决定留给运维策略，但前提是通知链路必须有人在看。

需要启用时，同样以文档给出的开关为准，先找出来再设置：

-- 具体变量名/配置项以组件文档为准，这里只是定位思路
SELECT VARIABLE_NAME, VARIABLE_VALUE
FROM performance_schema.global_variables
WHERE VARIABLE_NAME LIKE '%fenc%'
   OR VARIABLE_NAME LIKE '%health%';

确认无误后再按文档 SET PERSIST，并同步进配置管理，别只留在运行时。

和 mysqld_exporter + Prometheus 的分工

两边解决的不是同一个问题：

组件内采集：数据产生在 server 内部，不依赖外部进程存活、不依赖网络可达，DBA 连上去就能查。适合单实例自查、容量预测、和错误日志对照。
中心化告警：Prometheus 负责跨实例、跨系统的聚合与留存，Alertmanager 负责去重、静默、值班路由和“把谁叫醒”。这部分 Health Monitor 不做，也不该由它做。

实际部署里常见的组合是：node_exporter 看整机与所有挂载点，mysqld_exporter 看 MySQL 指标，Health Monitor 补 server 自己算出的磁盘预测。告警规则仍写在 Prometheus 侧，组件侧只作为查询与诊断入口。只用组件而不接通知，等于默认关闭 fencing 之后又没人看告警。

只监控数据目录这个默认值的坑

默认监控的是数据目录所在的文件系统。但 MySQL 会往别的地方写：

SELECT @@datadir,
       @@tmpdir,
       @@log_bin_basename,
       @@innodb_log_group_home_dir;

对照 df -h 看这些路径分别落在哪个挂载点。常见情况是 datadir 在一个大盘上，binlog 单独挂一个小盘，tmpdir 用的是 /tmp，备份写到另一块 NFS 或对象存储网关。这些位置写满同样会让实例不可用，但默认配置下 Health Monitor 看不到。要么把这些路径纳入监控范围（按组件文档支持的配置方式），要么在外层用 node_exporter 的文件系统指标兜住。

启用 fencing 前要确认的策略

fencing 一旦触发，是把实例主动变成不可写。开之前至少把这四件事定下来：

触发后应用侧怎么表现：连接池是否会持续重连报错，读写分离中间件会不会把流量打到别的节点，业务方是否需要提前知道。
阈值和预测窗口：按什么水位触发、提前多久触发。建议先开着监控跑一到两个完整的业务周期，用预测汇总校准，别照搬默认值。
恢复路径：扩容或清理之后，fencing 状态怎么解除，是否需要人工介入，有没有可能卡在只读状态没人处理。
复制拓扑下的影响：单节点被 fence 在组复制或主从结构里意味着什么，是否要保证主库和从库策略一致。

26.10 里的其他改动

同一版本还包括：FIDO 设备认证用于多因素与无密码登录；MySQL REST Service 变成服务器组件，HTTPS 端口、TLS 证书与私钥、工作线程、连接数、请求/响应大小都变成配置变量，并提供启停重启的 SQL 函数和运行时状态变量；EXPLAIN FORMAT=TREE、EXPLAIN ANALYZE 与 JSON 格式 v2 里能看到分区裁剪结果（in partitions (p1) 及结构化的 partitions 数组，描述的是计划选中的读取分区，不是实际访问次数）；JSON Duality Views 支持表级/列级 CHECK/NO CHECK 控制 ETAG 计算与 UPDATE/NO UPDATE；InnoDB redo 解析会缓存内部索引元数据对象；VERSION_WITH_UPDATE() 返回四段式版本号；MySQL Router 支持 --reload-tls 不重启重载 TLS 材料，已有会话保持连接。

复制全文生成海报 MySQL 运维监控容量规划