사례1건

1건 중 1~1번째

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

   Woowa Brothers2016

   증상

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

   데이터 유실서비스 중단

   촉발

   결제 시스템 모듈을 개발하던 개발자가 실수로 빌링 데이터베이스의 주요 테이블 9개를 DROP했다.

   원인

   운영 실수

   구성 요소

   데이터베이스데이터베이스 백업과 스냅숏

   기여 요인

   –

   감지

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

   조치

   • 애플리케이션이 임시 데이터베이스를 보도록 고쳐 결제 중단 시간을 줄였다.
   • 매일 새벽 6시 mysqldump로 만든 Full Backup 파일을 풀어 DB에 실행해, 빌링 시스템을 연 때부터 새벽 6시까지의 데이터를 복구했다.
   • mysqlbinlog로 binary log에서 2016-12-27 06:00:00 부터 15:00:00 까지의 이벤트를 restore.log에 뽑고, 9개 테이블만 남기도록 고친 뒤 mysql에 실행해 나머지 데이터를 복구했다.

   후속 조치

   • 빌링 데이터베이스는 장애 때 복구 과정을 단순하게 하려고 XtraBackup으로 증분 백업 없이 전체 백업을 한다.

   교훈

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

   사례 보기

원인별1