Incident Library
Applied filters Root causeFaulty deploymentOrganisationDevsistersClear 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

Cases2 cases

1 to 2 of 2

  1. IL-0567 Aurora MySQL behind Cookie Run: OvenBreak hit 100% CPU after a sales-ranking feature launch, and players could not play
    Devsisters2023
    Symptoms

    After further bug-fix deployments and reconnecting users on the launch day of the package sales ranking feature, a database alarm fired and the CPU of the Cookie Run: OvenBreak AWS Aurora MySQL database was at 100%. Database connections then failed, and players could not log in to or play the game.

    Database overloadService outage
    Trigger

    The package sales ranking feature was deployed, and further bug-fix deployments followed that reconnected users; each server update left more servers with empty caches that ran the ranking query against the database.

    Root cause
    Faulty deployment
    Component
    Database
    Contributing factor
    Inefficient queryDependence on a warm cacheUnrepresentative staging
    Detection

    A database alarm fired, and the CPU graph of the Aurora MySQL database showed 100%.

    Remediation
    • Put the game servers into maintenance
    • Added a switch for the package sales ranking feature and turned the feature off, which restored the service
    • Rewrote the ranking query to group products that share a sale start time and to drop the current-time condition
    • Moved the ranking query to a scheduler server that runs it periodically and stores one shared cached result
    • Turned the package sales ranking feature back on after both fixes
    Lessons

    A heavy query combined with per-server caches in a distributed server setup caused a problem nobody expected, so the points likely to cause trouble need to be found in advance. During an outage, restoring the service comes before finding the cause, and a switch that turns a feature off, built in ahead of time, is a safety device that helps run a stable service. The online ALTER itself went well with Percona Toolkit and was used again for later schema changes.

    View case
  2. IL-0566 Hot ranges after a Cookie Run: Kingdom guild update drove CockroachDB nodes to 100% CPU, forcing emergency maintenance
    Devsisters2021
    Symptoms

    About half an hour after the Cookie Run: Kingdom guild update maintenance ended at 11:00 on 6 March 2021, one CockroachDB node was using all 24 cores of its 24-core machine and server metrics began to show a significant number of errors. Soon two more nodes showed abnormal CPU use.

    Load imbalanceDatabase overloadHigh error rate
    Trigger

    During the guild update maintenance, new guild tables were added and pre-split across the cluster, and a new database node was added to replace one removed a few days earlier for a physical hardware issue. When the game reopened, all players at once wrote to existing tables whose primary-key prefixes were new or had changed in the update.

    Root cause
    Faulty deployment
    Component
    Database
    Contributing factor
    Unverified assumptionOverlapping failures
    Detection

    Monitoring after the maintenance showed one node's CPU at the ceiling together with errors in server metrics. Later a Slack alert reported a node failing its Host Status Check, and the abnormal-log channel reported filemap_fdatawait_range_keep_errors.

    Remediation
    • Blocked new logins without kicking players already in the game, using the maintenance switch as a makeshift access queue
    • Put the game into full emergency maintenance at 14:50 when several nodes failed health checks
    • Backed up the game data table by table after the full database backup stalled
    • Paused writing play records to reduce load on the database before reopening
    • Split the problem tables from about 18:30
    • Decommissioned the node that failed its Host Status Check
    • Reopened the game and used the login-block queue again when a node reached 100% CPU
    • Terminated the node that kept returning to 100% CPU
    Lessons

    In a single-server relational database a change to the primary-key prefix is usually harmless, but in CockroachDB's distributed design such a change on a production cluster needs great care. The team had studied this in CockroachDB documentation, but living through it taught far more than reading about it.

    View case
Check your cluster for this

These 2 cases involve 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 cause1

Faulty deployment2 cases

Component
Database2
Contributing factor
Unverified assumption1Inefficient query1Overlapping failures1Unrepresentative staging1Dependence on a warm cache1
Organisation
Devsisters2
  1. IL-0567 Aurora MySQL behind Cookie Run: OvenBreak hit 100% CPU after a sales-ranking feature launch, and players could not play
    Devsisters2023
  2. IL-0566 Hot ranges after a Cookie Run: Kingdom guild update drove CockroachDB nodes to 100% CPU, forcing emergency maintenance
    Devsisters2021