Incident Library
Applied filters ComponentDatabase replicationSymptomData lossClear 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

Cases8 cases

8 to 8 of 8

  1. Symptoms

    At 2:39 AM PDT (9:39 UTC) on 18 July 2013, services that relied on the redis-master of Twilio's billing system began to fail because the load on its host had become extreme. At 2:42 AM PDT monitoring alerted the on-call engineers to a failure in the Redis cluster.

    Trigger

    At 1:35 AM PDT on 18 July a loss of network connectivity disconnected all billing redis-slaves from the redis-master at once, and all of them requested a full synchronization at the same time. On-call engineers then restarted the overloaded redis-master.

    Root cause
    Component
    Contributing factor
    Detection

    At 2:42 AM PDT monitoring alerted the on-call engineers to a failure in the Redis cluster. At 3:28 AM PDT the billing system monitoring reported the anomalous charges, and at 12:36 PM PDT monitoring detected the recurrence.

    Remediation
    • Restarted the redis-master to relieve the high load, which loaded a wrong configuration
    • Took the billing system offline to stop further credit card charges
    • Restored service to all suspended accounts
    • Restored the lost account balances from the independent double-bookkeeping record in the relational datastore
    • Took billing offline again after the recurrence and reactivated the newly suspended accounts
    • Refunded all erroneous credit card charges
    • Gave all affected accounts a credit of 10% of their last 30 days of spend
    • Replaced the original Redis cluster and corrected the redis-master configuration
    • Activated the billing system progressively for groups of customer accounts
    Action items
    • Disable Redis restarts on the redis-master and recover the master by pivoting a slave instead
    • Add fail-safes so the billing system neither suspends accounts nor charges cards when balances are missing or cannot be written
    • Validate the billing system against the double-bookkeeping databases in real time
    Lessons

    Losing the in-flight balances and the ability to write balances at the same time exposed a flaw in the auto-recharge system: it failed in a dangerous way, charging cards and suspending accounts instead of stopping.

Check your cluster for this

These 8 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 cause4

Certificate or credential expiry1 case

Organisation
  1. IL-0490 Records were missing from LootLocker's new MySQL database after a migration cutover and the service degraded for 3 hours

Software defect1 case

Organisation
  1. IL-0281 PostHog's Logs ClickHouse cluster silently deleted almost all its S3 data, losing US logs older than 3 days

Operator error4 cases

  1. IL-0242 Both PostgreSQL servers behind matrix.org were lost during a disk expansion, and the homeserver was down for 24 hours
  2. IL-0431 During Mackerel's move to AWS, PostgreSQL failed over to a replica that had stopped replicating, losing an hour of data
    Hatena2017
  3. 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
  4. IL-0319 Dropping databases on the MySQL replica mysql2 also dropped them on mysql1, as the pair actually ran master-master

Configuration change2 cases

Organisation
  1. IL-0331 An RDS MySQL Multi-AZ failover lost 5 seconds of committed data and broke replication on all five read replicas
  2. IL-0215 Twilio's billing Redis master lost all balances and went read-only, and auto-recharge charged customer cards repeatedly
    Twilio2013