Incident Library

IL-0489 Magic Pages · 2025-01-15databasekubernetes

Kubernetes 위 3노드 MySQL 클러스터에 노드를 다시 붙이다 메타데이터가 깨져 Magic Pages 고객 사이트가 내려갔다

Magic Pages는 노드 세 대로 된 고가용성 MySQL 데이터베이스 클러스터를 쓴다. 2025-01-15 노드 하나가 내려갔고, 나머지 두 노드가 설계대로 서비스를 이어 갔다. 문제는 창업자가 세 번째 노드를 다시 붙이려 할 때 시작됐다. 데이터베이스 서버가 메타데이터가 없다는 모호한 오류를 냈고, 메타데이터를 다시 만들려고 노드 하나로 줄이자 두 번째 노드에서도 비슷한 오류가 났다.

원인은 Kubernetes의 PVC였다. PVC는 있는 것처럼 보였지만 다시 만들어야 하는 데이터베이스 노드에 새 볼륨을 프로비저닝하지 못했다. 스토리지 서버를 재시작하자 몇 초 만에 PVC 프로비저닝 문제가 풀렸다. 클러스터 메타데이터를 다시 만들려면 MySQL 노드들이 복원되고 서로 동기화돼야 해서 약 45분이 걸렸다. 마지막으로 깨진 메타데이터를 정리하고 MySQL Router를 다시 배포하자 장애가 끝났다. 장애는 09:55 CET 무렵부터 11:36 CET까지 고객 웹사이트에 영향을 줬다. 데이터는 잃지 않았다.

심각도
–
영향 범위
Magic Pages customer websites, which depend on the MySQL cluster, from about 09:55 to 11:36 CET
영향 사용자
Magic Pages customers
지역
–
감지까지
–
복구까지
1h 41m

증상

2025-01-15 09:55 CET 무렵부터 11:36 CET까지 데이터베이스 장애로 Magic Pages의 고객 웹사이트가 영향을 받았다. 노드 세 대로 된 MySQL 클러스터에서 내려간 노드를 다시 붙이려 하자 데이터베이스 서버가 메타데이터 정보가 없다는 모호한 오류를 냈다.

처음에는 클러스터 구성 문제로 보고, 메타데이터를 다시 만들려고 노드 하나로 줄였다. 그러자 두 번째 노드에서도 비슷한 오류가 났다.

Kubernetes의 Persistent Volume Claim, 줄여서 PVC는 있는 것처럼 보였지만 다시 만들어야 하는 데이터베이스 노드에 새 볼륨을 제대로 프로비저닝하지 못하고 있었다.

Magic Pages의 상태 페이지는 고객 웹사이트가 실패하면 알아채도록 설정돼 있었지만 이 장애를 바로 잡아내지 못했다.

증상 서비스 중단

원인

원인 의존성 장애

구성 요소 데이터베이스영구 볼륨과 스테이트풀셋
기여 요인 수동 조치 악화단일 장애점모니터링 사각지대
촉발
그날 앞서 MySQL 클러스터의 세 노드 중 하나가 내려갔고, 창업자가 그 노드를 클러스터에 다시 붙이려 했다.

감지

–

조치

후속 조치

교훈

고가용성 구성 덕분에 데이터는 잃지 않았고 첫 노드 장애도 클러스터가 문제없이 넘겼다. 하지만 중복 구성인데도 클러스터 메타데이터가 단일 장애 지점이었다. PVC 상태를 더 잘 모니터링했다면 비슷한 문제를 막을 수 있었고, 45분 걸린 복구는 더 줄일 여지가 있다. 상태 페이지는 고객 사이트 실패를 감지하도록 설정했는데도 이 장애를 바로 알아채지 못했다.

출처

관련 사례

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

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 영구 볼륨과 스테이트풀셋. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

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