MariaDB 静默崩溃：当日志沉默掩盖了关键故障

问题

2026 年 1 月至 3 月间，我们在一台由 PmaControl 监控的生产 MariaDB 10.11.15 服务器上观察到 6 次异常的 uptime 重置。该服务器托管非常大的分区 RocksDB 表（时间序列指标）。

DBA 面对崩溃时的经典反应：检查系统日志。journalctl、dmesg、/var/log/syslog。查找 OOM、Killed process、segfault、kernel panic。

在 6 次崩溃中，只有一次有可利用的内核追踪信息。 其余 5 次：系统端完全沉默。

检测方法

我们没有依赖系统日志，而是使用 PmaControl 通过 uptime 时间序列来检测崩溃：

1. 从 ts_value_general_int 获取 uptime 值
2. 过滤异常重置（uptime 降回 0）
3. 与 MariaDB 日志（error.log）关联
4. 与 journalctl 关联，查找内核签名
5. 分析前一小时的指标（线程、CPU、内存）

这是最可靠的方法：uptime 重置 + InnoDB crash recovery 签名 = 确认崩溃，即使没有系统追踪。

识别出的 6 次崩溃

3 月 6 日的崩溃：MDEV-39044 关联

最严重的事故发生在 3 月 6 日。错误信息有所不同：

RocksDB: Error opening instance, Status Code: 2,
  Status: Corruption: truncated record body
Incorrect information in file: './pmacontrol/ts_value_general_int.frm'
Can't init tc log
Aborting

这个模式与 MariaDB 工单 MDEV-39044 完全吻合：MyRocks 损坏由以下因素触发：

• 在大型分区 RocksDB 表上执行 ALTER TABLE
• 持续的高写入负载
• 同时存在的 InnoDB 内存压力

该工单明确确认在此场景下，没有崩溃日志或 OOM killer 是正常的。

为什么系统日志不够用

在 6 次事故中，journalctl 只找到一条可利用的追踪（3 月 12 日的 status=9/KILL）。

对于其余 5 次：

• 没有 Out of memory
• 没有 Killed process
• 没有 segfault
• 没有 kernel panic

推论很简单：没有内核签名并不能排除事故。这甚至与 MDEV-39044 的模式一致，该文档记录了没有系统追踪的崩溃。

PmaControl 能检测到日志无法显示的内容

PmaControl 持续监控 uptime（每 10 秒）。重置 = 立即告警。代理随后自动关联：

• 前一小时的指标（线程、内存、CPU）
• error log 中是否存在 crash recovery
• 元数据错误（.frm mismatch）

这使得即使没有内核配合也能对事故进行分类。

建议

1. 永远不要仅依赖系统日志来检测 MariaDB 崩溃
2. 将 uptime 作为主要的稳定性指标进行监控
3. 与 MariaDB error log 关联，而不是与 journalctl
4. 如果使用 RocksDB：限制在大型分区表上的 DDL 操作，特别是在高写入负载下
5. 关注 MDEV-39044 以获取潜在的 MyRocks 修复

总结

一台 MariaDB 服务器可以在 6 周内崩溃 6 次而没有任何系统日志记录。只有专门的数据库监控 — 理解 MariaDB 内部恢复签名的监控 — 才能检测和分类这些事故。

这正是 PmaControl 所做的。