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

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

• 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 รวมความรับผิดชอบ

แหล่งที่มา

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