# วิศวกรลบฐานข้อมูลการผลิตของ GitLab 300 กิกะไบต์

Published: 2026-09-10

31 มกราคม 2560, 23:27 UTC: วิศวกร GitLab ที่กำลังต่อสู้กับเรพลิกาที่เสียหายในช่วงท้ายของค่ำคืนอันยาวนาน ได้ลบไดเรกทอรีข้อมูล PostgreSQL บน db1 แทนที่จะเป็น db2 โดยที่ db1 เป็นหลักฐาน. ประมาณ 300 GB ของฐานข้อมูล GitLab.com หายไปในหนึ่งหรือสองวินาที และจากกลไกการสำรองและจำลองข้อมูลทั้งห้ากลไก ไม่มีกลไกใดทำงานเลย. การตรวจสอบภายหลัง: ไทม์ไลน์ตั้งแต่การสปายสปายที่เพิ่มขึ้นไปจนถึงชื่อโฮสต์ที่ไม่ถูกต้อง, สาเหตุที่ pg\_basebackup ดูเหมือนค้าง, สาเหตุที่ pg\_dump ล้มเหลวอย่างเงียบ ๆ (ไบนารี 9.2 บนฐานข้อมูล 9.6, อีเมลแจ้งความล้มเหลวถูกตีกลับโดย DMARC), การกู้คืน 18 ชั่วโมงจากสแนปชอตที่สร้างขึ้น 6 ชั่วโมงก่อนหน้านี้และสตรีมสดบน YouTube, และใครเป็นผู้รับผิดชอบจริง ๆ. คำตัดสินเกี่ยวกับการตอบสนอง: SHIP IT.

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

## วิดีโอนี้ครอบคลุมอะไรบ้าง

- 31 ม.ค. 2560: 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.com หายไปในหนึ่งหรือสองวินาที ประมาณระยะเวลาที่ใช้ในการอ่านชื่อโฮสต์ 31 มกราคม 2560 เวลา 23:27 น. UTC. GitLab ทวีตว่าได้ลบข้อมูลการผลิตโดยไม่ตั้งใจ เปิดบันทึกเหตุการณ์สู่สาธารณะและสตรีมการกู้คืนบน YouTube เป็นไลฟ์สตรีมอันดับสองบนแพลตฟอร์ม วันถัดมา ในบันทึก: จากเทคนิคการสำรองข้อมูลห้าวิธี

0:25 ไม่มีอันใดทำงานได้อย่างน่าเชื่อถือ มันเกิดขึ้นได้อย่างไร ทำไมมันจึงเป็นไปได้ และใครเป็นผู้รับผิดชอบจริงๆ นี่คือ The Daily Diff, postmortem 17:20 น.: วิศวกรสร้างสแนปชอตการผลิต เพื่อทดสอบโหลดบาลานเซอร์ใน staging 19:00 น.: สแปมถล่มฐานข้อมูล และงานที่ลบพนักงาน GitLab อย่างถาวร โทรลล์รายงานการละเมิด 23:00 น.: เรพลิกาตามหลังมากจนหลักฐานได้ทิ้ง

0:48 บันทึกที่ต้องการไปแล้ว; ทางแก้เดียวคือลบเรพลิกาและคัดลอกหลักฐาน อีกครั้ง pg\_basebackup ค้างโดยไม่มีผลลัพธ์ มันกำลังรออย่างเงียบๆ สำหรับหลักฐาน; ไม่มีใครรู้เรื่องนั้น และคู่มือไม่ได้บอก วิศวกรที่ตั้งใจจะเลิกงานตอนสิบเอ็ดโมง ตัดสินใจว่าไดเรกทอรีข้อมูลว่างเปล่า คือปัญหาและลบมันทิ้ง บน db1. หลักฐาน เขาสังเกตเห็นในหนึ่งหรือสองวินาทีต่อมา; จากประมาณสามร้อยกิกะไบต์

1:11 เหลือ 4.5. การสำรองข้อมูล หนึ่ง: pg\_dump ไป S3, รายวัน ถังเก็บข้อมูลว่างเปล่า งาน cron ทำงานบนเซิร์ฟเวอร์แอปพลิเคชันที่ไม่มีฐานข้อมูล ดังนั้นแพ็คเกจจึงเลือก ไบนารี PostgreSQL 9.2 สำหรับฐานข้อมูล 9.6, ล้มเหลว, และส่งอีเมล ความล้มเหลวซึ่งถูกตีกลับเนื่องจาก DMARC หายไป สอง: สแนปชอตดิสก์ Azure, เปิดใช้งานสำหรับเซิร์ฟเวอร์ไฟล์ ไม่ใช่ฐานข้อมูล

1:32 สาม: เรพลิกา, ถูกลบโดยตั้งใจเมื่อหนึ่งชั่วโมงที่แล้ว สี่: สแนปชอตรายวัน, อายุ 24 ชั่วโมง, เว็บฮุกทั้งหมดถูกลบออกโดย การซิงค์ staging. ห้า: สแนปชอตด้วยตนเองจาก 5:20, สำหรับการทดสอบที่ไม่เกี่ยวข้อง อันนั้นชนะ การกู้คืนหมายถึงการคัดลอกดิสก์ staging กลับสู่การผลิตผ่านพื้นที่เก็บข้อมูลราคาถูกของ Azure ที่หกสิบเมกะบิตต่อวินาที: สิบแปดชั่วโมง GitLab.com กลับมาในวันที่ 1 กุมภาพันธ์ เวลาหกโมงเย็น UTC, ข้อมูลเก่าไปหกชั่วโมง

1:58 git blame: ชื่อโฮสต์สองชื่อที่ต่างกันเพียงอักขระเดียว และระบบสำรองข้อมูลห้าระบบที่ไม่มีใคร เคยกู้คืนจาก ไม่ใช่วิศวกร การตรวจสอบภายหลัง, ลงนามโดย CEO, รักษาความลับของเขา ระบายสีข้อความแจ้งการผลิตเป็นสีแดง และมอบความทนทานของข้อมูลให้เจ้าของ เพราะจนถึงตอนนี้มันยังไม่มี รัศมีผลกระทบ: ล่มสิบแปดชั่วโมง, ข้อมูลหายไปหกชั่วโมง ประมาณห้าพันโปรเจกต์, ห้าพันคอมเมนต์

2:18 ผู้ใช้ใหม่เจ็ดร้อยคน, และคนห้าพันคนกำลังดูแถบความคืบหน้า Hacker News ให้เอกสารสด 1,162 คะแนน และอ้างคำพูด กลับไปที่พวกเขา: จากการสำรองข้อมูลห้ารายการ, ไม่มีเลย คำตัดสิน, การตรวจสอบภายหลัง: ship it, เกี่ยวกับการตอบสนอง พวกเขาจัดการเหตุการณ์ในที่สาธารณะ, โทษกระบวนการ, และเผยแพร่รายการแก้ไข พร้อมหมายเลขปัญหา การดำเนินการในวันจันทร์: กู้คืนข้อมูลสำรอง ถ้าคุณไม่เคยกู้คืนมัน คุณก็ไม่มีมัน

2:42 ส่งเหตุการณ์ที่คุณยังไม่ได้รับอนุญาตให้พูดถึงให้ฉัน ในความคิดเห็น หรือที่ the daily diff dot dev และนั่นคือความแตกต่างสำหรับวันนี้ ฉันชื่อ Niko จาก 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