Incident Library

IL-0323 Wikimedia Foundation · 2019-09-22database

s3 주 데이터베이스 마스터 db1075 가 완전히 멈춰 s3 위키 전체가 읽기 전용이 됐다

2019-09-22 18:40 UTC 에 Wikimedia 의 s3 주 데이터베이스 마스터 db1075 가 RAID 백업 배터리인 BBU 를 잃으면서 호스트 전체가 멈췄다. 마스터에 쓸 수 없게 되자 s3 의 모든 위키가 읽기 전용이 됐다. 레플리카는 모두 살아 있어 읽기는 영향을 받지 않았다. Icinga 가 18:42 에 HOST DOWN 을 IRC 로 알렸지만 이 알림은 호출을 보내지 않았고, 첫 SMS 호출은 18:56 에 나갔다. 자원봉사자와 직원은 알림보다 먼저 문제를 알아챘다.

19:02 에 BBU 문제이고 호스트가 응답하지 않는 것을 확인한 뒤 idrac 으로 호스트를 재부팅했다. 19:03 에 MySQL 이 InnoDB 복구를 시작해 19:06 에 마쳤고, 19:07 에 db1075 의 read_only=ON 을 직접 풀었다. 그런데 19:04 의 수동 puppet 실행이 MySQL 이 다 뜨기 전에 pt-heartbeat 를 돌리려다 실패했고, 아무도 이를 알아채지 못했다. 그래서 모든 것이 올라왔는데도 복제 지연이 보고됐다. 19:16 에 puppet 을 다시 돌려 pt-heartbeat 가 시작되면서 장애가 끝났다. 이 경합 때문에 장애가 8분 더 길어졌다.

db1075 는 같은 배치로 들어온 서버 6대 가운데 하나였고, 그중 3대가 이미 BBU 문제를 겪었다. BBU 고장이 호스트 전체를 멈추게 하는 일은 HP 호스트에서 전에도 있었다. 호스트가 깨끗하게 돌아왔기 때문에 새 레플리카를 마스터로 올리는 수동 장애 조치는 하지 않아도 됐다. 복구에는 DBA 1명, SRE 2명, WMCS 1명, 개발자 1명, 자원봉사자 1명이 참여했다.

심각도
–
영향 범위
All s3 wikis were read-only for 36 minutes; reads were not affected
영향 사용자
–
지역
eqiad
감지까지
2m
복구까지
36m

증상

s3 의 주 데이터베이스 마스터 db1075 가 응답하지 않아 s3 의 모든 위키가 쓰기를 받지 못하고 읽기 전용이 됐다. 레플리카는 모두 살아 있어 읽기는 정상이었다. Icinga 가 IRC 에 HOST DOWN 을 알렸고 사용자들이 #wikimedia-operations 에 문제를 알렸다.

18:40:38 UTC 에 db1115 의 mysqld 로그에 OpenTable: (2003) Can't connect to MySQL server on 'db1075.eqiad.wmnet' (110 "Connection timed out") 가 찍혔다. 18:42:45 에 icinga-wm 이 PROBLEM - Host db1075 is DOWN: PING CRITICAL - Packet loss = 100% 를 알렸다.

18:47 에 한 사용자가 otrs-wiki 에서 높은 복제 지연으로 데이터베이스가 잠겼다는 경고가 뜨고 평소보다 느리다고 알렸다. 18:48 부터 db2105, dbstore1004, db1095 의 s3 레플리카에서 MariaDB Slave IO 알림이 이어졌다. 메시지는 CRITICAL slave_io_state Slave_IO_Running: No, Errno: 2003, Errmsg: error reconnecting to master [email protected]:3306 - retry-time: 60 maximum-retries: 86400 message: Cant connect to MySQL server on db1075.eqiad.wmnet (110 Connection timed out) 였다.

HOST DOWN 은 IRC 알림만 보내고 온콜 호출은 보내지 않았기 때문에 첫 SMS 호출은 18:56 에야 나갔다. 자원봉사자와 직원은 알림보다 먼저 장애를 알아챘다.

19:07 에 db1075 의 read_only=ON 을 직접 풀었는데도 복제 지연이 계속 보고됐다. 19:04 의 수동 puppet 실행이 MySQL 이 다 뜨기 전에 pt-heartbeat 를 띄우려다 실패했는데 아무도 알아채지 못했다. 19:16 에 puppet 을 다시 돌려 pt-heartbeat 가 시작되고서야 지연 보고가 멈췄다.

증상 쓰기 거부복제 지연지연 시간 증가

원인

원인 하드웨어 고장

구성 요소 데이터베이스데이터베이스 복제
기여 요인 온콜 호출 미전달수동 조치 악화
촉발
db1075 의 RAID 백업 배터리인 BBU 가 고장 나면서 호스트가 완전히 멈췄다.

감지

db1075 의 HOST DOWN 이 보고되면서 문제가 분명해졌다. 하지만 HOST DOWN 알림은 IRC 로만 가고 호출을 보내지 않았다. 알림은 IRC 와 호출로 보내졌고, 첫 SMS 호출은 18:56 UTC 에 나갔다. 사용자들도 #wikimedia-operations 에 문제를 알렸고, 자원봉사자와 직원은 알림보다 먼저 장애를 알아챘다.

조치

후속 조치

교훈

BBU 고장이 호스트 전체를 멈추게 해서는 안 됐지만 HP 호스트에서는 전에도 그런 일이 있었다. puppet 으로 띄우는 pt-heartbeat 와 아직 다 뜨지 않은 MySQL 사이의 경합으로 수동 puppet 실행이 실패했는데 아무도 알아채지 못했다. 그 때문에 모든 것이 올라온 뒤에도 복제 지연이 보고돼 장애가 8분 더 길어졌다. 알림은 잘 동작했고 idrac 으로 재부팅한 것도 통했다. 호스트가 깨끗하게 돌아오지 않았다면 새 레플리카를 마스터로 올리는 장애 조치를 손으로 해야 했다.

출처

참고 문서

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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