# ວິສະວະກອນລຶບຖານຂໍ້ມູນການຜະລິດຂອງ GitLab. 300 ກິກກະໄບ.

Published: 2026-09-10

ວັນທີ 31 ມັງກອນ 2017, ເວລາ 23:27 UTC: ວິສະວະກອນຂອງ GitLab, ໃນຂະນະທີ່ກຳລັງແກ້ໄຂບັນຫາແບບຈຳລອງທີ່ເສຍຫາຍໃນຕອນທ້າຍຂອງຄືນ, ໄດ້ລຶບໄດເລກະທໍລີຂໍ້ມູນ PostgreSQL ໃນ db1 ແທນທີ່ຈະເປັນ db2. db1 ແມ່ນຖານຂໍ້ມູນຫຼັກ. ປະມານ 300 GB ຂອງຖານຂໍ້ມູນ GitLab.com ຫາຍໄປໃນໜຶ່ງ ຫຼື ສອງວິນາທີ, ແລະໃນບັນດາກົນໄກສຳຮອງ ແລະ ການຈຳລອງທັງຫ້າ, ບໍ່ມີອັນໃດເຮັດວຽກ. ການສືບສວນຫຼັງເກີດເຫດ: ລຳດັບເຫດການຕັ້ງແຕ່ການເພີ່ມຂຶ້ນຂອງສະແປມໄປຫາຊື່ໂຮດທີ່ຜິດພາດ, ເປັນຫຍັງ pg\_basebackup ຈຶ່ງຄ້າງ, ເປັນຫຍັງ pg\_dump ຈຶ່ງລົ້ມເຫຼວຢ່າງງຽບໆ (9.2 binaries ໃນຖານຂໍ້ມູນ 9.6, ອີເມວແຈ້ງເຕືອນຄວາມລົ້ມເຫຼວຖືກຕີກັບຄືນໂດຍ DMARC), ການກູ້ຄືນ 18 ຊົ່ວໂມງຈາກພາບຖ່າຍ staging ອາຍຸ 6 ຊົ່ວໂມງທີ່ຖ່າຍທອດສົດໃນ YouTube, ແລະໃຜທີ່ຄວນຖືກຕຳໜິແທ້ໆ. ຄຳຕັດສິນຕໍ່ການຕອບສະໜອງ: SHIP IT.

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

## ສິ່ງທີ່ວິດີໂອນີ້ກວມເອົາ

- ວັນທີ 31 ມັງກອນ 2017: rm -Rvf ຢູ່ໃນໄດເລກະທໍລີຂໍ້ມູນຫຼັກ; ປະມານ 300 GB ຖືກລຶບ, ເຫຼືອ 4.5 GB
- 5 ໃນ 5 ການສຳຮອງຂໍ້ມູນລົ້ມເຫຼວ: S3 bucket ເປົ່າຫວ່າງ (pg\_dump ຮຸ່ນບໍ່ກົງກັນ), ບໍ່ມີ Azure snapshots ໃນ DB, replica ຖືກລຶບ, daily LVM copy ໂດຍບໍ່ມີ webhooks
- ວັນທີ 1 ກຸມພາ, 18:00 UTC: GitLab.com ກັບຄືນມາຈາກ manual snapshot ອາຍຸ 6 ຊົ່ວໂມງ; ເອກະສານສົດ, ການຖ່າຍທອດສົດ, ການສືບສວນຫຼັງເກີດເຫດແບບບໍ່ມີການຕຳໜິພ້ອມບັນຊີລາຍຊື່ການແກ້ໄຂ

## ບົດບັນທຶກທີ່ແປແລ້ວ

ແປຈາກຄຳບັນຍາຍຕົ້ນສະບັບພາສາອັງກິດ. ສຽງ ແລະ ຄຳບັນຍາຍທີ່ມີໃຫ້ແມ່ນຄວບຄຸມໂດຍ YouTube.

