Incident Library

IL-0573 Woowa Brothers · 2016-12-27database

개발자의 실수로 MariaDB 빌링 데이터베이스의 주요 테이블 9개가 DROP되어 배달의민족 결제가 잠시 멈췄다

2016년 12월 27일 오후 3시 우아한형제들의 빌링 시스템 개발자가 실수로 MariaDB 빌링 데이터베이스의 주요 테이블 9개를 DROP했고, 배달의민족 결제가 잠시 중단됐다. 애플리케이션이 임시 데이터베이스를 보도록 바꿔 장애 시간은 길지 않았다. 빌링 데이터베이스는 매일 새벽 6시 mysqldump로 테이블별 SQL 파일을 만들어 압축해 두고 있었고, 개발자는 이 Full Backup으로 빌링 시스템을 연 때부터 그날 새벽 6시까지의 데이터를 되살렸다. 새벽 6시부터 15시까지의 데이터는 mysqlbinlog의 --start-datetime 과 --stop-datetime 으로 binary log에서 그 구간을 뽑아 restore.log에 저장했다. 개발자는 이 파일을 9개 테이블만 남기도록 고친 뒤 실행해 복구했다. 종료 시각을 잘못 잡으면 DROP TABLE 쿼리가 다시 실행될 수 있어 주의해야 했다.

그 뒤 빌링 데이터베이스를 새 서버로 옮기는 대규모 개편에서, 같은 방식으로 백업 데이터를 넣었더니 주요 결제 테이블 하나에도 엄청난 시간이 걸렸다. 배달의민족 주문이 크게 늘어 데이터가 쌓였기 때문이다. 비슷한 장애 때 복구에 몇십 시간을 쓸 수 없다고 본 팀은 엔진 데이터를 그대로 복사하는 물리 백업 도구 Percona XtraBackup으로 백업 방식을 바꿨다.

심각도
–
영향 범위
배달의민족 (Baemin) payments stopped briefly; nine main tables of the billing database were lost until they were restored
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

2016년 12월 27일 오후 3시, 결제 시스템 모듈을 개발하던 개발자의 실수로 빌링 데이터베이스의 주요 테이블 9개가 DROP됐다. 모니터링 시스템에 빨간불이 들어오고 장애 알림이 쏟아졌으며, 배달의민족 결제가 잠시 중단됐다.

증상 데이터 유실서비스 중단

원인

원인 운영 실수

구성 요소 데이터베이스데이터베이스 백업과 스냅숏
기여 요인 –
촉발
결제 시스템 모듈을 개발하던 개발자가 실수로 빌링 데이터베이스의 주요 테이블 9개를 DROP했다.

감지

모니터링 시스템에 빨간불이 들어오고 장애 알림이 쏟아져 알았다.

조치

후속 조치

교훈

장애를 관리할 지점은 많다. 데이터베이스의 서비스용 계정과 관리용 계정을 나누는 것, 쿼리를 보내기 전에 한 번 더 확인하는 것, rm -rf를 막는 것이 그 예다. 전체 백업과 binary log가 없었다면 복구할 수 없었으므로, 장애 때 전체를 복구할 지점이 있는지 점검해야 한다. 데이터가 수십에서 수백 GB에 이르면 mysqldump로는 백업과 복구에 너무 오래 걸린다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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