Incident Library
Applied filters Root causeSoftware defectComponentDatabase replicationFactorHarmful manual actionClear 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

    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

This case involves Database and Database replication. 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