0:00 ວິສະວະກອນຢູ່ GitLab ໃຊ້ຄຳສັ່ງ rm -rf ໃສ່ເຊີບເວີຖານຂໍ້ມູນຜິດ, ແລະສາມຮ້ອຍກິກກະໄບຂອງ GitLab dot com ຫາຍໄປໃນໜຶ່ງ ຫຼື ສອງວິນາທີ, ປະມານໄລຍະເວລາທີ່ໃຊ້ໃນການອ່ານຊື່ໂຮດ. ວັນທີ 31 ມັງກອນ 2017, ເວລາ 11:27 ຕອນແລງ UTC. GitLab ໄດ້ tweet ວ່າຕົນເອງໄດ້ລຶບຂໍ້ມູນການຜະລິດໂດຍບັງເອີນ, ເປີດບັນທຶກເຫດການໃຫ້ສາທາລະນະ, ແລະຖ່າຍທອດການກູ້ຄືນໃນ YouTube, ເປັນການຖ່າຍທອດສົດອັນດັບສອງໃນເວທີນັ້ນ. ມື້ຕໍ່ມາ, ໃນລາຍລັກອັກສອນ: ຈາກຫ້າເຕັກນິກການສຳຮອງຂໍ້ມູນ,

0:25 ບໍ່ມີອັນໃດເຮັດວຽກໄດ້ຢ່າງໜ້າເຊື່ອຖື. ມັນເກີດຂຶ້ນແນວໃດ, ເປັນຫຍັງມັນຈຶ່ງເປັນໄປໄດ້, ແລະໃຜທີ່ຄວນຖືກຕຳໜິແທ້ໆ. ນີ້ແມ່ນ The Daily Diff, ການສືບສວນຫຼັງເກີດເຫດ. 5:20 ຕອນແລງ: ວິສະວະກອນໄດ້ສ້າງ snapshot ຂອງການຜະລິດ ເພື່ອທົດສອບ load balancer ໃນ staging. 7 ໂມງແລງ: ສະແປມໂຈມຕີຖານຂໍ້ມູນ, ບວກກັບວຽກທີ່ລຶບພະນັກງານ GitLab ອອກຢ່າງຖາວອນ ຫຼັງຈາກ ຜູ້ໃຊ້ຄົນໜຶ່ງລາຍງານການລ່ວງລະເມີດ. 11 ໂມງແລງ: replica ລ້າຫຼັງຈົນວ່າ primary ໄດ້ລຶບ

0:48 log ທີ່ມັນຕ້ອງການໄປແລ້ວ; ວິທີແກ້ໄຂດຽວຄືການລຶບ replica ແລະຄັດລອກ primary ອີກຄັ້ງ. pg\_basebackup ຄ້າງໂດຍບໍ່ມີຜົນອອກມາ. ມັນກຳລັງລໍຖ້າ, ຢ່າງງຽບໆ, ສໍາລັບ primary; ບໍ່ມີໃຜຮູ້ເລື່ອງນັ້ນ, ແລະ runbook ກໍບໍ່ໄດ້ບອກໄວ້. ວິສະວະກອນ, ຜູ້ທີ່ຕັ້ງໃຈຈະເຊັນອອກໃນຕອນ 11 ໂມງ, ຕັດສິນໃຈວ່າໄດເລກະທໍລີຂໍ້ມູນທີ່ຫວ່າງເປົ່າ ແມ່ນບັນຫາ ແລະລຶບມັນອອກ. ຢູ່ໃນ db1. ຖານຂໍ້ມູນຫຼັກ. ລາວສັງເກດເຫັນໃນອີກໜຶ່ງ ຫຼື ສອງວິນາທີຕໍ່ມາ; ຈາກປະມານສາມຮ້ອຍກິກກະໄບ,

1:11 ເຫຼືອ 4.5. ການສຳຮອງຂໍ້ມູນ. ໜຶ່ງ: pg\_dump ໄປ S3, ປະຈຳວັນ. bucket ແມ່ນເປົ່າຫວ່າງ. cron job ເຮັດວຽກຢູ່ເຊີບເວີແອັບພລິເຄຊັນທີ່ບໍ່ມີຖານຂໍ້ມູນ, ດັ່ງນັ້ນແພັກເກດຈຶ່ງເລືອກ PostgreSQL 9.2 binaries ສໍາລັບຖານຂໍ້ມູນ 9.6, ລົ້ມເຫຼວ, ແລະສົ່ງອີເມວ ແຈ້ງເຕືອນຄວາມລົ້ມເຫຼວ, ເຊິ່ງຖືກຕີກັບຄືນຍ້ອນຂາດ DMARC. ສອງ: Azure disk snapshots, ເປີດໃຊ້ງານສໍາລັບ file servers, ບໍ່ແມ່ນຖານຂໍ້ມູນ.

