Bir mühendis GitLab'ın üretim veritabanını sildi. 300 gigabayt.
31 Ocak 2017, 23:27 UTC: uzun bir gecenin sonunda bozuk bir replikayla mücadele eden bir GitLab mühendisi, db2 yerine db1 üzerindeki PostgreSQL veri dizinini siler.
31 Ocak 2017, 23:27 UTC: uzun bir gecenin sonunda bozuk bir replikayla mücadele eden bir GitLab mühendisi, db2 yerine db1 üzerindeki PostgreSQL veri dizinini siler. db1 birincil sunucudur. GitLab.com'un veritabanının yaklaşık 300 GB'ı bir iki saniye içinde yok olur ve beş yedekleme ve çoğaltma mekanizmasından hiçbiri çalışmamaktadır. Postmortem: spam artışından yanlış ana bilgisayar adına kadar zaman çizelgesi, pg_basebackup'ın neden takılı kalmış gibi göründüğü, pg_dump'ın neden sessizce başarısız olduğu (9.6 veritabanında 9.2 ikili dosyaları, DMARC tarafından geri çevrilen hata e-postaları), 6 saatlik bir hazırlık anlık görüntüsünden 18 saatlik bir geri yükleme YouTube'da canlı yayınlandı ve suçu gerçekten kimin aldığı. Yanıt hakkındaki karar: SHIP IT.
Yazılı sürümü oku (İngilizce) ↗
Bu video neleri kapsar
- 31 Ocak 2017: birincil sunucunun veri dizini üzerinde rm -Rvf; ~300 GB silindi, 4.5 GB kaldı
- 5 yedekten 5'i başarısız: boş S3 kovası (pg_dump sürüm uyuşmazlığı), DB'de Azure anlık görüntüsü yok, silinmiş replika, web kancaları olmayan günlük LVM kopyası
- 1 Şubat, 18:00 UTC: GitLab.com 6 saatlik manuel bir anlık görüntüden geri döndü; canlı belge, canlı yayın, düzeltme listesiyle suçsuz postmortem
Çevrilmiş deşifre
Orijinal İngilizce anlatımdan çevrilmiştir. Mevcut ses ve altyazılar YouTube tarafından kontrol edilir.
0:00 GitLab'daki bir mühendis yanlış veritabanı sunucusunda rm -rf komutunu çalıştırır, ve GitLab.com'un üç yüz gigabaytı bir iki saniye içinde yok olur, bir ana bilgisayar adını okumak ne kadar sürerse o kadar. 31 Ocak 2017, akşam 11:27. UTC. GitLab, üretim verilerini yanlışlıkla sildiğini tweet'ler, olay notlarını internete açar ve kurtarma işlemini YouTube'da yayınlar, platformdaki iki numaralı canlı yayın. Ertesi gün, yazılı olarak: beş yedekleme tekniğinden,
0:25 hiçbiri güvenilir bir şekilde çalışmıyor. Nasıl oluyor, neden mümkün ve suçu aslında kim alıyor. Bu The Daily Diff, postmortem. Öğleden sonra 5:20: bir mühendis üretimden anlık görüntü alır hazırlık ortamında bir yük dengeleyiciyi test etmek için. Akşam 7: spam veritabanını vurur, ayrıca bir iş GitLab çalışanını zorla siler, bir trol kötüye kullanım için bildirdi. Akşam 11: replika o kadar geride kalır ki birincil sunucu zaten attığı
0:48 ihtiyaç duyduğu günlüğü; tek çözüm replikayı silmek ve birinciliyi kopyalamaktır tekrar. pg_basebackup çıktı vermeden takılır. Aslında sessizce birincil sunucuyu bekliyor; bunu kimse bilmiyor, ve çalışma kitabı söylemiyor. Akşam on birde işi bırakmak isteyen mühendis, boş veri dizininin sorun olduğunu düşünür ve onu siler. db1'de. Birincil sunucu. Bir iki saniye sonra fark eder; yaklaşık üç yüz gigabayttan,
1:11 4.5 kalır. Yedeklemeler. Bir: S3'e pg_dump, günlük. Kova boş. Cron işi veritabanı olmayan bir uygulama sunucusunda çalışır, bu yüzden paket 9.6 veritabanı için PostgreSQL 9.2 ikili dosyalarını alır, başarısız olur ve başarısızlığı e-posta ile gönderir, bu da DMARC eksikliği nedeniyle geri döner. İki: Azure disk anlık görüntüleri, dosya sunucuları için etkinleştirilmiş, veritabanları için değil.
1:32 Üç: replika, bir saat önce kasıtlı olarak silinmiş. Dört: günlük anlık görüntü, 24 saatlik, her web kancası hazırlık senkronizasyonu tarafından kaldırılmış. Beş: 5:20'den manuel anlık görüntü, ilgisiz bir test için. Bu kazanır. Geri yükleme, hazırlık diskini Azure'un ucuz depolaması üzerinden saniyede altmış megabit hızla üretime geri kopyalamak demektir: on sekiz saat. GitLab.com 1 Şubat akşam altıda geri döndü. UTC, altı saatlik veri daha eski.
1:58 git blame: bir karakter arayla iki ana bilgisayar adı ve kimsenin hiç geri yüklemediği beş yedekleme sistemi. Mühendis değil. CEO tarafından imzalanan postmortem, onu anonim tutar, üretim istemcisini kırmızı renklendirir ve veri kalıcılığına bir sahip verir, çünkü şimdiye kadar hiç yoktu. Patlama yarıçapı: on sekiz saat kapalı, altı saatlik veri kayıp, yaklaşık beş bin proje, beş bin yorum,
2:18 yedi yüz yeni kullanıcı ve beş bin kişi bir ilerleme çubuğunu izliyor. Hacker News canlı belgeye 1.162 puan verir ve onlara bir cümleyi geri alıntılar: beş yedekten hiçbiri. Karar, postmortem: yanıta SHIP IT. Olayı halka açık yürütüyorlar, süreci suçluyorlar ve düzeltme listesini sorun numaralarıyla yayınlıyorlar. Pazartesi eylemi: bir yedeği geri yükleyin. Eğer hiç geri yüklemediyseniz, bir tane sahip değilsinizdir.
2:42 Hakkında konuşmanıza hala izin verilmeyen olayı bana gönderin, yorumlar bölümünde veya daily diff dot dev adresinden. Ve bugünün farkı bu. Ben Axrisi'den Niko. Sorumlulukla birleştirin.
Kaynaklar
- 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
