{"id":"IL-0323","org":"Wikimedia Foundation","date":"2019-09-22","docs":["https://raw.githubusercontent.com/wikimedia/operations-mediawiki-config/master/dblists/s3.dblist","https://phabricator.wikimedia.org/T231638","https://phabricator.wikimedia.org/T225391","https://phabricator.wikimedia.org/T233569","https://phabricator.wikimedia.org/T230783","https://phabricator.wikimedia.org/T196366","https://phabricator.wikimedia.org/T172497","https://phabricator.wikimedia.org/T233567","https://phabricator.wikimedia.org/T233623","https://phabricator.wikimedia.org/T233684","https://phabricator.wikimedia.org/T233774"],"title":{"en":"A RAID battery backup unit failure crashed db1075, the MariaDB primary of section s3, and every s3 wiki went read-only","ko":"s3 주 데이터베이스 마스터 db1075 가 완전히 멈춰 s3 위키 전체가 읽기 전용이 됐다"},"domain":["database"],"impact":{"scope":"All s3 wikis were read-only for 36 minutes; reads were not affected","users":"unknown","region":"eqiad"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A BBU failure should not crash a whole host, yet it had happened before on HP hosts. HOST DOWN on a primary database should page instead of only alerting on IRC. Starting pt-heartbeat through puppet races with MySQL startup, and the unnoticed failure kept lag reported and made the outage 8 minutes longer.","ko":"BBU 고장이 호스트 전체를 멈추게 해서는 안 됐지만 HP 호스트에서는 전에도 그런 일이 있었다. puppet 으로 띄우는 pt-heartbeat 와 아직 다 뜨지 않은 MySQL 사이의 경합으로 수동 puppet 실행이 실패했는데 아무도 알아채지 못했다. 그 때문에 모든 것이 올라온 뒤에도 복제 지연이 보고돼 장애가 8분 더 길어졌다. 알림은 잘 동작했고 idrac 으로 재부팅한 것도 통했다. 호스트가 깨끗하게 돌아오지 않았다면 새 레플리카를 마스터로 올리는 장애 조치를 손으로 해야 했다."},"related":[],"sources":[{"url":"https://wikitech.wikimedia.org/wiki/Incidents/2019-09-23_s3_primary_db_master_crash","kind":"runbook","archived":"https://web.archive.org/web/20260121222829/https://wikitech.wikimedia.org/wiki/Incidents/2019-09-23_s3_primary_db_master_crash"}],"summary":{"en":"db1075, the primary database of section s3 in eqiad, lost its RAID battery backup unit, and the failure crashed the whole host. With the primary unavailable, no writes could happen and every s3 wiki went read-only, while reads continued from the replicas. The host was power-cycled from the iDRAC, MySQL recovered InnoDB cleanly, and read_only was removed by hand. A race between pt-heartbeat, started by puppet, and MySQL not yet being fully up made the first manual puppet run fail unnoticed, so replication lag kept being reported and the outage lasted 8 minutes longer, until a second puppet run started pt-heartbeat at 19:16. Had the host not come back, the team would have had to fail over manually and promote a replica to primary.\n\nHP hosts at Wikimedia had crashed on BBU failures before (T231638, T225391), and db1075 belongs to a batch of 6 servers, 3 of which had already had BBU problems (T233569). Replacing db1075 as primary with a host from outside that batch was the next step (T230783). The responders were 1 DBA, 2 SREs, 1 WMCS, 1 Dev and 1 Volunteer.","ko":"2019-09-22 18:40 UTC 에 Wikimedia 의 s3 주 데이터베이스 마스터 db1075 가 RAID 백업 배터리인 BBU 를 잃으면서 호스트 전체가 멈췄다. 마스터에 쓸 수 없게 되자 s3 의 모든 위키가 읽기 전용이 됐다. 레플리카는 모두 살아 있어 읽기는 영향을 받지 않았다. Icinga 가 18:42 에 HOST DOWN 을 IRC 로 알렸지만 이 알림은 호출을 보내지 않았고, 첫 SMS 호출은 18:56 에 나갔다. 자원봉사자와 직원은 알림보다 먼저 문제를 알아챘다.\n\n19: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분 더 길어졌다.\n\ndb1075 는 같은 배치로 들어온 서버 6대 가운데 하나였고, 그중 3대가 이미 BBU 문제를 겪었다. BBU 고장이 호스트 전체를 멈추게 하는 일은 HP 호스트에서 전에도 있었다. 호스트가 깨끗하게 돌아왔기 때문에 새 레플리카를 마스터로 올리는 수동 장애 조치는 하지 않아도 됐다. 복구에는 DBA 1명, SRE 2명, WMCS 1명, 개발자 1명, 자원봉사자 1명이 참여했다."},"trigger":{"en":"The RAID battery backup unit (BBU) of db1075, the s3 primary database host, failed and the whole host crashed.","ko":"db1075 의 RAID 백업 배터리인 BBU 가 고장 나면서 호스트가 완전히 멈췄다."},"severity":"unknown","symptoms":["writes-rejected","replication-lag","high-latency"],"timeline":{"detected_after":"2m","resolved_after":"36m"},"date_kind":"incident","detection":{"en":"Icinga reported db1075 HOST DOWN on IRC at 18:42:45, but that alert does not page; replica Slave IO alerts followed, users reported problems on #wikimedia-operations, and the first SMS page went out at 18:56. Volunteers and staff noticed the failure before the alerts did.","ko":"db1075 의 HOST DOWN 이 보고되면서 문제가 분명해졌다. 하지만 HOST DOWN 알림은 IRC 로만 가고 호출을 보내지 않았다. 알림은 IRC 와 호출로 보내졌고, 첫 SMS 호출은 18:56 UTC 에 나갔다. 사용자들도 #wikimedia-operations 에 문제를 알렸고, 자원봉사자와 직원은 알림보다 먼저 장애를 알아챘다."},"components":["database","database-replication"],"root_cause":"hardware-failure","remediation":[{"text":{"en":"Power-cycled db1075 from the iDRAC after finding the BBU problem","ko":"BBU 문제이고 호스트가 응답하지 않는 것을 확인한 뒤 19:02 UTC 에 idrac 으로 호스트를 재부팅했다."}},{"text":{"en":"Let MySQL finish InnoDB recovery on db1075","ko":"MySQL 이 19:03 에 InnoDB 복구를 시작해 19:06 에 마쳤다."}},{"text":{"en":"Removed read_only=ON from db1075 by hand","ko":"19:07 에 db1075 의 read_only=ON 을 직접 풀었다."}},{"text":{"en":"Ran puppet by hand a second time so pt-heartbeat started","ko":"19:16 에 puppet 을 다시 직접 돌려 성공했고, pt-heartbeat 가 시작되면서 장애가 끝났다."}}],"action_items":[{"text":{"en":"Implement or refactor a script that moves replicas when the primary is unavailable","ko":"마스터를 쓸 수 없을 때 레플리카를 옮기는 스크립트를 만들거나 고친다. 이번에는 필요하지 않았지만 앞으로의 장애에서는 필요할 수 있다."}},{"text":{"en":"Fix the MediaWiki heartbeat model so pt-heartbeat does not use a super-user, avoids a single point of failure and follows the real primary without depending on puppet","ko":"MediaWiki 의 heartbeat 방식을 고친다. pt-heartbeat 가 슈퍼유저를 쓰지 않게 하고, 단일 장애점을 없애고, puppet 없이 실제 마스터로 자동 전환되게 한다."}},{"text":{"en":"Decide what to do with the batch of hosts that already had BBU issues","ko":"이미 BBU 문제를 겪은 같은 배치의 호스트들을 어떻게 할지 정한다."}},{"text":{"en":"Buy a new BBU for db1075","ko":"db1075 에 쓸 새 BBU 를 산다."}},{"text":{"en":"Remove db1075 from the primary role","ko":"db1075 를 마스터에서 뺀다."}},{"text":{"en":"Address MediaWiki spam while the database is read-only or the primary is unavailable","ko":"읽기 전용이거나 마스터를 쓸 수 없는 동안 MediaWiki 가 쏟아내는 스팸을 해결한다."}},{"text":{"en":"Make primary database hosts page on HOST DOWN","ko":"주 데이터베이스 마스터가 HOST DOWN 일 때 호출이 가게 한다."}},{"text":{"en":"Track hardware errors better in Netbox","ko":"Netbox 에서 하드웨어 오류를 더 잘 추적한다."}}],"contributing":["paging-failed","manual-action-worsened"],"recurrence_of":null,"symptoms_text":{"en":"At 18:40 UTC db1075, the primary database of section s3, stopped answering, and all s3 wikis went read-only because no writes could reach it. Reads kept working from the replicas. At 18:42:45 Icinga reported \"PROBLEM - Host db1075 is DOWN: PING CRITICAL - Packet loss = 100%\".\n\nThe first error was logged by mysqld on db1115 at 18:40:38: \"OpenTable: (2003) Can't connect to MySQL server on 'db1075.eqiad.wmnet' (110 \"Connection timed out\")\". From 18:48 the s3 replicas db2105, dbstore1004 and db1095 alerted one after another with \"PROBLEM - MariaDB Slave IO: s3 on db2105 is CRITICAL: CRITICAL slave_io_state Slave_IO_Running: No, Errno: 2003, Errmsg: error reconnecting to master repl@db1075.eqiad.wmnet:3306\", followed by more alerts. At 18:47 a user on #wikimedia-operations reported a warning on otrs-wiki about a high replag database lock, and that the wiki was slower than usual.\n\nThe HOST DOWN alert went only to IRC and did not page; the first SMS page went out at 18:56. A responder was connecting at 18:55:51; the team saw that the host was unresponsive with a BBU problem, and rebooted it from the iDRAC at 19:02. MySQL started InnoDB recovery at 19:03 and finished at 19:06, and read_only=ON was removed by hand at 19:07. Lag was still being reported at 19:08 although everything was up: a manual puppet run at 19:04 had failed without anyone noticing, so pt-heartbeat had not started. A second manual puppet run at 19:16 succeeded, pt-heartbeat started and the outage ended, about 8 minutes later than it could have.","ko":"s3 의 주 데이터베이스 마스터 db1075 가 응답하지 않아 s3 의 모든 위키가 쓰기를 받지 못하고 읽기 전용이 됐다. 레플리카는 모두 살아 있어 읽기는 정상이었다. Icinga 가 IRC 에 HOST DOWN 을 알렸고 사용자들이 #wikimedia-operations 에 문제를 알렸다.\n\n18: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% 를 알렸다.\n\n18: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 repl@db1075.eqiad.wmnet:3306 - retry-time: 60 maximum-retries: 86400 message: Cant connect to MySQL server on db1075.eqiad.wmnet (110 Connection timed out) 였다.\n\nHOST DOWN 은 IRC 알림만 보내고 온콜 호출은 보내지 않았기 때문에 첫 SMS 호출은 18:56 에야 나갔다. 자원봉사자와 직원은 알림보다 먼저 장애를 알아챘다.\n\n19:07 에 db1075 의 read_only=ON 을 직접 풀었는데도 복제 지연이 계속 보고됐다. 19:04 의 수동 puppet 실행이 MySQL 이 다 뜨기 전에 pt-heartbeat 를 띄우려다 실패했는데 아무도 알아채지 못했다. 19:16 에 puppet 을 다시 돌려 pt-heartbeat 가 시작되고서야 지연 보고가 멈췄다."},"updated_at":"2026-11-14T12:33:57.625371Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0323","org_slug":"wikimedia-foundation"}