Incident Library

IL-0320 Postmark · 2011-10-20 (게시일)database

주 MySQL 서버의 디스크가 가득 차 메일 발송, API, 웹 화면이 지연됐다

오전 8시 15분 EDT 무렵 Postmark 의 주 MySQL 서버가 디스크 공간을 다 써서 메일 발송, API, 웹 화면이 지연됐다. 서버마다 디스크 공간을 감시하는 알림이 있었지만 이번에는 공간이 평소보다 훨씬 빨리 차서, 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다. Postmark 는 MySQL-MMM 으로 고가용성 환경을 운영했다. 그런데 MySQL 이 멈추지 않은 채 일부 데이터만 디스크에 쓰지 못하는 상태여서 MySQL-MMM 이 장애 조치를 시작하지 않았다. 팀은 로그를 지워 공간을 확보하려 애쓰다가 약 30분 뒤 두 번째 서버로 직접 장애 조치했다. 그 뒤 서비스가 정상으로 돌아왔고 팀은 실패한 작업을 복구했다. 데이터베이스를 쓸 수 없을 때 각 서버가 메일을 로컬 큐에 쌓아 두는 장치 덕분에 잃어버린 메일은 없었다.

심각도
–
영향 범위
Email sending, the API and the web interface were delayed; no emails were lost
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

오전 8시 15분 EDT 무렵 주 MySQL 서버의 디스크 공간이 바닥나 메일 발송, API, 웹 화면이 지연됐다. 디스크 공간 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다.

디스크 사용량은 평소보다 훨씬 빨리 늘었다. 서버마다 디스크 공간을 감시해 알리는 장치가 있었다.

MySQL 은 멈추지 않고 계속 돌면서 일부 데이터만 디스크에 쓰지 못했다. 그래서 평소 문제를 감지해 정상 서버로 자동 장애 조치하던 MySQL-MMM 이 이번에는 장애 조치를 시작하지 않았다.

팀은 먼저 로그를 지워 공간을 확보하려 했지만 쉽게 되지 않았다. 복제가 정상인지 먼저 확인하려다가 약 30분 뒤에 두 번째 서버로 장애 조치하기로 했다.

증상 노드 디스크 가득 참쓰기 거부장애 조치 실패

원인

원인 용량 한계

구성 요소 데이터베이스데이터베이스 장애 조치 관리자
기여 요인 –
촉발
–

감지

서버마다 디스크 공간을 감시해 알리는 시스템이 있었다. 이번에는 공간이 평소보다 훨씬 빨리 차서, 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다.

조치

후속 조치

교훈

돌아보면 처음부터 바로 두 번째 서버로 장애 조치했어야 했다. 팀은 복제가 정상인지 먼저 확인하려다가 약 30분을 썼다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 데이터베이스 장애 조치 관리자. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.