Incident Library

IL-0490 LootLocker · 2026-04-28database

관리형 데이터베이스에서 자체 MySQL로 옮긴 뒤 이전 직전에 쓴 기록이 새 데이터베이스에 없어 LootLocker 서비스가 저하됐다

LootLocker는 대형 관리형 데이터베이스 사업자를 떠나 유럽 인프라 협력사 위에서 직접 운영하는 MySQL로 데이터베이스를 옮기고 있었다. 이전 기간 동안 임시 일회성 복제 프로세스가 두 데이터베이스를 맞췄다. 2026-04-20 16:20 BST 무렵 관련 없는 설정 수정 작업 중에 자격 증명을 교체하자 그 자격 증명을 쓰던 복제 프로세스가 죽었다. 프로세스는 몇 분 만에 스스로 살아났지만 그 순간 처리 중이던 묶음은 버려진 채 다시 재생되지 않았다. 프로세스가 정상으로 돌았고 상태나 복제 지연을 보는 모니터링도 없어서 이 손실은 드러나지 않았다.

2026-04-28 10:34 BST에 새 데이터베이스로 전환했고 전환 자체는 문제없이 끝났다. 10:40 무렵 되돌릴 길이 더는 필요 없다고 보고 원본 데이터베이스를 지웠다. 11:30 무렵 운영에서 데이터 이상이 보여 조사를 시작했고, 팀은 원인보다 서비스 동작을 되살리는 일을 먼저 해 13:30 무렵 정상으로 돌렸다. 19:00 무렵 원인을 찾았지만, 버려진 묶음을 다시 재생하려면 지운 원본 데이터베이스가 필요해 이전 사업자에게 복원을 요청해야 했고 복구가 늦어졌다.

원본 데이터베이스를 복원한 뒤 2026-04-29부터 2026-04-30까지 영향을 받은 사용자의 기록을 조금씩 다시 재생했고, 그동안 서비스는 더 멈추지 않았다. LootLocker는 불안정했던 기간에 쓴 데이터 일부가 더 영향을 받았을 가능성을 완전히 배제할 수 없다고 밝혔다. LootLocker는 기여 요인으로 네 가지를 들었다. 임시 동기화 프로세스에 모니터링이 없었고, 런북에 전환 전 동기화 상태와 무결성을 확인하는 단계가 없었다. 자격 증명을 교체할 때 그 자격 증명을 쓰는 프로세스에 미칠 영향을 따지지 않았고, 새 데이터베이스의 무결성을 확인하기 전에 원본 데이터베이스를 지웠다.

심각도
sev2
영향 범위
LootLocker service degraded for about three hours on migration day; a window of writes from 2026-04-19 to 2026-04-20 was missing from the new database until it was replayed over the next two days
영향 사용자
a specific subset of users
지역
–
감지까지
56m
복구까지
2h 56m

증상

2026-04-28 10:34 BST에 새 데이터베이스로 전환한 뒤 11:30 무렵 운영에서 데이터 이상이 보였다. 이전 직전에 쓴 짧은 기간의 데이터가 새 데이터베이스로 복제되지 않았고, 서비스는 전환 때부터 약 3시간 저하됐다.

빠진 것은 2026-04-19부터 2026-04-20에 걸친 짧은 기간의 쓰기였다. 복제 오프셋과 시간대가 맞물린 방식 때문에 전날 데이터 일부도 이 기간에 들어갔다.

데이터가 빠진 일은 8일 전에 이미 일어났지만 이전 당일까지 아무도 몰랐다. 복제 프로세스는 잠깐 죽었다가 몇 분 만에 스스로 살아나 정상으로 복제를 이어 갔기 때문에 무언가를 잃었다는 신호가 없었다. 임시 동기화 프로세스의 상태나 복제 지연을 보는 모니터링과 알림도 없었다.

팀은 근본 원인을 찾기보다 서비스 동작을 되살리는 일을 먼저 했고, 13:30 무렵 서비스가 정상으로 돌아왔다. 원인은 그날 19:00 무렵 찾았지만, 원본 데이터베이스는 전환 직후인 10:40 무렵 이미 지운 뒤였다.

증상 데이터 유실

원인

원인 인증서·자격 증명 만료

구성 요소 데이터베이스데이터베이스 복제
기여 요인 늦게 드러난 변경모니터링 사각지대미검증 가정파괴적 변경 보호 장치 부재
촉발
2026-04-20 16:20 BST 무렵 관련 없는 설정 수정 작업 중에 자격 증명을 교체했다. 그 자격 증명으로 데이터베이스 연결을 잡고 있던 임시 일회성 복제 프로세스가 죽었고, 그 순간 처리 중이던 데이터 묶음이 버려진 뒤 다시 재생되지 않았다.

감지

2026-04-28 11:30 BST 무렵 운영에서 데이터 이상을 발견하고 조사를 시작했다. 8일 전의 손실은 그때까지 아무 신호도 없었다.

조치

후속 조치

교훈

이전 작업 자체는 문제가 없었고, 실패는 8일 전 관련 없는 변경이 조용히 남긴 부작용이었다. 복제 프로세스가 다시 살아나 정상으로 돌았기 때문에 데이터를 잃었다는 신호가 없었고, 전환 전에 데이터 무결성을 확인했다면 트래픽을 다시 받기 전에 잡았을 것이다. 새 데이터베이스의 무결성을 확인하기 전에 원본 데이터베이스를 지운 탓에 복구가 크게 복잡해졌으므로 앞으로는 전환 뒤 확인이 끝날 때까지 원본을 남긴다. 중단을 줄이려고 고른 라이브 이전에는 트래픽이 돌아오기 전에 무결성을 확인할 틈이 없었다. 그 결과 약 3시간의 서비스 저하와 이틀의 복구가 이어졌고, 이는 계획된 유지보수로 서비스를 잠깐 멈췄을 때보다 훨씬 큰 영향이었다. Discord 공지는 영향이 분명하지 않았고 고객이 대비할 시간을 충분히 주지 못했다.

출처

관련 사례

–

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

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

kubegap 열기

AI 도구와 스크립트용

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