# ინჟინერმა GitLab-ის საწარმოო მონაცემთა ბაზა წაშალა. 300 გიგაბაიტი.

Published: 2026-09-10

2017 წლის 31 იანვარი, 23:27 UTC: GitLab-ის ინჟინერი, რომელიც დიდხნიანი ღამის ბოლოს გატეხილ რეპლიკას ებრძვის, db1-ზე PostgreSQL-ის მონაცემთა დირექტორიას შლის db2-ის ნაცვლად. db1 არის მთავარი. GitLab.com-ის მონაცემთა ბაზის დაახლოებით 300 GB ქრება წამში ან ორში, და ხუთი სარეზერვო და რეპლიკაციის მექანიზმიდან არცერთი არ მუშაობს. შემდგომი ანალიზი: ვადები სპამის ზრდიდან არასწორ ჰოსტნეიმამდე, რატომ ჩანდა pg\_basebackup გაჭედილი, რატომ მარცხდებოდა pg\_dump ჩუმად (9.2 ორობითი ფაილები 9.6 მონაცემთა ბაზაზე, მარცხის ელ.ფოსტები DMARC-ის მიერ დაბლოკილი), 18-საათიანი აღდგენა 6-საათიანი წინასწარი ვერსიის სნეპშოტიდან, რომელიც პირდაპირ ეთერში გადაიცემოდა YouTube-ზე, და ვის ეკისრება რეალურად ბრალი. გადაწყვეტილება რეაგირებაზე: SHIP IT.

Canonical: https://thedailydiff.dev/ka/video/2026-09-10-gitlab-rm-rf/

## რას მოიცავს ეს ვიდეო

- 2017 წლის 31 იანვარი: rm -Rvf მთავარი სერვერის მონაცემთა დირექტორიაზე; ~300 GB წაიშალა, 4.5 GB დარჩა
- 5-დან 5 სარეზერვო ასლი მარცხდება: ცარიელი S3 bucket (pg\_dump ვერსიის შეუსაბამობა), მონაცემთა ბაზაზე Azure-ის სნეპშოტები არ არის, წაშლილი რეპლიკა, ყოველდღიური LVM ასლი ვებჰუკების გარეშე
- 1 თებერვალი, 18:00 UTC: GitLab.com დაუბრუნდა 6-საათიან, ხელით გაკეთებულ სნეპშოტს; ცოცხალი დოკუმენტი, პირდაპირი ტრანსლაცია, უდანაშაულო შემდგომი ანალიზი გამოსწორების სიით

## ნათარგმნი ტრანსკრიპტი

ნათარგმნია ორიგინალური ინგლისური ნარატივიდან. ხელმისაწვდომი აუდიო და სუბტიტრები კონტროლდება YouTube-ის მიერ.

0:00 GitLab-ის ინჟინერი არასწორ მონაცემთა ბაზის სერვერზე აწარმოებს rm -rf-ს, და სამასი გიგაბაიტი GitLab dot com ქრება წამში ან ორში, დაახლოებით ის დრო, რაც ჰოსტნეიმის წასაკითხად არის საჭირო. 2017 წლის 31 იანვარი, საღამოს 11:27. UTC. GitLab ტვიტავს, რომ შემთხვევით წაშალა საწარმოო მონაცემები, ინციდენტის ჩანაწერებს ინტერნეტს უხსნის და აღდგენას YouTube-ზე გადასცემს, პლატფორმაზე მეორე ყველაზე ყურებადი ლაივ სტრიმია. მეორე დღეს, წერილობით: ხუთი სარეზერვო ტექნიკიდან,

0:25 არცერთი საიმედოდ არ მუშაობს. როგორ ხდება, რატომ არის შესაძლებელი და ვის ეკისრება რეალურად ბრალი. ეს არის The Daily Diff, შემდგომი ანალიზი. საღამოს 5:20: ინჟინერი აკეთებს საწარმოო სნეპშოტს დატვირთვის ბალანსერის შესამოწმებლად განვითარების გარემოში. საღამოს 7:00: სპამი აწვება მონაცემთა ბაზას, პლუს სამუშაო, რომელიც უხეშად შლის GitLab-ის თანამშრომელს, რომელიც ტროლმა ძალადობისთვის დააფიქსირა. საღამოს 11:00: რეპლიკა ისე ჩამორჩა, რომ მთავარმა სერვერმა უკვე წაშალა

