Ein Ingenieur löschte die Produktionsdatenbank von GitLab. 300 Gigabyte.
31.
31. Januar 2017, 23:27 UTC: Ein GitLab-Ingenieur, der am Ende einer langen Nacht gegen eine defekte Replika kämpfte, entfernte das PostgreSQL-Datenverzeichnis auf db1 anstelle von db2. db1 ist die primäre Datenbank. Etwa 300 GB der GitLab.com-Datenbank sind innerhalb von ein oder zwei Sekunden verschwunden, und von den fünf Backup- und Replikationsmechanismen funktioniert keiner. Postmortem: die Zeitachse vom Spam-Spike zum falschen Hostnamen, warum pg_basebackup festgefahren schien, warum pg_dump stillschweigend fehlschlug (9.2-Binärdateien auf einer 9.6-Datenbank, Fehler-E-Mails wurden von DMARC abgewiesen), die 18-stündige Wiederherstellung von einem 6 Stunden alten Staging-Snapshot, live auf YouTube gestreamt, und wer wirklich die Schuld trägt. Urteil zur Reaktion: SHIP IT.
Die schriftliche Ausgabe lesen (Englisch) ↗
Was dieses Video behandelt
- 31. Jan. 2017: rm -Rvf auf dem Datenverzeichnis der primären Datenbank; ~300 GB entfernt, 4,5 GB übrig
- 5 von 5 Backups schlagen fehl: leerer S3-Bucket (Versionskonflikt bei pg_dump), keine Azure-Snapshots auf der DB, gelöschte Replika, tägliche LVM-Kopie ohne Webhooks
- 1. Feb., 18:00 UTC: GitLab.com wiederhergestellt von einem 6 Stunden alten manuellen Snapshot; Live-Dokument, Live-Stream, blameless Postmortem mit einer Fixliste
Übersetztes Transkript
Aus der englischen Originalerzählung übersetzt. Verfügbare Audio- und Untertitel werden von YouTube gesteuert.
0:00 Ein Ingenieur bei GitLab führt rm -rf auf dem falschen Datenbankserver aus, und dreihundert Gigabyte von GitLab dot com verschwinden in ein oder zwei Sekunden, ungefähr so lange, wie es dauert, einen Hostnamen zu lesen. 31. Januar 2017, 23:27 Uhr UTC. GitLab twittert, dass es versehentlich Produktionsdaten gelöscht hat, öffnet seine Incident-Notizen dem Internet und streamt die Wiederherstellung auf YouTube, der zweitmeistgesehene Livestream auf der Plattform. Am nächsten Tag, schriftlich: Von fünf Backup-Techniken
0:25 funktioniert keine zuverlässig. Wie es passiert, warum es möglich ist und wer tatsächlich die Schuld trägt. Dies ist The Daily Diff, Postmortem. 17:20 Uhr: Ein Ingenieur erstellt einen Snapshot der Produktion um einen Load Balancer im Staging zu testen. 19 Uhr: Spam hämmert auf die Datenbank ein, plus ein Job, der einen GitLab-Mitarbeiter eines Trolls, der Missbrauch gemeldet hat, endgültig löscht. 23 Uhr: Die Replika gerät so weit ins Hintertreffen, dass die Primärdatenbank das Protokoll, das sie benötigt,
0:48 bereits verworfen hat; die einzige Lösung ist, die Replika zu löschen und die Primärdatenbank erneut zu kopieren. pg_basebackup hängt ohne Ausgabe fest. Es wartet tatsächlich, stillschweigend, auf die Primärdatenbank; niemand weiß das, und das Handbuch sagt es nicht. Der Ingenieur, der sich um elf Uhr abmelden wollte, entscheidet, dass das leere Datenverzeichnis das Problem ist und entfernt es. Auf db1. Der Primärdatenbank. Er bemerkt es ein oder zwei Sekunden später; von ungefähr dreihundert Gigabyte
1:11 bleiben 4,5 übrig. Die Backups. Eins: pg_dump nach S3, täglich. Der Bucket ist leer. Der Cron-Job läuft auf einem App-Server ohne Datenbank, so dass das Paket PostgreSQL 9.2 Binärdateien für eine 9.6 Datenbank auswählt, fehlschlägt und die Fehlermeldung sendet, die wegen fehlendem DMARC abgewiesen wird. Zwei: Azure Disk-Snapshots, aktiviert für die Dateiserver, nicht die Datenbanken.
1:32 Drei: die Replika, absichtlich vor einer Stunde gelöscht. Vier: der tägliche Snapshot, 24 Stunden alt, jede Webhook durch die Staging-Synchronisation entfernt. Fünf: der manuelle Snapshot von 17:20 Uhr, für einen nicht verwandten Test. Der gewinnt. Wiederherstellen bedeutet, die Staging-Festplatte über Azures günstigen Speicher mit sechzig Megabit pro Sekunde zurück in die Produktion zu kopieren: achtzehn Stunden. GitLab dot com ist am 1. Februar um 18 Uhr UTC zurück, sechs Stunden Daten älter.
1:58 git blame: zwei Hostnamen, die sich nur um ein Zeichen unterscheiden, und fünf Backup-Systeme, von denen niemand jemals eine Wiederherstellung durchgeführt hat. Nicht der Ingenieur. Das Postmortem, vom CEO unterzeichnet, hält ihn anonym, färbt die Produktionsaufforderung rot und gibt der Datenbeständigkeit einen Verantwortlichen, denn bis jetzt hatte sie keinen. Blast Radius: achtzehn Stunden Ausfallzeit, sechs Stunden Datenverlust, ungefähr fünftausend Projekte, fünftausend Kommentare,
2:18 siebenhundert neue Benutzer und fünftausend Leute, die einen Fortschrittsbalken beobachten. Hacker News gibt dem Live-Dokument 1.162 Punkte und zitiert eine Zeile zurück an sie: Von fünf Backups, keines. Urteil, Postmortem: SHIP IT, bezüglich der Reaktion. Sie führen den Vorfall öffentlich durch, geben dem Prozess die Schuld und veröffentlichen die Fixliste mit Problem-Nummern. Aktion am Montag: ein Backup wiederherstellen. Wenn Sie es nie wiederhergestellt haben, haben Sie keines.
2:42 Senden Sie mir den Vorfall, über den Sie immer noch nicht sprechen dürfen, in den Kommentaren oder unter the daily diff dot dev. Und das ist der Diff für heute. Ich bin Niko von Axrisi. Merge responsibly.
Quellen
- GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
- GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
- @gitlabstatus, "We accidentally deleted production data…"twitter.com
- @gitlabstatus, emergency maintenance noticetwitter.com
- Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
- Hacker News, the postmortem thread (377 points)news.ycombinator.com
