Cases3 cases

1 to 3 of 3

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

   Symptoms

   From around 19:00 UTC on 31 January 2017, load on GitLab.com's PostgreSQL database rose, which GitLab suspected was spam, and many users could not post comments on issues and merge requests. Around 23:00 UTC the replication of the PostgreSQL secondary fell behind and then failed, because WAL segments it still needed had already been removed from the primary.

   Database overloadReplication lagData lossService outage

   Trigger

   While trying to restore replication to the secondary, an engineer ran the removal of the PostgreSQL data directory on the primary, db1.cluster.gitlab.com, believing it was the secondary.

   Root cause

   Operator error

   Component

   DatabaseDatabase replicationDatabase backups and snapshotsCloud block storage

   Contributing factor

   Untested backupSingle point of failureNo runbookPages not deliveredUnverified assumptionUnreviewed defaults

   Detection

   The engineer who ran the deletion on the primary noticed the mistake and stopped it a second or two later.

   Remediation

   • Raised max_wal_senders from 3 to 32 and lowered max_connections from 8000 to 2000 so PostgreSQL would restart
   • Stopped the deletion on the primary a second or two after noticing it
   • Restored the database from the LVM snapshot taken about 6 hours before the outage by copying the PostgreSQL data directory from staging
   • Restored the webhooks from a separate database built from the snapshot and imported them as a SQL dump
   • Incremented all database sequences by 100,000 so IDs used before the outage could not be reused
   • Re-enabled GitLab.com gradually
   • Rebuilt projects created after 17:20 UTC in basic form from their Git repositories on the NFS cluster

   Action items

   • Change the shell prompt (PS1) on all hosts to show more clearly which host and environment is in use
   • Monitor backups with Prometheus
   • Set PostgreSQL's max_connections to a sane value
   • Investigate point-in-time recovery and continuous archiving for PostgreSQL
   • Take LVM snapshots of the production databases every hour
   • Take Azure disk snapshots of the production databases
   • Move staging to the ARM environment
   • Recover the production replicas
   • Test recovery of PostgreSQL database backups automatically
   • Improve the PostgreSQL replication documentation and runbooks
   • Investigate pgbarman for PostgreSQL backups
   • Investigate WAL-E for database backup and realtime replication
   • Build a streaming database restore
   • Assign an owner for data durability
   • Set up multiple secondaries and balance load among them with pgpool-II
   • Provide a tool for developers to run and revert Rails migrations on staging
   • Build owned recovery procedures for the rest of the GitLab.com infrastructure, not only the database
   • Publish a backup monitoring dashboard and add more backup data to it
   • Improve the abuse reporting and response system so removal for spam does not hard delete
   • Redact engineers' names in future public incident documents

   Lessons

   GitLab split the incident into two problems: GitLab.com went down because the primary's data directory was removed by mistake during a manual, undocumented replication rebuild, and recovery took over 18 hours because the backups had failed silently, disk snapshots were not enabled and the only copy sat on slow staging disks. The backup procedure was never tested because no one owned it. GitLab chose to focus on fast, regularly practised recovery and on making it obvious which host an engineer is on, rather than on blocking commands, since a safer rm only protects against one of many ways to lose data.

   View case
2. IL-0434 Rolling restarts of a 30-node Elasticsearch 0.19 cluster after a host failure left 12 shards unassigned

   CyberAgent2016

   Symptoms

   After an OpenStack host server went down and took one Elasticsearch node with it, the health check that the API servers run against Elasticsearch returned false, although the Head plugin showed the cluster status as green. The check stayed false after the node was brought back and the cluster was green again.

   High latencyData loss

   Trigger

   An OpenStack host server went down, and one node of the Elasticsearch cluster went down with it.

   Root cause

   Operator error

   Component

   Elasticsearch or OpenSearch

   Contributing factor

   Unverified assumptionAutomation amplification

   Detection

   The health check that the API servers run against Elasticsearch returned false while the Head plugin showed the cluster as green.

   Remediation

   • Migrated the Elasticsearch node's virtual server to another host after the failed host recovered
   • Started the node's Elasticsearch process and let it rejoin the cluster
   • Restarted all nodes in order from node 1, pausing at about the twentieth when the API slowed
   • Restarted all nodes again from node 1, which ended the API delays but left 12 shards unassigned
   • Tried to move an unassigned shard with the allocate command of _cluster/reroute, which failed
   • For index A, copied node 22's shard files to nodes 3 and 10 and set primary to true in node 22's state file
   • For index B, deleted the broken shard files on node 27, copied node 28's files to node 27 and other nodes and marked node 28 primary
   • For index C, copied shards 2 and 4 from nodes 27 and 25 to two other nodes each and marked the copies as not primary

   Action items

   • Upgrade Elasticsearch and stop running such an old version

   Lessons

   Automatic shard reallocation should have been turned off before restarting nodes. After each node restart, the next node should have been restarted only after reallocation had completely finished, not just after the log file looked fine.

   View case
3. IL-0319 Dropping databases on the MySQL replica mysql2 also dropped them on mysql1, as the pair actually ran master-master

   Oregon State University Open Source Lab2015

   Symptoms

   On July 30th, a few minutes after the OSU Open Source Lab started reloading the MySQL server mysql2 to fix its replication errors, the team saw that databases were being dropped on mysql1 as well. The script was stopped, and the MySQL service behind mysql1-vip stayed down through a long restore.

   Data lossService outageReplication lag

   Trigger

   On July 30th at 4:00PM PDT the team stopped slave replication on mysql2 and began dropping its databases one at a time to reload it and fix replication errors.

   Root cause

   Operator error

   Component

   DatabaseDatabase replicationDatabase backups and snapshots

   Contributing factor

   Unverified assumptionUntested backup

   Detection

   The team watching the reload noticed after a few minutes that mysql1 was also dropping databases; the delays between drops in the script gave them that time.

   Remediation

   • Stopped the script that was dropping databases
   • Restored the databases from the mysql-zrm backups
   • Pulled each database that failed to restore out of the 200GB backup file and restored it separately
   • Recovered most data with the binary logs from the 17th through the 30th

   Action items

   • Evaluate better replication strategies, including row-based replication
   • Store binlogs as a backup on a separate server
   • Take backups with Percona XtraBackup for much faster full restores
   • Use mydumper instead of mysql-zrm for faster logical backups
   • Improve documentation and training for complex systems
   • Test full restores regularly on a spare server as part of the backup process
   • Gather more accurate time estimates for the restore process
   • Audit the hosted databases regularly, since test and very large databases delayed the restore
   • Migrate to a bigger, more powerful MySQL cluster
   • Set a policy and tools to keep the community informed of outages, maintenance and resource use, with dashboards
   • Define and monitor capacity limits for core services
   • Implement redundancy and restore practices for core services, including staff drills
   • Migrate more core services to Chef
   • Review documentation, policies and performance metrics periodically
   • Find better ways to draw on community expertise
   • Raise funds to replace the oldest infrastructure and reduce technical debt

   Lessons

   The lab had stretched its resources to host as many projects as possible, and that came with tradeoffs such as heavily compressed backups to save disk and less redundancy than wanted; the heavy compression made this restore CPU-bound. The lab concluded that it needs to change how it plans, monitors and manages resources, and that the length of the outage and the lack of progress reports were not acceptable.

   View case

By root cause1