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

Cases17 cases

17 to 17 of 17

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

    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
    Component
    Contributing factor
    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.

Check your cluster for this

These 17 cases involve Database replication 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.

By root cause9

Capacity exhaustion4 cases

  1. IL-0379 InfluxDB Cloud queries in Azure West Europe slowed and timed out as storage pods fell behind and kept restarting
  2. IL-0288 ZooKeeperWait rose to thousands of seconds on three redundant ClickHouse instances, degrading a CDN77 data pipeline
    CDN772026
  3. IL-0305 Replicas of one Intercom Vitess shard hit 100% CPU and fell up to 2.2 hours behind, serving stale inbox data
  4. IL-0443 A Repro Aurora MySQL reader restarted unexpectedly and writer insert latency rose about sevenfold for a day or more
    Repro2019

Breaking change in an upgrade1 case

Contributing factor
Organisation
  1. IL-0569 After an MHA master failover, one of three MySQL replicas failed with a malformed binlog error and could not catch up
    DeNA2026

Cloud provider outage1 case

Contributing factor
–
Organisation
  1. IL-0368 PlanetScale's control plane went down and some database branches failed queries during the AWS us-east-1 outage

Software defect3 cases

  1. IL-0527 OpenStreetMap.org made no replication diffs for 16 hours as PostgreSQL logical decoding failed on a memory alloc error
  2. IL-0589 Every Kickstarter MySQL replica on Amazon RDS stopped replicating on a duplicate-key error in the backings table
  3. 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

Configuration change2 cases

  1. IL-0392 MariaDB replication of section x1 between eqiad and codfw broke on a missing heartbeat row during a cookbook run
  2. IL-0331 An RDS MySQL Multi-AZ failover lost 5 seconds of committed data and broke replication on all five read replicas

Dependency failure1 case

Organisation
  1. IL-0255 Basecamp's two redundant links between data centers dropped together and a Redis replica resync loop stalled chat

Hardware failure1 case

  1. IL-0323 A RAID battery backup unit failure crashed db1075, the MariaDB primary of section s3, and every s3 wiki went read-only

DNS or network fault1 case

Organisation
  1. IL-0210 GitHub's MySQL clusters failed over to the US West Coast and the site served slow, stale, inconsistent data for 24 hours
    GitHub2018

Operator error3 cases

  1. IL-0431 During Mackerel's move to AWS, PostgreSQL failed over to a replica that had stopped replicating, losing an hour of data
    Hatena2017
  2. IL-0218 GitLab.com's primary PostgreSQL data was wiped by mistake and, with no working backup, the site was down about 18 hours
    GitLab2017
  3. IL-0319 Dropping databases on the MySQL replica mysql2 also dropped them on mysql1, as the pair actually ran master-master