{"id":"IL-0573","org":"Woowa Brothers","date":"2016-12-27","docs":[],"title":{"en":"A developer's mistake dropped nine main tables of the Baemin billing MariaDB database and payments briefly stopped","ko":"개발자의 실수로 MariaDB 빌링 데이터베이스의 주요 테이블 9개가 DROP되어 배달의민족 결제가 잠시 멈췄다"},"domain":["database"],"impact":{"scope":"배달의민족 (Baemin) payments stopped briefly; nine main tables of the billing database were lost until they were restored","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"There are many points where such failures can be managed: separate database accounts for the service and for administration, check once more before running a query, and guard against rm -rf. Without the full backup and the binary log the data could not have been recovered, so every team should check that it has a full recovery point for a failure.","ko":"장애를 관리할 지점은 많다. 데이터베이스의 서비스용 계정과 관리용 계정을 나누는 것, 쿼리를 보내기 전에 한 번 더 확인하는 것, rm -rf를 막는 것이 그 예다. 전체 백업과 binary log가 없었다면 복구할 수 없었으므로, 장애 때 전체를 복구할 지점이 있는지 점검해야 한다. 데이터가 수십에서 수백 GB에 이르면 mysqldump로는 백업과 복구에 너무 오래 걸린다."},"related":[],"sources":[{"url":"https://techblog.woowahan.com/2576/","kind":"blog","archived":"https://web.archive.org/web/20240526111700/https://techblog.woowahan.com/2576/"}],"summary":{"en":"The dropped tables belonged to the MariaDB billing database of Woowa Brothers. The outage stayed short because the application was changed to point at a temporary database. The billing database was backed up in full with mysqldump every day at 6:00, as compressed SQL files per table, so the dropped tables could be restored easily from that backup; with a lot of payment data this took some time, but it brought back the data up to 6:00. The data written between 6:00 and 15:00 was recovered from the MariaDB binary log: mysqlbinlog with --start-datetime=\"2016-12-27 06:00:00\" and --stop-datetime=\"2016-12-27 15:00:00\" turned the binary logs into a restore.log file, which was edited to keep only the nine tables and then applied to the database; the stop time had to be set so that the DROP TABLE statement would not run again. With that, all data was restored.\n\nLater, during a large reorganisation of the billing database onto new servers with partitioning, restoring a single main payment table from a mysqldump backup took an enormous amount of time because order volume and data had grown fast. The team concluded that mysqldump backup and restore was no longer usable, since a similar failure would take tens of hours to recover, and moved the billing database to full physical backups with Percona XtraBackup 2.4 on MariaDB 10.2.x and CentOS 6.x, without incremental backups to keep recovery simple, using the binary log position recorded at backup time for point-in-time recovery.","ko":"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 쿼리가 다시 실행될 수 있어 주의해야 했다.\n\n그 뒤 빌링 데이터베이스를 새 서버로 옮기는 대규모 개편에서, 같은 방식으로 백업 데이터를 넣었더니 주요 결제 테이블 하나에도 엄청난 시간이 걸렸다. 배달의민족 주문이 크게 늘어 데이터가 쌓였기 때문이다. 비슷한 장애 때 복구에 몇십 시간을 쓸 수 없다고 본 팀은 엔진 데이터를 그대로 복사하는 물리 백업 도구 Percona XtraBackup으로 백업 방식을 바꿨다."},"trigger":{"en":"While developing a payment system module, the developer who wrote the post dropped nine main tables of the billing database by mistake.","ko":"결제 시스템 모듈을 개발하던 개발자가 실수로 빌링 데이터베이스의 주요 테이블 9개를 DROP했다."},"severity":"unknown","symptoms":["data-loss","service-unavailable"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":{"en":"The monitoring system turned red and failure alerts fired.","ko":"모니터링 시스템에 빨간불이 들어오고 장애 알림이 쏟아져 알았다."},"components":["database","database-backup"],"root_cause":"human-operation","remediation":[{"text":{"en":"Pointed the application at a temporary database, which kept the outage short","ko":"애플리케이션이 임시 데이터베이스를 보도록 고쳐 결제 중단 시간을 줄였다."}},{"text":{"en":"Restored the dropped tables from the 6:00 mysqldump full backup","ko":"매일 새벽 6시 mysqldump로 만든 Full Backup 파일을 풀어 DB에 실행해, 빌링 시스템을 연 때부터 새벽 6시까지의 데이터를 복구했다."}},{"text":{"en":"Replayed the binary log from 6:00 to 15:00 with mysqlbinlog, filtered to the nine tables and stopping before the DROP TABLE","ko":"mysqlbinlog로 binary log에서 2016-12-27 06:00:00 부터 15:00:00 까지의 이벤트를 restore.log에 뽑고, 9개 테이블만 남기도록 고친 뒤 mysql에 실행해 나머지 데이터를 복구했다."}}],"action_items":[{"text":{"en":"Replace mysqldump backups of the billing database with full backups taken by XtraBackup","ko":"빌링 데이터베이스는 장애 때 복구 과정을 단순하게 하려고 XtraBackup으로 증분 백업 없이 전체 백업을 한다."}}],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"At 15:00 on 27 December 2016, while a developer was working on a payment system module, nine main tables of the billing database were dropped. The monitoring system turned red, failure alerts poured in, and payments in 배달의민족 (Baemin) stopped for a while.","ko":"2016년 12월 27일 오후 3시, 결제 시스템 모듈을 개발하던 개발자의 실수로 빌링 데이터베이스의 주요 테이블 9개가 DROP됐다. 모니터링 시스템에 빨간불이 들어오고 장애 알림이 쏟아졌으며, 배달의민족 결제가 잠시 중단됐다."},"updated_at":"2026-11-14T12:34:22.018182Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0573","org_slug":"woowa-brothers"}