IL-0385 GitHub · 2021-11-27database
큰 MySQL 테이블의 스키마 마이그레이션 마지막 단계에서 읽기 복제본 다수가 semaphore deadlock 에 걸려 GitHub 핵심 서비스가 2시간 50분 저하됐다
GitHub 은 스키마 마이그레이션을 자주 하고, 한 번에 몇 주가 걸리기도 한다. 마이그레이션의 마지막 단계는 갱신한 테이블을 rename 으로 제자리에 옮기는 일이다. 2021년 11월 27일 20:40 UTC 에 큰 MySQL 테이블의 마이그레이션이 이 단계에 이르자 읽기 복제본 상당수가 semaphore deadlock 에 걸렸다. GitHub 은 이것을 처음 겪는 장애 양상이라고 했다. GitHub 의 MySQL 클러스터는 쓰기를 받는 primary 노드 하나, 운영 트래픽을 받는 읽기 복제본 여러 대, 백업과 분석용 내부 읽기를 받는 복제본 몇 대로 이루어진다. deadlock 에 걸린 복제본은 crash-recovery 상태로 들어갔고, 정상 복제본에 부하가 몰리면서 연쇄로 번져 운영 요청을 감당할 활성 읽기 복제본이 모자라게 됐다. 그 결과 GitHub 의 핵심 서비스가 저하됐다.
대응하는 동안 용량을 늘리려고 정상인 내부 복제본을 모두 운영 경로로 올렸지만 충분하지 않았다. 운영 트래픽을 받는 복제본은 잠시 회복했다가 부하로 다시 죽기를 되풀이했다. GitHub 은 사이트 가용성보다 데이터 무결성을 먼저 지키기로 하고, 망가진 복제본에서 운영 트래픽을 미리 빼 테이블 rename 을 끝까지 처리하게 했다. 복제본이 회복하자 운영에 다시 넣어 용량을 되찾았고, 장애는 2시간 50분 만에 끝났다. 쓰기 작업은 내내 정상이었고, GitHub 은 데이터 손상이 없었음을 확인했다.
- 심각도
- –
- 영향 범위
- Core GitHub services were degraded: GitHub Actions, API Requests, Codespaces, Git Operations, Issues, GitHub Packages, GitHub Pages, Pull Requests and Webhooks; write operations stayed healthy
- 영향 사용자
- –
- 지역
- –
- 감지까지
- –
- 복구까지
- 2h 50m
증상
2021년 11월 27일 20:40 UTC 부터 GitHub Actions, API 요청, Codespaces, Git 작업, Issues, GitHub Packages, GitHub Pages, Pull Requests, Webhooks 의 가용성이 떨어졌다. 큰 MySQL 테이블의 스키마 마이그레이션이 마지막 rename 단계를 실행하던 때였다.
MySQL 읽기 복제본 상당수가 semaphore deadlock 에 걸린 뒤 crash-recovery 상태로 들어갔다. 이 복제본들이 빠지자 남은 정상 읽기 복제본에 부하가 몰렸다.
부하가 연쇄로 번지면서 운영 요청을 받을 활성 읽기 복제본이 모자라게 됐다. 운영 트래픽을 받는 복제본은 crash-recovery 에서 잠시 살아났다가 부하 때문에 다시 죽기를 되풀이했다. 쓰기 작업은 내내 정상이었다.
처음에는 용량을 늘리려고 정상 상태인 내부용 복제본을 모두 운영 경로로 올렸다. 그래도 완전히 복구되지는 않았다.
원인
원인 소프트웨어 결함
- 촉발
- 큰 MySQL 테이블의 스키마 마이그레이션이 마지막 단계로 갱신한 테이블을 제자리로 옮기는 rename 을 실행했다. 이때 읽기 복제본 상당수가 semaphore deadlock 에 걸렸다.
감지
–
조치
- 정상 상태인 내부용 복제본을 모두 운영 경로로 올려 용량을 늘렸다. 이것만으로는 완전히 복구되지 않았다.
- crash-recovery 를 되풀이하는 복제본에서 운영 트래픽을 미리 빼고, 그 복제본이 테이블 rename 을 끝까지 처리할 때까지 기다렸다.
- 회복한 복제본을 운영에 다시 넣어 정상 운영에 필요한 용량을 되찾았다.
후속 조치
- 클러스터를 기능별로 나누는 작업을 계속 우선해서, 마이그레이션을 샤드 하나에서 카나리 모드로 먼저 돌릴 수 있게 한다.
- 클러스터마다 여유 용량을 더 크게 잡도록 내부 절차를 고친다.
- 이 문제를 막는 방법을 더 알게 될 때까지 스키마 마이그레이션을 멈춘다.
- 이번 장애가 일어난 구체적인 조건을 계속 조사한다.
- 마이그레이션 도구를 시험하면서 이런 상황에서 도구를 고칠 점을 가려낸다.
교훈
–
출처
관련 사례
IL-0451Aurora MySQL 에서 인덱스를 INVISIBLE 로 바꿀 때마다 Reader 3대의 버퍼풀이 무효화돼 CPU 와 ReadIOPS 가 튀었다Daangn · 2026같은 원인 · 공통 스키마 마이그레이션, 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0281PostHog US 리전 Logs 제품의 ClickHouse 클러스터가 S3 에 둔 로그 데이터를 거의 다 지워 3일보다 오래된 로그가 사라졌다PostHog · 2026같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0150DynamoDB DNS 자동화의 경쟁 조건이 us-east-1 리전 엔드포인트의 DNS 레코드를 비워 DynamoDB 와 EC2 인스턴스 시작이 실패했고, 그 여파로 EKS, ECS, Fargate 의 컨테이너 시작과 클러스터 스케일링이 14시간 넘게 막혔다Amazon Web Services · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0527OpenStreetMap.org 의 복제 diff 생성이 invalid memory alloc request size 오류로 16시간 멈춤OpenStreetMap Foundation · 2025같은 원인 · 공통 데이터베이스
IL-0329Postgres 17 업그레이드 뒤 다시 켠 PGAudit 가 마이그레이션 중 락을 쥔 채 멈춰, 서비스 전반이 느려지고 데이터베이스가 2분 동안 내려갔다incident.io · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0024무거운 API 요청이 MongoDB 에 과부하를 걸고 취소되지 않은 요청이 쌓여 Hugging Face Hub 가 사흘 동안 세 번 멈췄다Hugging Face · 2024같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0196Redis Operator 로 레플리카를 늘리면서 메모리 한도를 낮추자 데이터를 가진 유일한 Redis 파드가 재시작됐고, Sentinel 이 빈 레플리카를 마스터로 올려 데이터가 모두 지워졌다.Palark · 2020같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0388Redis 고가용 클러스터의 primary 노드가 내려간 뒤 Discord API 가 느려지고 길드 일부가 오프라인으로 보이며 접속이 실패했다Discord · 2017같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0385
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0385/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.