Cases1 case
1 to 1 of 1
IL-0289A failing SSD made updown.io's primary MongoDB about 200 times slower, no failover happened and the site went downupdown.io2019- Symptoms
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.
- Trigger
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.
- Root cause
- Component
- Contributing factor
- –
- Detection
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.
- Remediation
- Forced the primary to step down after making sure the secondary was ready to take over
- Took the failing SSD out of the RAID array, which restored the old primary's performance
- Asked the hosting provider to replace the SSD
- Replaced the less powerful secondary with a more powerful server
- Action items
- Write a script that detects when MongoDB is up but not responsive and forces a step-down automatically
- Shut down and delete the old secondary once nothing is left to investigate on it
- Make sure the new secondary can run as primary for several days
- Test the automatic step-down script once the primary server is healthy again
- Provide a proper status page for updown.io
- Replace the custom script with MongoDB's Storage Node Watchdog
Check your cluster for this
This case involves Database and Database failover manager. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.
By root cause1
Hardware failure1 case
- Component
- Contributing factor
- –
- Organisation