Cases1 case
1 to 1 of 1
IL-0320Postmark's primary MySQL disk filled but MySQL kept running, so MySQL-MMM never failed over and sending was delayedPostmark2011- Symptoms
At about 8:15am EDT Postmark's primary MySQL server ran out of disk space, and email sending, the API and the web interface were delayed. Disk space alerts fired, but the space had grown much faster than usual and MySQL was already struggling when the alerts were noticed. MySQL kept running while it failed to write some data to disk, so MySQL-MMM, which normally detects problems and fails over to a healthy server, never triggered a failover; the team spent about 30 minutes trying to free logs and disk space before failing over by hand.
- Root cause
- Component
- Contributing factor
- –
- Detection
Per-server monitoring raised disk space alerts, but the disk filled so quickly that MySQL was already struggling by the time the alerts were noticed.
- Remediation
- Tried to free up logs and disk space on the primary server
- Failed over manually to the second MySQL server
- Recovered the jobs that had failed
- Sent the emails that each server had queued locally while the database was unavailable
- Action items
- Upgrade the MySQL cluster with a focus on availability and performance
- Make the alerts more sensitive to catch problems sooner
- Lessons
Looking back, Postmark said it should have failed over to the second server right away instead of first making sure replication was healthy.
This case involves Database and Database failover manager. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.
By root cause1
Capacity exhaustion1 case
- Component
- Contributing factor
- –
- Organisation