Cases1 case

1 to 1 of 1

1. IL-0311 BattleMetrics' primary PostgreSQL went read-only at transaction ID wraparound, breaking the website and RCON updates

   BattleMetrics2022

   Symptoms

   At 03:23 UTC on 27 March 2022, BattleMetrics' primary PostgreSQL database, which holds all account, server and player information, went into read-only mode. Users first saw the website fail to load, and soon RCON updates and queries began to fail as well.

   Writes rejectedService outage

   Trigger

   A corruption of the index on the player identifiers table, which BattleMetrics' logs place at about 26 February 2022, made every vacuum job fail, so transaction IDs kept climbing until Postgres stopped accepting writes on 27 March.

   Root cause

   Data loss or corruption

   Component

   DatabasePostgreSQL vacuumDatabase replicationDatabase backups and snapshots

   Contributing factor

   Monitoring blind spotOverlapping failuresNo headroom

   Detection

   Users failed to load the website and reported it as their API keys expired, then RCON updates and queries began to fail, and the team found that the main database no longer accepted writes.

   Remediation

   • Shut the database down and dropped the corrupted player identifiers index in single-user mode
   • Ran the vacuum again, which succeeded and let the database accept writes
   • Rebuilt the player identifier index, which took about two hours
   • Shut down the query workers and gave RCON updates priority
   • Pointed services at the new Postgres primary
   • Bootstrapped new replicas one after another to take load off the primary
   • Restarted queries with throttling, prioritised by server population and rank, after RCON updates had caught up

   Action items

   • Monitor errors in the Postgres logs
   • Monitor and alert on transaction IDs
   • Set up a logical replica in addition to physical replication
   • Build a faster network to speed up recovery from failure

   Lessons

   BattleMetrics names skipping health checks on transaction ID size as its critical mistake: the index corruption silently broke vacuum for a month, and without monitoring of transaction IDs nobody saw the database approach wraparound. Because the corruption had been replicated to the replicas, failing over did not help, and the backup servers and downloadable backups carried the same corruption. The team also found that, contrary to the error message, a full vacuum on a server in wraparound protection does not need single-user mode, and chose to run a slow, delayed service over no service while replicas were rebuilt.

   View case

By root cause1