{"id":"IL-0320","org":"Postmark","date":"2011-10-20","docs":[],"title":{"en":"Postmark's primary MySQL disk filled but MySQL kept running, so MySQL-MMM never failed over and sending was delayed","ko":"주 MySQL 서버의 디스크가 가득 차 메일 발송, API, 웹 화면이 지연됐다"},"domain":["database"],"impact":{"scope":"Email sending, the API and the web interface were delayed; no emails were lost","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Looking back, Postmark said it should have failed over to the second server right away instead of first making sure replication was healthy.","ko":"돌아보면 처음부터 바로 두 번째 서버로 장애 조치했어야 했다. 팀은 복제가 정상인지 먼저 확인하려다가 약 30분을 썼다."},"related":[],"sources":[{"url":"https://postmarkapp.com/blog/what-happened-this-morning","kind":"blog","archived":"https://web.archive.org/web/20260613211347/https://postmarkapp.com/blog/what-happened-this-morning"}],"summary":{"en":"Postmark runs MySQL in a high-availability setup with MySQL-MMM, which usually detects a failing server and fails over automatically. At about 8:15am EDT the disk of the primary MySQL server filled much faster than normal and ran out of space, and email sending, the API and the web interface were delayed. MySQL did not stop; it only had trouble writing some data to disk, so MySQL-MMM saw no reason to fail over. The team first tried to free up logs and space, and after about 30 minutes, having wanted to confirm that replication was healthy first, failed over manually to the second server. Service returned to normal and the team recovered the failed jobs. No email was lost, because when the database is unavailable each Postmark server queues emails locally and sends them after recovery.","ko":"오전 8시 15분 EDT 무렵 Postmark 의 주 MySQL 서버가 디스크 공간을 다 써서 메일 발송, API, 웹 화면이 지연됐다. 서버마다 디스크 공간을 감시하는 알림이 있었지만 이번에는 공간이 평소보다 훨씬 빨리 차서, 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다. Postmark 는 MySQL-MMM 으로 고가용성 환경을 운영했다. 그런데 MySQL 이 멈추지 않은 채 일부 데이터만 디스크에 쓰지 못하는 상태여서 MySQL-MMM 이 장애 조치를 시작하지 않았다. 팀은 로그를 지워 공간을 확보하려 애쓰다가 약 30분 뒤 두 번째 서버로 직접 장애 조치했다. 그 뒤 서비스가 정상으로 돌아왔고 팀은 실패한 작업을 복구했다. 데이터베이스를 쓸 수 없을 때 각 서버가 메일을 로컬 큐에 쌓아 두는 장치 덕분에 잃어버린 메일은 없었다."},"trigger":null,"severity":"unknown","symptoms":["node-disk-full","writes-rejected","failover-failed"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"published","detection":{"en":"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.","ko":"서버마다 디스크 공간을 감시해 알리는 시스템이 있었다. 이번에는 공간이 평소보다 훨씬 빨리 차서, 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다."},"components":["database","failover-manager"],"root_cause":"capacity","remediation":[{"text":{"en":"Tried to free up logs and disk space on the primary server","ko":"로그를 지워 디스크 공간을 확보하려 했지만 쉽게 되지 않았다."}},{"text":{"en":"Failed over manually to the second MySQL server","ko":"약 30분 뒤 두 번째 서버로 직접 장애 조치했고, 그 뒤 서비스가 정상으로 돌아왔다."}},{"text":{"en":"Recovered the jobs that had failed","ko":"장애 조치 뒤 실패한 작업을 복구했다."}},{"text":{"en":"Sent the emails that each server had queued locally while the database was unavailable","ko":"데이터베이스를 쓸 수 없는 동안 각 서버가 메일을 로컬 큐에 쌓아 두었다가 복구 뒤 보냈으므로 잃어버린 메일은 없었다."}}],"action_items":[{"text":{"en":"Upgrade the MySQL cluster with a focus on availability and performance","ko":"가용성과 성능에 초점을 맞춰 클러스터를 업그레이드한다."}},{"text":{"en":"Make the alerts more sensitive to catch problems sooner","ko":"문제를 더 일찍 잡도록 알림을 조금 더 민감하게 바꾼다."}}],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"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.","ko":"오전 8시 15분 EDT 무렵 주 MySQL 서버의 디스크 공간이 바닥나 메일 발송, API, 웹 화면이 지연됐다. 디스크 공간 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다.\n\n디스크 사용량은 평소보다 훨씬 빨리 늘었다. 서버마다 디스크 공간을 감시해 알리는 장치가 있었다.\n\nMySQL 은 멈추지 않고 계속 돌면서 일부 데이터만 디스크에 쓰지 못했다. 그래서 평소 문제를 감지해 정상 서버로 자동 장애 조치하던 MySQL-MMM 이 이번에는 장애 조치를 시작하지 않았다.\n\n팀은 먼저 로그를 지워 공간을 확보하려 했지만 쉽게 되지 않았다. 복제가 정상인지 먼저 확인하려다가 약 30분 뒤에 두 번째 서버로 장애 조치하기로 했다."},"updated_at":"2026-11-14T12:33:57.348649Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0320","org_slug":"postmark"}