Incident Library

IL-0485 Dropbox · 2014-01-10database

계획된 OS 업그레이드 작업이 운영 중인 데이터베이스 서버를 재설치해 Dropbox 서비스가 멈췄다

Dropbox는 수천 개의 데이터베이스를 쓰고, 데이터베이스마다 마스터 한 대와 복제본 두 대를 둔다. 전체 백업과 증분 백업은 별도 환경에 보관한다. 2014-01-10 금요일 오후 5시 30분 PT에 일부 서버의 OS를 올리는 계획된 유지보수를 했다. 업그레이드 스크립트는 새 OS를 설치하기 전에 서버에 사용 중인 데이터가 없는지 원격으로 확인하게 되어 있었다. 스크립트의 잘 드러나지 않는 버그 때문에 운영 트래픽을 받던 서버 몇 대가 재설치됐고, 그중에 같은 데이터베이스의 마스터와 복제본 쌍이 있어 사이트가 내려갔다.

마스터와 복제본을 함께 잃은 데이터베이스는 백업에서 복원하는 방법밖에 없었다. 대부분의 기능은 3시간 안에 돌아왔지만, MySQL 백업을 복원하는 표준 도구가 큰 데이터에서 느려 핵심 서비스가 완전히 돌아온 것은 일요일 오후 4시 40분 PT였다. 이 데이터베이스들에는 파일 데이터가 없어 사용자 파일은 안전했다.

심각도
–
영향 범위
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
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

2014-01-10 금요일 오후 5시 30분 PT에 시작한 계획된 유지보수 중에 Dropbox 서비스가 내려갔다. 약 3시간 뒤 서비스는 다시 올라왔지만, 핵심 서비스가 완전히 돌아온 것은 일요일 오후 4시 40분 PT였다.

멈춘 것은 파일 데이터가 아니라 일부 기능을 받치는 데이터베이스였다. 사진 앨범 공유, 카메라 업로드, 일부 API 기능이 이 데이터베이스를 쓴다.

백업에서 복원하면서 대부분의 기능은 3시간 안에 돌아왔다. 일부 데이터베이스는 크기가 커서 복원이 느렸다.

증상 서비스 중단

원인

원인 소프트웨어 결함

구성 요소 데이터베이스데이터베이스 백업과 스냅숏
기여 요인 파괴적 변경 보호 장치 부재
촉발
일부 서버의 OS를 올리는 계획된 유지보수에서 업그레이드 스크립트의 잘 드러나지 않는 버그 때문에 사용 중인 데이터가 있는 서버 몇 대에 재설치 명령이 내려졌다.

감지

–

조치

후속 조치

교훈

서버 상태를 원격 스크립트로만 확인하면 스크립트의 버그 하나로 운영 서버에 파괴적인 작업이 실행될 수 있으므로, 서버 스스로도 자기 상태를 확인해야 한다. 복제본을 여러 대 두어도 복제본까지 잃으면 백업에서 복원하는 길뿐이다. 큰 데이터에서는 MySQL 표준 복원 도구가 느리므로 복구를 빠르게 할 수단이 필요하다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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