Incident Library
Applied filters ComponentDatabaseSymptomFailover failureOrganisationPostmarkClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. 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.

Check your cluster for this

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