{"id":"IL-0485","org":"Dropbox","date":"2014-01-10","docs":[],"title":{"en":"Dropbox went down when an OS upgrade script reinstalled active MySQL master-replica pairs and backup restores ran slow","ko":"계획된 OS 업그레이드 작업이 운영 중인 데이터베이스 서버를 재설치해 Dropbox 서비스가 멈췄다"},"domain":["database"],"impact":{"scope":"Dropbox service down for about three hours after scheduled maintenance; core service not fully restored until 4:40 PM PT on Sunday; user files were not at risk","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"Scripts that verify a machine's production state remotely before upgrading or repurposing it can be wrong, so machines need to check their own state before accepting destructive commands. Replicas give redundancy, but when every replica is lost the restore from backup decides the length of the outage, and the standard MySQL restore tool is slow on large data sets.","ko":"서버 상태를 원격 스크립트로만 확인하면 스크립트의 버그 하나로 운영 서버에 파괴적인 작업이 실행될 수 있으므로, 서버 스스로도 자기 상태를 확인해야 한다. 복제본을 여러 대 두어도 복제본까지 잃으면 백업에서 복원하는 길뿐이다. 큰 데이터에서는 MySQL 표준 복원 도구가 느리므로 복구를 빠르게 할 수단이 필요하다."},"related":[],"sources":[{"url":"https://dropbox.tech/infrastructure/outage-post-mortem","kind":"blog","archived":"https://web.archive.org/web/20260519222716/https://dropbox.tech/infrastructure/outage-post-mortem"}],"summary":{"en":"Dropbox runs thousands of databases, each with one master and two replica machines, and keeps full and incremental backups in a separate environment. During a planned OS upgrade on Friday at 5:30 PM PT, the upgrade script was supposed to verify remotely that each machine had no active data before installing the new OS. A subtle bug in the script made it reinstall a small number of machines that were serving production traffic. Some of them were master-replica pairs, and the site went down.\n\nTo bring the service back as fast as possible, the team recovered the databases from backups. Most functionality was back within about three hours, but the standard tool for recovering MySQL data from backups was slow on the largest databases, and core service was fully restored only at 4:40 PM PT on Sunday. Afterwards Dropbox added a local check on each machine before it runs incoming commands, and built a tool that replays binary logs in parallel to speed up restores of large MySQL backups.","ko":"Dropbox는 수천 개의 데이터베이스를 쓰고, 데이터베이스마다 마스터 한 대와 복제본 두 대를 둔다. 전체 백업과 증분 백업은 별도 환경에 보관한다. 2014-01-10 금요일 오후 5시 30분 PT에 일부 서버의 OS를 올리는 계획된 유지보수를 했다. 업그레이드 스크립트는 새 OS를 설치하기 전에 서버에 사용 중인 데이터가 없는지 원격으로 확인하게 되어 있었다. 스크립트의 잘 드러나지 않는 버그 때문에 운영 트래픽을 받던 서버 몇 대가 재설치됐고, 그중에 같은 데이터베이스의 마스터와 복제본 쌍이 있어 사이트가 내려갔다.\n\n마스터와 복제본을 함께 잃은 데이터베이스는 백업에서 복원하는 방법밖에 없었다. 대부분의 기능은 3시간 안에 돌아왔지만, MySQL 백업을 복원하는 표준 도구가 큰 데이터에서 느려 핵심 서비스가 완전히 돌아온 것은 일요일 오후 4시 40분 PT였다. 이 데이터베이스들에는 파일 데이터가 없어 사용자 파일은 안전했다."},"trigger":{"en":"A planned maintenance on Friday at 5:30 PM PT upgraded the operating system on some machines with a script that was meant to check that a machine held no active data before reinstalling it.","ko":"일부 서버의 OS를 올리는 계획된 유지보수에서 업그레이드 스크립트의 잘 드러나지 않는 버그 때문에 사용 중인 데이터가 있는 서버 몇 대에 재설치 명령이 내려졌다."},"severity":"unknown","symptoms":["service-unavailable"],"timeline":{"detected_after":null,"resolved_after":null},"date_kind":"incident","detection":null,"components":["database","database-backup"],"root_cause":"software-bug","remediation":[{"text":{"en":"Restored the affected databases from backups","ko":"서비스를 빨리 되살리려고 영향을 받은 데이터베이스를 백업에서 복원했다."}}],"action_items":[{"text":{"en":"Add a check that makes each machine verify its own state locally before running incoming commands, so machines running critical processes refuse destructive operations","ko":"서버가 들어온 명령을 실행하기 전에 자기 상태를 로컬에서 확인하는 검사 단계를 더했다. 중요한 프로세스를 돌리고 있다고 스스로 확인한 서버는 파괴적일 수 있는 작업을 거부한다."}},{"text":{"en":"Use a new tool that replays binary logs in parallel to recover large MySQL backups faster","ko":"바이너리 로그 재생을 병렬로 처리하는 도구를 만들어 큰 MySQL 백업에서 더 빨리 복원한다."}},{"text":{"en":"Open source the parallel binary log replay tool","ko":"이 바이너리 로그 병렬 재생 도구를 오픈 소스로 공개할 계획이다."}}],"contributing":["no-safeguard-on-destructive-change"],"recurrence_of":null,"symptoms_text":{"en":"On Friday evening, during scheduled maintenance that started at 5:30 PM PT, the Dropbox service went down. Most functionality came back about three hours later, but core service was not fully restored until 4:40 PM PT on Sunday.\n\nThe affected databases did not hold file data, so user files were not at risk. They back features such as photo album sharing, camera uploads and some API features.","ko":"2014-01-10 금요일 오후 5시 30분 PT에 시작한 계획된 유지보수 중에 Dropbox 서비스가 내려갔다. 약 3시간 뒤 서비스는 다시 올라왔지만, 핵심 서비스가 완전히 돌아온 것은 일요일 오후 4시 40분 PT였다.\n\n멈춘 것은 파일 데이터가 아니라 일부 기능을 받치는 데이터베이스였다. 사진 앨범 공유, 카메라 업로드, 일부 API 기능이 이 데이터베이스를 쓴다.\n\n백업에서 복원하면서 대부분의 기능은 3시간 안에 돌아왔다. 일부 데이터베이스는 크기가 커서 복원이 느렸다."},"updated_at":"2026-11-14T12:34:13.036838Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0485","org_slug":"dropbox"}