0:48 მისთვის საჭირო ჟურნალი; ერთადერთი გამოსავალია რეპლიკის წაშლა და მთავარი სერვერის ხელახლა კოპირება. pg\_basebackup გაიჭედა გამოსავლის გარეშე. ის რეალურად ჩუმად ელოდება მთავარ სერვერს; არავინ იცის ეს, და runbook არ ამბობს. ინჟინერი, რომელსაც თერთმეტზე უნდა მოეწერა ხელი, გადაწყვეტს, რომ ცარიელი მონაცემთა დირექტორია პრობლემაა და შლის მას. db1-ზე. მთავარ სერვერზე. ის წამში ან ორში ამჩნევს; დაახლოებით სამასი გიგაბაიტიდან,

1:11 4.5 რჩება. სარეზერვო ასლები. ერთი: pg\_dump S3-ზე, ყოველდღიურად. bucket ცარიელია. cron-ის დავალება მუშაობს აპლიკაციის სერვერზე მონაცემთა ბაზის გარეშე, ამიტომ პაკეტი ირჩევს PostgreSQL 9.2 ორობით ფაილებს 9.6 მონაცემთა ბაზისთვის, მარცხდება და აგზავნის ელ.ფოსტებს მარცხის შესახებ, რომელიც DMARC-ის ნაკლებობის გამო უკუაგდებს. ორი: Azure-ის დისკის სნეპშოტები, ჩართულია ფაილურ სერვერებისთვის, არა მონაცემთა ბაზებისთვის.

1:32 სამი: რეპლიკა, მიზანმიმართულად წაშლილი ერთი საათის წინ. ოთხი: ყოველდღიური სნეპშოტი, 24 საათის წინანდელი, ყოველი ვებჰუკი ამოღებულია განვითარების გარემოს სინქრონიზაციით. ხუთი: ხელით გაკეთებული სნეპშოტი 5:20-დან, დაუკავშირებელი ტესტისთვის. ეს იმარჯვებს. აღდგენა ნიშნავს განვითარების გარემოს დისკის უკან საწარმოო გარემოში კოპირებას Azure-ის იაფი საცავით სამოცი მეგაბიტი წამში: თვრამეტი საათი. GitLab dot com ბრუნდება 1 თებერვალს საღამოს ექვს საათზე UTC, ექვსი საათით ძველი მონაცემებით.

1:58 git blame: ორი ჰოსტნეიმი ერთ სიმბოლოში განსხვავდება, და ხუთი სარეზერვო სისტემა, რომელთაგან არავის არასოდეს აღუდგენია. არა ინჟინერი. შემდგომი ანალიზი, CEO-ს მიერ ხელმოწერილი, მას ანონიმურად ტოვებს, საწარმოო გარემოს მოთხოვნას წითლად აფერადებს და მონაცემთა გამძლეობას მფლობელს აძლევს, რადგან აქამდე მას არ ჰყავდა. დაზიანების რადიუსი: თვრამეტი საათი გათიშული, ექვსი საათის მონაცემები დაკარგული, დაახლოებით ხუთი ათასი პროექტი, ხუთი ათასი კომენტარი,

2:18 შვიდასი ახალი მომხმარებელი და ხუთი ათასი ადამიანი უყურებს პროგრესის ზოლს. Hacker News-მა ცოცხალ დოკუმენტს 1,162 ქულა მიანიჭა და ერთი სტრიქონი მოჰყავს უკან: ხუთი სარეზერვო ასლიდან, არცერთი. ვერდიქტი, შემდგომი ანალიზი: SHIP IT, რეაგირებაზე. ისინი ინციდენტს საჯაროდ ატარებენ, ბრალს პროცესს სდებენ და გამოსწორების სიას საკითხის ნომრებით აქვეყნებენ. ორშაბათის მოქმედება: სარეზერვო ასლის აღდგენა. თუ არასოდეს აღგიდგენიათ, არ გაქვთ.

2:42 გამომიგზავნეთ ინციდენტი, რომელზეც ჯერ კიდევ არ გაქვთ საუბრის უფლება, კომენტარებში, ან daily diff dot dev-ზე. და ეს არის დღევანდელი diff. მე ვარ ნიკო Axrisi-დან. პასუხისმგებლობით გააერთიანეთ.

## წყაროები

- [GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/) — about.gitlab.com
- [GitLab, "GitLab.com database incident" (Feb 1, 2017)](https://about.gitlab.com/blog/gitlab-dot-com-database-incident/) — about.gitlab.com
- [@gitlabstatus, "We accidentally deleted production data…"](https://twitter.com/gitlabstatus/status/826591961444384768) — twitter.com
- [@gitlabstatus, emergency maintenance notice](https://twitter.com/gitlabstatus/status/826572933304827904) — twitter.com
- [Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)](https://news.ycombinator.com/item?id=13537052) — news.ycombinator.com
- [Hacker News, the postmortem thread (377 points)](https://news.ycombinator.com/item?id=13619714) — news.ycombinator.com