Incident Library
Applied filters ComponentDatabase failover managerSymptomService outageClear 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

Cases6 cases

5 to 6 of 6

  1. IL-0278 A weekly update put a Redis Cloud management process into an infinite loop, and most nodes of a GCP cluster failed
    Redis2016
    Symptoms

    On 8 February 2016 at 17:45 UTC, four nodes of the Redis Cloud cluster us-central1-1-1.gce.garantiadata.com on Google Cloud Platform stopped responding, four minutes after a first node had failed. The databases whose endpoints end in us-central1-1-1.gce.garantiadata.com went down.

    Service outageFailover failure
    Trigger

    The weekly upgrade of Redis Cloud's non-critical cluster components reached its first Google Cloud Platform cluster, us-central1-1-1.gce.garantiadata.com, at 17:30 UTC.

    Root cause
    Faulty deployment
    Component
    In-memory cacheDatabase failover managerAuthoritative DNS servers and records
    Contributing factor
    Overlapping failures
    Remediation
    • Shut down and terminated all nodes of the cluster
    • Deleted all of the cluster's endpoints from its DNS zone, removing by hand the entries left by throttled deletes
    • Provisioned new cluster nodes from scratch without the weekly update
    • Reconnected the original nodes' storage to the new nodes so persistence-enabled databases could be recovered
    • Bootstrapped and launched the databases, recovering the ones with persistence from storage
    Action items
    • Suspend all automatic weekly upgrades until a procedure that prevents this kind of outage is in place
    • Revalidate the QA processes for DevOps code deployments
    • Improve the tooling so it handles throttling of DNS requests
    View case
  2. IL-0303 GitHub's MySQL master failed over to a node with a cold buffer pool during a schema migration and GitHub.com went down
    GitHub2012
    Symptoms

    On Monday, September 10th, 2012, during a schema migration, the health checks on GitHub's MySQL master failed and Percona Replication Manager moved the 'active' role to another node of the new three-node cluster. That node's InnoDB buffer pool was cold and it performed poorly, its health checks failed in turn, and the role failed back to the original server. GitHub.com went down.

    Failover failureDatabase overloadHigh latencyReplication lagSplit brainService outage
    Trigger

    A schema migration on Monday, September 10th put more load on the master database than earlier migrations had, and Percona Replication Manager's health checks on the master failed.

    Root cause
    Software defect
    Component
    DatabaseDatabase failover managerDatabase replication
    Contributing factor
    Automation amplificationDependence on a warm cacheHarmful manual actionOverlapping failures
    Detection

    On the morning of September 11th, a developer told the operations team that the 'standby' node was returning incorrect query results.

    Remediation
    • Enabled Pacemaker's maintenance-mode so no health checks or automatic failovers ran, and let the buffer pool warm
    • Powered off the out-of-date node 'c' to end the partition
    • Stopped Pacemaker and Heartbeat on nodes 'a' and 'b' and started them on node 'a' only
    • Started MySQL on node 'a' in the active role
    • Removed the events leaked to wrong dashboards and audited the wrongly routed repositories
    • Contacted the owners of the exposed private repositories
    Action items
    • Change the Pacemaker configuration so the active database role fails over only when an operations engineer starts it
    • Find a way to warm the InnoDB buffer pool of slave databases so failovers do not hurt performance
    • Audit the Pacemaker and Heartbeat stack, focusing on the code path behind the segfault
    • Run hardware tests on the server where the segfault happened
    Lessons

    GitHub concluded that automated failover is not the right strategy for its primary production database: for every failover in this incident, any member of the operations team would have said it should not happen. Failovers that must happen, in an emergency or during maintenance, should not hurt performance.

    View case
Check your cluster for this

These 6 cases involve Database failover manager and Database. 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.

Open kubegap

By root cause4

Configuration change1 case

Component
Cloud block storageDatabaseDatabase failover manager
Contributing factor
Excessive blast radiusMonitoring blind spotNo staged rolloutUnsafe failure behaviour
Organisation
Microsoft Azure
  1. IL-0367 Azure Storage in Central US rejected VM disk I/O, taking down VMs and the SQL Database and Cosmos DB services on them
    Microsoft Azure2024

Software defect2 cases

Component
Database failover manager2In-memory cache1Database1Database replication1
Contributing factor
Unverified assumption1Automation amplification1Harmful manual action1Overlapping failures1Unrepresentative staging1Dependence on a warm cache1
Organisation
GitHub1Pusher1
  1. IL-0295 Pusher's Channels publish API on the mt1 cluster was largely unavailable for 11 minutes while a Redis master failed over
    Pusher2022
  2. IL-0303 GitHub's MySQL master failed over to a node with a cold buffer pool during a schema migration and GitHub.com went down
    GitHub2012

Hardware failure2 cases

Component
Database2Database failover manager2
Contributing factor
Unverified assumption1Overlapping failures1
Organisation
GoCardless1updown.io1
  1. IL-0289 A failing SSD made updown.io's primary MongoDB about 200 times slower, no failover happened and the site went down
    updown.io2019
  2. IL-0219 GoCardless's API and Dashboard failed every request for 1 hour 50 minutes when Pacemaker did not promote a replica
    GoCardless2017

Faulty deployment1 case

Component
In-memory cacheAuthoritative DNS servers and recordsDatabase failover manager
Contributing factor
Overlapping failures
Organisation
Redis
  1. IL-0278 A weekly update put a Redis Cloud management process into an infinite loop, and most nodes of a GCP cluster failed
    Redis2016