Bir mühəndis GitLab-ın istehsal verilənlər bazasını sildi. 300 giqabayt.
31 yanvar 2017-ci il, 23:27 UTC: uzun bir gecənin sonunda xarab replika ilə mübarizə aparan bir GitLab mühəndisi, db2 əvəzinə db1-də PostgreSQL məlumat qovluğunu silir.
31 yanvar 2017-ci il, 23:27 UTC: uzun bir gecənin sonunda xarab replika ilə mübarizə aparan bir GitLab mühəndisi, db2 əvəzinə db1-də PostgreSQL məlumat qovluğunu silir. db1 əsasdır. GitLab.com verilənlər bazasının təxminən 300 GB-ı bir-iki saniyədə yox olur və beş ehtiyat nüsxə və replikasiya mexanizmindən heç biri işləmir. Postmortem: spam sıçrayışından səhv host adına qədər zaman qrafiki, pg_basebackup-ın niyə ilişib qalması, pg_dump-ın niyə səssizcə uğursuz olması (9.6 verilənlər bazasında 9.2 ikili fayllar, DMARC tərəfindən rədd edilən uğursuzluq e-poçtları), YouTube-da canlı yayımlanan 6 saatlıq köhnə mərhələli anlıq təsvirdən 18 saatlıq bərpa və günahı həqiqətən kimin daşıması. Cavab barədə qərar: SHIP IT.
Yazılı nəşri oxuyun (İngiliscə) ↗
Bu videoda nələr əhatə olunur
- 31 yanvar 2017: əsas məlumat qovluğunda rm -Rvf; ~300 GB silindi, 4.5 GB qaldı
- 5 ehtiyat nüsxənin 5-i uğursuz olur: boş S3 paketi (pg_dump versiya uyğunsuzluğu), verilənlər bazasında Azure anlıq təsvirləri yoxdur, silinmiş replika, veb-kancalar olmadan gündəlik LVM kopyası
- 1 fevral, 18:00 UTC: GitLab.com 6 saatlıq köhnə əl ilə alınmış anlıq təsvirdən geri qayıdır; canlı sənəd, canlı yayım, düzəliş siyahısı ilə günahsız postmortem
Tərcümə olunmuş transkript
Orijinal ingilis dilindəki nəqldən tərcümə edilmişdir. Mövcud audio və subtitrlər YouTube tərəfindən idarə olunur.
0:00 GitLab-da bir mühəndis səhv verilənlər bazası serverində rm -rf işlədir, və GitLab.com-un üç yüz giqabaytı bir-iki saniyədə yox olur, host adını oxumaq üçün təxminən nə qədər vaxt lazım gəlirsə o qədər. 31 yanvar 2017-ci il, gecə 11:27. UTC. GitLab təsadüfən istehsal məlumatlarını sildiyini tvit edir, hadisə qeydlərini internetə açır və bərpanı YouTube-da canlı yayımlayır, platformada ikinci ən çox baxılan canlı yayım. Növbəti gün, yazılı olaraq: beş ehtiyat nüsxə texnikasından,
0:25 heç biri etibarlı şəkildə işləmir. Bu necə baş verir, niyə mümkündür və əslində kim günahı daşıyır. Bu The Daily Diff, postmortemdir. Axşam 5:20: bir mühəndis istehsalın anlıq təsvirini çəkir mərhələli mühitdə yük tənzimləyicisini sınamaq üçün. Axşam 7: spam verilənlər bazasını döyür, üstəlik bir iş GitLab işçisini sərt şəkildə silir bir troll sui-istifadə barədə məlumat verdi. Axşam 11: replika o qədər geridə qalır ki, əsas artıq atmışdı
0:48 ona lazım olan jurnalı; yeganə həll replikanı silmək və əsası kopyalamaqdır yenidən. pg_basebackup heç bir çıxış olmadan donur. Əslində səssizcə əsası gözləyir; bunu heç kim bilmir, və icra kitabı bunu bildirmir. Saat on bir də işdən çıxmağı düşünən mühəndis, boş məlumat qovluğunun problem olduğuna qərar verir və onu silir. Db1-də. Əsas. Bir-iki saniyə sonra fərq edir; təxminən üç yüz giqabaytdan,
1:11 4.5 qaldı. Ehtiyat nüsxələr. Bir: S3-ə pg_dump, gündəlik. Paket boşdur. Cron işi verilənlər bazası olmayan bir proqram serverində işləyir, buna görə paket seçir 9.6 verilənlər bazası üçün PostgreSQL 9.2 ikili faylları, uğursuz olur və e-poçt göndərir uğursuzluğu, bu da DMARC olmadığı üçün geri qayıdır. İki: Azure disk anlıq təsvirləri, fayl serverləri üçün aktivdir, verilənlər bazaları üçün deyil.
1:32 Üç: replika, bir saat əvvəl qəsdən silindi. Dörd: gündəlik anlıq təsvir, 24 saatlıq, hər bir veb-kancası çıxarılmışdır mərhələli sinxronizasiya. Beş: 5:20-dəki əl ilə alınmış anlıq təsvir, əlaqəsiz bir test üçün. Bu qalib gəlir. Bərpa etmək o deməkdir ki, mərhələli diski Azure-nin ucuz saxlanc yerindən saniyədə altmış meqabit sürətlə istehsala geri kopyalamaq: on səkkiz saat. Bərpa etmək o deməkdir ki, mərhələli diski Azure-nin ucuz sağlancı üzərindən saniyədə altmış meqabitlə istehsala geri kopyalamaq: on səkkiz saat. UTC, altı saat köhnə məlumatlarla.
1:58 Git blame: bir xarakter fərqi olan iki host adı və heç kimin əvvəllər bərpa etmədiyi beş ehtiyat sistem. əvvəllər bərpa etmədiyi beş ehtiyat sistem. Mühəndis deyil. CEO tərəfindən imzalanmış postmortem, onu anonim saxlayır, istehsal əmrini qırmızı rəngdə verir və məlumat davamlılığına bir sahib təyin edir, çünki indiyə qədər heç kimə aid deyildi. Partlayış radiusu: on səkkiz saat işləmədi, altı saatlıq məlumat itdi, təxminən beş min layihə, beş min şərh,
2:18 yeddi yüz yeni istifadəçi və beş min insan irəliləyiş zolağını izləyir. Hacker News canlı sənədə 1,162 bal verir və bir sətir onlara geri sitat gətirir: beş ehtiyat nüsxədən heç biri. Qərar, postmortem: cavaba görə SHIP IT. Onlar hadisəni açıq şəkildə idarə edir, prosesi günahlandırır və düzəliş siyahısını nəşr edirlər məsələ nömrələri ilə. Bazar ertəsi hərəkəti: ehtiyat nüsxəni bərpa edin. Əgər onu heç vaxt bərpa etməmisinizsə, deməli sizdə yoxdur.
2:42 Hələ də danışmağa icazə verilməyən hadisəni mənə göndərin, şərhlərdə və ya dailydiff.dev ünvanında. Və bu da bugünkü fərqdir. Mən Axrisi-dən Nikonam. Məsuliyyətlə birləşdirin.
Mənbələr
- 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



