Un inginer a șters baza de date de producție a GitLab. 300 de gigabytes.
31 ianuarie 2017, 23:27 UTC: un inginer GitLab, luptându-se cu o replică defectă la sfârșitul unei nopți lungi, elimină directorul de date PostgreSQL de pe db1 în loc de db2.
31 ianuarie 2017, 23:27 UTC: un inginer GitLab, luptându-se cu o replică defectă la sfârșitul unei nopți lungi, elimină directorul de date PostgreSQL de pe db1 în loc de db2. db1 este primarul. Aproximativ 300 GB din baza de date GitLab.com dispar într-o secundă sau două, iar dintre cele cinci mecanisme de backup și replicare, niciunul nu funcționează. Postmortem: cronologia de la vârful de spam la numele de gazdă greșit, de ce pg_basebackup părea blocat, de ce pg_dump eșua în tăcere (binare 9.2 pe o bază de date 9.6, e-mailurile de eșec respinse de DMARC), restaurarea de 18 ore dintr-un snapshot de staging de 6 ore, transmisă în direct pe YouTube, și cine este cu adevărat de vină. Verdictul privind răspunsul: SHIP IT.
Citiți ediția scrisă (engleză) ↗
Ce acoperă acest videoclip
- 31 ianuarie 2017: rm -Rvf în directorul de date al primarului; ~300 GB eliminați, 4.5 GB rămași
- 5 din 5 backup-uri eșuează: bucket S3 gol (incompatibilitate versiune pg_dump), fără snapshot-uri Azure pe baza de date, replică ștearsă, copie LVM zilnică fără webhooks
- 1 februarie, 18:00 UTC: GitLab.com revine dintr-un snapshot manual de 6 ore; document live, stream live, postmortem fără vină cu o listă de remedieri
Transcrierea tradusă
Tradus din narațiunea originală în engleză. Audio-ul și subtitrările disponibile sunt controlate de YouTube.
0:00 Un inginer de la GitLab rulează rm -rf pe serverul de baze de date greșit, și trei sute de gigabytes de GitLab dot com dispar într-o secundă sau două, cam cât durează să citești un nume de gazdă. 31 ianuarie 2017, 11:27 p.m. UTC. GitLab tweet-uiește că a șters accidental date de producție, își deschide notele de incident către internet și transmite în direct recuperarea pe YouTube, al doilea cel mai urmărit stream live de pe platformă. A doua zi, în scris: din cinci tehnici de backup,
0:25 niciuna nu funcționează fiabil. Cum se întâmplă, de ce este posibil și cine primește de fapt vina. Acesta este The Daily Diff, postmortem. 17:20: un inginer face un snapshot al producției pentru a testa un echilibrator de sarcină în staging. 19:00: spam-ul bombardează baza de date, plus o sarcină care șterge definitiv un angajat GitLab, un trol raportat pentru abuz. 23:00: replica rămâne atât de mult în urmă încât primarul a aruncat deja
0:48 log-ul de care are nevoie; singura soluție este să ștergi replica și să copiezi primarul din nou. pg_basebackup se blochează fără ieșire. De fapt, așteaptă, în tăcere, primarul; nimeni nu știe asta, iar ghidul de proceduri nu o menționează. Inginerul, care intenționa să își termine programul la unsprezece, decide că directorul de date gol este problema și îl elimină. Pe db1. Primarul. Observă o secundă sau două mai târziu; din aproximativ trei sute de gigabytes,
1:11 4.5 rămân. Backup-urile. Unu: pg_dump către S3, zilnic. Bucket-ul este gol. Sarcina cron rulează pe un server de aplicații fără bază de date, așa că pachetul alege binare PostgreSQL 9.2 pentru o bază de date 9.6, eșuează și trimite e-mailuri de eșec, care sunt respinse din cauza DMARC-ului lipsă. Doi: snapshot-uri de disc Azure, activate pentru serverele de fișiere, nu și pentru baze de date.
1:32 Trei: replica, ștearsă intenționat cu o oră în urmă. Patru: snapshot-ul zilnic, vechi de 24 de ore, fiecare webhook eliminat de sincronizarea staging. Cinci: snapshot-ul manual de la 5:20, pentru un test nelegat. Acesta câștigă. Restaurarea înseamnă copierea discului de staging înapoi în producție peste stocarea ieftină a Azure la șaizeci de megabiți pe secundă: optsprezece ore. GitLab dot com revine pe 1 februarie la ora șase p.m. UTC, cu șase ore de date mai vechi.
1:58 git blame: două nume de gazdă la distanță de un caracter și cinci sisteme de backup din care nimeni nu a restaurat vreodată. Nu inginerul. Postmortem-ul, semnat de CEO, îl păstrează anonim, colorează în roșu prompt-ul de producție și atribuie durabilității datelor un proprietar, pentru că până acum nu avea niciunul. Raza de acțiune: optsprezece ore de inactivitate, șase ore de date pierdute, aproximativ cinci mii de proiecte, cinci mii de comentarii,
2:18 șapte sute de utilizatori noi și cinci mii de oameni care urmăresc o bară de progres. Hacker News acordă documentului live 1.162 de puncte și citează o replică: din cinci backup-uri, niciunul. Verdict, postmortem: SHIP IT, privind răspunsul. Ei gestionează incidentul în public, blamează procesul și publică lista de remedieri cu numere de probleme. Acțiunea de luni: restaurează un backup. Dacă nu l-ați restaurat niciodată, nu aveți unul.
2:42 Trimiteți-mi incidentul despre care încă nu aveți voie să vorbiți, în comentarii sau la the daily diff dot dev. Și asta este diff-ul pentru astăzi. Sunt Niko de la Axrisi. Îmbinați responsabil.
Surse
- 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
