+− THE DAILY DIFFdev & AI news
Mga Video / postmortem
SHIP IT

Isang inhenyero ang nagtanggal ng production database ng GitLab. 300 gigabytes.

Nai-publish Set 10, 2026 · 2:53 · Niko from Axrisi

Enero 31, 2017, 23:27 UTC: Isang inhenyero ng GitLab, na nakikipaglaban sa isang sirang replica sa pagtatapos ng isang mahabang gabi, ay tinanggal ang PostgreSQL data directory sa db1 sa halip na db2.

Enero 31, 2017, 23:27 UTC: Isang inhenyero ng GitLab, na nakikipaglaban sa isang sirang replica sa pagtatapos ng isang mahabang gabi, ay tinanggal ang PostgreSQL data directory sa db1 sa halip na db2. Ang db1 ang pangunahin. Halos 300 GB ng database ng GitLab.com ay nawala sa loob ng isa o dalawang segundo, at sa limang mekanismo ng backup at replication, wala ni isa ang gumagana. Postmortem: ang timeline mula sa pagtaas ng spam hanggang sa maling hostname, kung bakit tila stuck ang pg_basebackup, kung bakit tahimik na bumabagsak ang pg_dump (9.2 binaries sa isang 9.6 database, ang mga failure e-mail ay na-bounce ng DMARC), ang 18-oras na pag-restore mula sa isang 6-oras na lumang staging snapshot na naka-stream nang live sa YouTube, at kung sino talaga ang dapat sisihin. Hatol sa tugon: SHIP IT.

Basahin ang nakasulat na edisyon (English) ↗

Ang sakop ng video na ito

  • Ene 31, 2017: rm -Rvf sa data directory ng primary; ~300 GB tinanggal, 4.5 GB natira
  • 5 sa 5 backup ay bumagsak: walang laman na S3 bucket (pg_dump version mismatch), walang Azure snapshots sa DB, naburang replica, pang-araw-araw na LVM copy nang walang webhooks
  • Peb 1, 18:00 UTC: GitLab.com ay bumalik mula sa isang 6-oras na lumang manual snapshot; live doc, live stream, blameless postmortem na may listahan ng pag-aayos

Isinaling transcript

Isinalin mula sa orihinal na salaysay sa English. Ang available na audio at mga caption ay kinokontrol ng YouTube.

0:00 Isang inhenyero sa GitLab ang nagpatakbo ng rm -rf sa maling database server, at tatlong daang gigabytes ng GitLab dot com ay nawala sa loob ng isa o dalawang segundo, halos kung gaano katagal basahin ang isang hostname. Enero 31, 2017, 11:27 p.m. UTC. Nag-tweet ang GitLab na aksidente nitong natanggal ang production data, binuksan ang incident notes nito sa internet, at ipinalabas ang pag-recover sa YouTube, ang pangalawang live stream sa platform. Kinabukasan, sa sulat: sa limang teknik ng backup,

0:25 wala ni isa ang gumagana nang maaasahan. Paano ito nangyari, bakit ito posible, at sino talaga ang dapat sisihin. Ito ang The Daily Diff, postmortem. 5:20 p.m.: isang inhenyero ang nag-snapshot ng production upang subukan ang isang load balancer sa staging. 7 p.m.: binomba ng spam ang database, kasama ang isang trabaho na hard-deleting sa isang empleyado ng GitLab na iniulat ng isang troll para sa pang-aabuso. 11 p.m.: napakalayo na ng replica kaya na-discard na ng primary

0:48 ang log na kailangan nito; ang tanging solusyon ay burahin ang replica at kopyahin ang primary muli. Nag-hang ang pg_basebackup nang walang output. Ito ay talagang naghihintay, tahimik, para sa primary; walang nakakaalam niyan, at hindi sinasabi sa runbook. Ang inhenyero, na balak sanang mag-sign off ng alas onse, ay nagpasya na ang walang laman na data directory ang problema at tinanggal ito. Sa db1. Ang primary. Napansin niya pagkatapos ng isa o dalawang segundo; sa halos tatlong daang gigabytes,

1:11 4.5 ang natira. Ang mga backup. Isa: pg_dump sa S3, araw-araw. Walang laman ang bucket. Ang cron job ay tumatakbo sa isang app server na walang database, kaya ang package ay pumipili ng PostgreSQL 9.2 binaries para sa isang 9.6 database, bumagsak, at nag-e-mail ng failure, na na-bounce para sa nawawalang DMARC. Dalawa: Azure disk snapshots, naka-enable para sa mga file server, hindi sa mga database.

1:32 Tatlo: ang replica, sinadyang burahin isang oras na ang nakalipas. Apat: ang pang-araw-araw na snapshot, 24 na oras na ang lumipas, bawat webhook ay tinanggal ng staging sync. Lima: ang manual snapshot mula 5:20, para sa isang hindi kaugnay na pagsubok. Iyon ang nanalo. Ang pag-restore ay nangangahulugang pagkopya ng staging disk pabalik sa production sa ibabaw ng murang imbakan ng Azure sa animnapung megabits per second: labingwalong oras. Bumalik ang GitLab dot com noong Pebrero 1 ng alas sais ng gabi UTC, mas matanda ng anim na oras ng data.

1:58 git blame: dalawang hostname na may isang karakter lang ang agwat, at limang backup system na wala pa ni isa ang na-restore. Hindi ang inhenyero. Ang postmortem, na nilagdaan ng CEO, ay pinanatili siyang anonymous, nilagyan ng pulang kulay ang production prompt, at nagbigay ng may-ari sa data durability, dahil hanggang ngayon ay wala itong may-ari. Blast radius: labingwalong oras na down, anim na oras ng data ang nawala, halos limang libong proyekto, limang libong komento,

2:18 pitong daang bagong user, at limang libong tao ang nanonood ng progress bar. Ang Hacker News ay nagbigay ng 1,162 puntos sa live doc at sinipi ang isang linya pabalik sa kanila: sa limang backup, wala ni isa. Hatol, postmortem: SHIP IT, sa tugon. Isinagawa nila ang insidente sa publiko, sinisi ang proseso, at inilathala ang listahan ng pag-aayos na may mga numero ng isyu. Aksyon sa Lunes: i-restore ang isang backup. Kung hindi mo pa na-restore, wala kang backup.

2:42 Ipadala sa akin ang insidente na hindi mo pa rin pinapayagang pag-usapan, sa mga komento, o sa the daily diff dot dev. At iyon ang diff para sa araw na ito. Ako si Niko mula sa Axrisi. Merge responsibly.

Mga Pinagmulan

  1. GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
  2. GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
  3. @gitlabstatus, "We accidentally deleted production data…"twitter.com
  4. @gitlabstatus, emergency maintenance noticetwitter.com
  5. Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
  6. Hacker News, the postmortem thread (377 points)news.ycombinator.com

Mga kaugnay na video