Incident Library

IL-0319 Oregon State University Open Source Lab · 2015-07-30database

mysql2 를 다시 적재하려고 데이터베이스를 지우는 동안 mysql1 의 데이터베이스도 함께 지워졌다

Oregon State University Open Source Lab 의 mysql1 과 mysql2 는 MySQL 5.5 를 쓰는 서버 한 쌍이다. 7월 15일과 16일 mysql2 의 세션 테이블에서 복제 오류가 이어졌고, 팀은 7월 20일 주간에 mysql2 를 통째로 다시 적재하고 행 기반 복제 같은 다른 복제 방식을 살펴보기로 했다. 문서와 팀 안의 지식으로는 두 서버가 마스터-슬레이브 복제였지만 실제로는 마스터-마스터 복제로 설정돼 있었다.

7월 30일 오후 4시 PDT 에 팀은 mysql2 의 슬레이브 복제를 멈추고 데이터베이스를 하나 지울 때마다 잠깐씩 쉬면서 지웠다. mysql2 는 여전히 mysql1 로 명령을 보내고 있었으므로 두 서버 모두에서 데이터베이스가 지워졌다. 스크립트가 중간중간 쉬었기 때문에 몇 분 뒤 mysql1 에서도 데이터베이스가 지워지는 것을 알아챘다. 팀은 스크립트를 멈추고 곧바로 복원을 시작했다.

복원은 세 가지 이유로 예상보다 훨씬 느리고 손이 많이 갔다. 자원 가운데 디스크 공간이 가장 큰 병목이었기 때문에 mysql-zrm 으로 강하게 압축해 백업해 왔다. 그래서 복원할 때 IO 가 아니라 CPU 가 병목이 됐다. 인덱스와 외래 키 문제로 복원이 실패하는 데이터베이스가 몇 개 있었다. 그때마다 약 200GB 백업 파일 전체를 훑어 문제가 난 데이터베이스와 아직 복원하지 못한 나머지를 따로 꺼내야 했다. 백업은 mysql2 에서 떴는데, mysql2 는 처음 동기화가 실패한 탓에 mysql1 보다 뒤처져 있었다. 17일부터 30일까지의 바이너리 로그가 남아 있어 대부분의 데이터는 되살렸지만 15일과 17일 사이의 데이터 일부는 잃었다. 시험용 데이터베이스와 100GB 넘게 불어난 데이터베이스 여러 개도 복원을 크게 늦췄다.

심각도
–
영향 범위
Databases on the mysql1 and mysql2 MySQL cluster were dropped and unavailable until restored; some data written between July 15th and 17th was lost
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

복제 오류를 고치려고 mysql2 의 데이터베이스를 하나씩 지우던 중, 몇 분 뒤 mysql1 에서도 데이터베이스가 지워지고 있는 것을 알아챘다. 지워진 데이터베이스들은 복원될 때까지 쓸 수 없었다.

그 전부터 mysql2 의 복제가 흔들리고 있었다. 7월 15일 세션 테이블 두어 개에서 복제 문제가 나 복제가 멈췄고, 많은 구문을 건너뛴 뒤에야 복제를 다시 시작했다. 7월 16일에는 같은 테이블에서 훨씬 많은 문제가 났고 복제를 여러 번 다시 시작했다. 결국 7월 20일 주간에 mysql2 를 통째로 다시 적재하기로 했다.

문서와 팀 안에서 전해지던 지식으로는 두 서버가 마스터-슬레이브 복제였지만 실제 설정은 마스터-마스터 복제였다. 그래서 mysql2 의 슬레이브 복제를 일부러 멈췄는데도 mysql2 는 여전히 mysql1 로 명령을 보내고 있었다. 이 때문에 mysql2 에서 지운 데이터베이스가 mysql1 에서도 지워졌다.

복원은 예상보다 훨씬 느리고 손이 많이 갔다. mysql-zrm 으로 강하게 압축한 백업이라 복원할 때 CPU 가 병목이 됐다. 인덱스와 외래 키 문제로 복원이 실패하는 데이터베이스가 나올 때마다 약 200GB 짜리 백업 파일 전체를 다시 훑어야 했다. 백업은 mysql1 보다 뒤처진 mysql2 에서 뜨고 있었기 때문에 15일과 17일 사이의 데이터 일부는 되살리지 못했다.

증상 데이터 유실서비스 중단복제 지연

원인

원인 운영 실수

구성 요소 데이터베이스데이터베이스 복제데이터베이스 백업과 스냅숏
기여 요인 미검증 가정미검증 백업
촉발
7월 30일 오후 4시 PDT 에 팀은 복제 오류를 고치려고 mysql2 를 다시 적재하기로 했다. 슬레이브 복제를 멈춘 뒤 mysql2 의 데이터베이스를 하나 지울 때마다 잠깐씩 쉬면서 지웠다.

감지

데이터베이스를 지우는 스크립트가 하나를 지울 때마다 짧게 쉬었기 때문에, 시작하고 몇 분 뒤 mysql1 에서도 데이터베이스가 지워지고 있는 것을 알아챘다.

조치

후속 조치

교훈

Open Source Lab 은 이번 장애에서 MySQL 클러스터를 운영하는 방식과 연구소 전체가 자원을 계획하고 관리하는 방식 모두에서 교훈을 얻었다고 적었다. 디스크 공간을 아끼려고 백업을 강하게 압축한 선택은 전체 복원이 드물었던 그동안에는 괜찮았지만 이번 복원을 크게 늦췄다. 더 많은 프로젝트를 받으려고 자원을 빠듯하게 나눠 써 왔고, 그 대가로 백업을 압축하고 바라던 것보다 이중화를 덜 갖췄다. 장애가 길었던 것과 진행 상황을 알리지 못한 것은 받아들일 수 없는 일이었다고 밝혔다.

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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