{"id":"IL-0289","org":"updown.io","date":"2019-04-03","docs":["https://jira.mongodb.org/browse/SERVER-29980"],"title":{"en":"A failing SSD made updown.io's primary MongoDB about 200 times slower, no failover happened and the site went down","ko":"updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답해 사이트와 모니터링 데몬이 거의 멈췄는데 자동 페일오버가 일어나지 않았다"},"domain":["database"],"impact":{"scope":"The updown.io website and monitoring daemons were almost fully down from 2:30 am to 8:56 am CEST, then ran with lower performance on the less powerful secondary","users":"unknown","region":"unknown"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://updown.io/blog/mongodb-ssd-incident-postmortem","kind":"blog","archived":"https://web.archive.org/web/20260720184956/https://updown.io/blog/mongodb-ssd-incident-postmortem"}],"summary":{"en":"updown.io runs MongoDB with a primary server, whose data sits on 3 SSDs in RAID5, and a less powerful secondary. When one SSD started to fail at 2:30 am CEST on 3 April 2019, the primary slowed to about 200 times its normal query time but kept answering the heartbeat, so MongoDB never failed over. The founder was asleep and noticed the problem at 8:45 am, checked that the secondary was ready and forced the primary to step down; the website and daemons recovered at 8:56 am, more slowly than usual on the weaker secondary. The founder then found the failing SSD, took it out of the array, which restored the old primary's performance, and asked the hosting provider to replace it. On the following two nights the weaker secondary, now primary, failed again because a daily clamscan antivirus run took memory from MongoDB: on 4 April the kernel's OOM killer killed MongoDB, and on 5 April the server slowed and the DNS automatic failover switched to the disabled primary. On 6 April at 12:48 pm the secondary was replaced with a more powerful server and response times returned to normal. When the provider replaced the SSD, a second SSD had died in the same way, apparently both far past their rated endurance; it was replaced on 16 April and the original server became primary again on 22 April. The script written afterwards to force a step-down when MongoDB is up but unresponsive cut the downtime to under 10 minutes when the third SSD died on 6 November 2019, and in 2020 MongoDB's Storage Node Watchdog, then opened to the community edition, replaced the script.","ko":"2019년 4월 3일 2:30 am CEST 에 updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답하기 시작해 웹사이트와 모니터링 데몬이 거의 다 멈췄다. 하트비트 검사는 계속 빠르게 답했기 때문에 MongoDB 의 자동 페일오버가 문제를 보지 못했고, 대기 중인 보조 서버가 주 서버로 선출되지 않았다. 운영자는 자고 있다가 8:45 에야 문제를 알았다. 운영자는 주 서버의 I/O 문제를 확인하고 보조 서버가 넘겨받을 준비가 됐는지 본 뒤 주 서버를 강제로 step down 시켰다. 8:56 에 플랫폼 전체가 돌아왔지만, 보조 서버의 사양이 낮아 성능은 떨어졌다. 원인은 RAID5 로 묶은 SSD 3개 가운데 하나였고, 이 디스크를 어레이에서 빼자 서버 성능이 원래대로 돌아왔다.\n\n그 뒤 며칠 동안 보조 서버가 주 서버 역할을 하면서 장애가 더 이어졌다. 4월 4일 3:56 am 에는 매일 도는 clamscan 백신 검사와 MongoDB 가 메모리를 다 써, 커널의 OOM Killer 가 MongoDB 를 죽였다. 운영자는 8:40 에 MongoDB 를 재시작하고 스왑 공간을 더했다. 4월 5일 3:56 부터 5:30 까지는 clamscan 이 다시 MongoDB 를 느리게 했다. DNS 자동 페일오버가 이 서버를 죽은 것으로 보고 트래픽을 꺼져 있던 주 서버로 돌려, 일부 사용자가 연결 오류를 겪었을 수 있었다. 운영자는 clamscan 과 DNS 페일오버를 껐고, 4월 6일 12:48 pm 에 보조 서버를 더 높은 사양의 서버로 바꿔 응답 시간을 되돌렸다.\n\n호스팅 업체가 4월 6일 밤 SSD 를 바꿨지만, 같은 날 밤 다른 SSD 하나가 같은 방식으로 죽어 운영자는 다시 교체를 요청했다. 두 디스크 모두 정격 내구 수명을 한참 넘긴 것으로 보였다. 두 번째 SSD 는 4월 16일에 교체됐고, 관찰 기간을 거쳐 4월 22일에 원래 서버를 다시 주 서버로 돌렸다. 운영자는 MongoDB 가 살아 있지만 응답하지 않는 상황을 찾아 자동으로 step down 시키는 스크립트를 만들었다. 2019년 11월 6일 세 번째 SSD 가 죽었을 때 이 스크립트 덕분에 중단 시간이 10분 아래로 줄었다."},"trigger":{"en":"One of the three SSDs in the primary MongoDB server's RAID5 array began to fail, slowing the server's IO without taking the server down.","ko":"주 MongoDB 서버의 RAID5 를 이루는 SSD 3개 가운데 하나가 고장 나기 시작해 디스크 I/O 가 크게 느려졌다."},"severity":"unknown","symptoms":["high-latency","service-unavailable","failover-failed"],"timeline":{"detected_after":"6h 15m","resolved_after":"6h 26m"},"date_kind":"incident","detection":{"en":"The founder, who was asleep when the slowdown began, noticed the problem at 8:45 am CEST and found the IO performance issue by inspecting the primary server.","ko":"MongoDB 의 자동 페일오버는 하트비트가 계속 빠르게 응답해 문제를 감지하지 못했다. 운영자는 자고 있다가 8:45 am CEST 에야 문제를 알아챘다."},"components":["database","failover-manager"],"root_cause":"hardware-failure","remediation":[{"text":{"en":"Forced the primary to step down after making sure the secondary was ready to take over","ko":"보조 서버가 넘겨받을 준비가 됐는지 확인한 뒤 주 서버를 강제로 step down 시켰다. 8:56 am CEST 에 웹과 데몬 전체가 돌아왔지만, 보조 서버의 사양이 낮아 성능은 떨어졌다."}},{"text":{"en":"Took the failing SSD out of the RAID array, which restored the old primary's performance","ko":"I/O 문제를 일으킨 SSD 를 RAID 어레이에서 빼자 서버가 원래 성능으로 돌아왔다."}},{"text":{"en":"Asked the hosting provider to replace the SSD","ko":"호스팅 업체에 SSD 교체 일정을 잡는 티켓을 열었다."}},{"text":{"en":"Replaced the less powerful secondary with a more powerful server","ko":"4월 6일 12:48 pm 에 보조 서버를 더 높은 사양의 서버로 바꿨고, 그 뒤 응답 시간이 정상으로 돌아왔다."}}],"action_items":[{"text":{"en":"Write a script that detects when MongoDB is up but not responsive and forces a step-down automatically","ko":"MongoDB 팀이 이 문제를 곧 고칠 것 같지 않아, MongoDB 가 살아 있지만 응답하지 않는 상황을 찾아 자동으로 step down 시키는 스크립트를 만든다."}},{"text":{"en":"Shut down and delete the old secondary once nothing is left to investigate on it","ko":"더 조사할 것이 없다고 확인되면 옛 보조 서버를 내리고 지운다."}},{"text":{"en":"Make sure the new secondary can run as primary for several days","ko":"새 보조 서버가 며칠 동안 주 서버 역할을 버틸 수 있는지, clamscan 이 도는 밤까지 포함해 확인한다."}},{"text":{"en":"Test the automatic step-down script once the primary server is healthy again","ko":"주 서버가 정상으로 돌아오면 자동 step down 스크립트를 시험한다."}},{"text":{"en":"Provide a proper status page for updown.io","ko":"updown.io 의 제대로 된 상태 페이지를 만든다."}},{"text":{"en":"Replace the custom script with MongoDB's Storage Node Watchdog","ko":"MongoDB 가 Storage Node Watchdog 을 커뮤니티 에디션에도 제공하자 이를 켜서 한동안 시험했다. 잘 동작해 직접 만든 스크립트는 지웠다."}}],"contributing":[],"recurrence_of":null,"symptoms_text":{"en":"At 2:30 am CEST on 3 April 2019, the primary MongoDB server of updown.io started answering queries about 200 times slower than usual, and the website and the monitoring daemons went almost completely down.\n\nMongoDB's automatic failover did not react, because the replica set heartbeat check still answered quickly; a secondary server was ready to take over but was never elected primary (MongoDB ticket SERVER-29980). On the primary, atop showed the IO usage (\"busy\") and average latency (\"avgio\") of its three disks, and the founder found an IO performance problem.","ko":"2019년 4월 3일 2:30 am CEST 부터 updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답했다. 웹사이트와 모니터링 데몬이 거의 전부 멈췄다.\n\nMongoDB 의 하트비트 검사는 계속 빠르게 응답했다. 그래서 대기 중인 보조 서버가 있었는데도 자동 페일오버가 문제를 감지하지 못했고 보조 서버가 주 서버로 선출되지 않았다.\n\n주 서버를 살펴보니 디스크 I/O 성능에 문제가 있었다. atop 출력에서 디스크 3개의 사용률을 뜻하는 busy 와 평균 지연을 뜻하는 avgio 를 보니, RAID5 로 묶은 SSD 3개 가운데 하나가 원인이었다."},"updated_at":"2026-11-14T12:33:54.389173Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0289","org_slug":"updown-io"}