1:32 ສາມ: replica, ຖືກລຶບໂດຍເຈດຕະນາເມື່ອໜຶ່ງຊົ່ວໂມງກ່ອນ. ສີ່: daily snapshot, ອາຍຸ 24 ຊົ່ວໂມງ, ທຸກ webhook ຖືກລຶບອອກໂດຍ staging sync. ຫ້າ: manual snapshot ຈາກ 5:20, ສໍາລັບການທົດສອບທີ່ບໍ່ກ່ຽວຂ້ອງ. ອັນນັ້ນຊະນະ. ການກູ້ຄືນໝາຍເຖິງການຄັດລອກ staging disk ກັບຄືນໄປຫາ production ຜ່ານ Azure's cheap storage ທີ່ຄວາມໄວຫົກສິບເມກາບິດຕໍ່ວິນາທີ: ສິບແປດຊົ່ວໂມງ. GitLab dot com ກັບມາໃນວັນທີ 1 ກຸມພາ ເວລາຫົກໂມງແລງ UTC, ຂໍ້ມູນເກົ່າລົງຫົກຊົ່ວໂມງ.

1:58 git blame: ສອງຊື່ໂຮດທີ່ແຕກຕ່າງກັນພຽງໜຶ່ງຕົວອັກສອນ, ແລະລະບົບສຳຮອງຫ້າລະບົບທີ່ບໍ່ມີໃຜ ເຄີຍກູ້ຄືນຈາກມັນ. ບໍ່ແມ່ນວິສະວະກອນ. ການສືບສວນຫຼັງເກີດເຫດ, ເຊັນໂດຍ CEO, ຮັກສາຕົວຕົນຂອງລາວໄວ້ເປັນຄວາມລັບ, ໃສ່ສີແດງໃຫ້ກັບ production prompt, ແລະມອບເຈົ້າຂອງໃຫ້ກັບຄວາມທົນທານຂອງຂໍ້ມູນ, ເພາະຈົນເຖິງຕອນນີ້ມັນບໍ່ມີ. Blast radius: ລົງ 18 ຊົ່ວໂມງ, ຂໍ້ມູນຫາຍໄປ 6 ຊົ່ວໂມງ, ປະມານຫ້າພັນໂຄງການ, ຫ້າພັນຄອມເມັ້ນ,

2:18 ຜູ້ໃຊ້ໃໝ່ເຈັດຮ້ອຍຄົນ, ແລະຫ້າພັນຄົນກຳລັງເບິ່ງ progress bar. Hacker News ໃຫ້ 1,162 ຄະແນນແກ່ເອກະສານສົດ ແລະອ້າງອີງໜຶ່ງ ປະໂຫຍກຄືນໄປຫາພວກເຂົາ: ຈາກຫ້າການສຳຮອງຂໍ້ມູນ, ບໍ່ມີອັນໃດ. ຄຳຕັດສິນ, ການສືບສວນຫຼັງເກີດເຫດ: SHIP IT, ກ່ຽວກັບການຕອບສະໜອງ. ພວກເຂົາໄດ້ດໍາເນີນເຫດການຕໍ່ສາທາລະນະ, ຕໍານິຂະບວນການ, ແລະເຜີຍແຜ່ລາຍຊື່ການແກ້ໄຂ ພ້ອມດ້ວຍໝາຍເລກບັນຫາ. ການກະທໍາວັນຈັນ: ກູ້ຄືນຂໍ້ມູນສຳຮອງ. ຖ້າເຈົ້າບໍ່ເຄີຍກູ້ຄືນມັນ, ເຈົ້າກໍບໍ່ມີມັນ.

2:42 ສົ່ງເຫດການທີ່ເຈົ້າຍັງບໍ່ໄດ້ຮັບອະນຸຍາດໃຫ້ເວົ້າເຖິງໃຫ້ຂ້ອຍ, ໃນຄອມເມັ້ນ, ຫຼືທີ່ the daily diff dot dev. ແລະນັ້ນຄື diff ສໍາລັບມື້ນີ້. ຂ້ອຍແມ່ນ Niko ຈາກ Axrisi. Merge ຢ່າງມີຄວາມຮັບຜິດຊອບ.

## ແຫຼ່ງຂໍ້ມູນ

- [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