Incident Library
Applied filters ComponentDatabase failover managerOrganisationupdown.ioClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. 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