+− THE DAILY DIFFdev & AI news
SHIP IT

ایک انجینئر نے گٹ لیب کا پروڈکشن ڈیٹا بیس ڈیلیٹ کر دیا۔ 300 گیگا بائٹس۔

31 جنوری 2017، 23:27 UTC: ایک گٹ لیب انجینئر نے، ایک لمبی رات کے اختتام پر ایک خراب ریپلیکا سے لڑتے ہوئے، db2 کی بجائے db1 پر PostgreSQL ڈیٹا ڈائریکٹری کو ہٹا دیا۔

31 جنوری 2017، 23:27 UTC: ایک گٹ لیب انجینئر نے، ایک لمبی رات کے اختتام پر ایک خراب ریپلیکا سے لڑتے ہوئے، db2 کی بجائے db1 پر PostgreSQL ڈیٹا ڈائریکٹری کو ہٹا دیا۔ db1 پرائمری ہے۔ GitLab.com کے ڈیٹا بیس کا تقریباً 300 GB ایک یا دو سیکنڈ میں غائب ہو گیا، اور پانچ بیک اپ اور نقل کے میکانزم میں سے، کوئی بھی کام نہیں کر رہا تھا۔ پوسٹ مارٹم: سپیم سپائیک سے لے کر غلط میزبان نام تک کی ٹائم لائن، pg_basebackup کیوں پھنسا ہوا لگتا تھا، pg_dump کیوں خاموشی سے ناکام ہو رہا تھا (9.6 ڈیٹا بیس پر 9.2 بائنریز، DMARC کی وجہ سے باؤنس ہونے والے ناکامی کے ای میلز)، یوٹیوب پر براہ راست نشر ہونے والے 6 گھنٹے پرانے اسٹیجنگ اسنیپ شاٹ سے 18 گھنٹے کی بحالی، اور اصل میں کون قصوروار ہے۔ ردعمل پر فیصلہ: SHIP IT۔

تحریری ایڈیشن پڑھیں (انگریزی) ↗

اس ویڈیو میں کیا شامل ہے

  • 31 جنوری 2017: پرائمری کے ڈیٹا ڈائریکٹری پر rm -Rvf؛ ~300 GB ہٹا دیا گیا، 4.5 GB باقی۔
  • 5 میں سے 5 بیک اپ ناکام: خالی S3 بالٹی (pg_dump ورژن کی بے ترتیبی)، DB پر کوئی Azure اسنیپ شاٹس نہیں، ریپلیکا صاف، ویب ہکس کے بغیر روزانہ LVM کاپی۔
  • 1 فروری، 18:00 UTC: GitLab.com 6 گھنٹے پرانے دستی اسنیپ شاٹ سے واپس؛ لائیو دستاویز، لائیو سٹریم، فکس لسٹ کے ساتھ بے قصور پوسٹ مارٹم۔

ترجمہ شدہ ٹرانسکرپٹ

اصل انگریزی بیان سے ترجمہ کیا گیا۔ دستیاب آڈیو اور کیپشنز یوٹیوب کے زیر انتظام ہیں۔

0:00 گٹ لیب کا ایک انجینئر غلط ڈیٹا بیس سرور پر rm -rf چلاتا ہے، اور گٹ لیب ڈاٹ کام کے تین سو گیگا بائٹس ایک یا دو سیکنڈ میں غائب ہو جاتے ہیں، تقریباً اتنا ہی وقت لگتا ہے ایک میزبان نام پڑھنے میں۔ 31 جنوری 2017، رات 11:27 بجے UTC۔ گٹ لیب ٹویٹ کرتا ہے کہ اس نے غلطی سے پروڈکشن ڈیٹا حذف کر دیا، اپنے واقعے کے نوٹس انٹرنیٹ پر کھولتا ہے، اور یوٹیوب پر بحالی کو سٹریم کرتا ہے، پلیٹ فارم پر نمبر دو لائیو سٹریم۔ اگلے دن، تحریری طور پر: پانچ بیک اپ تکنیکوں میں سے،

0:25 کوئی بھی قابل اعتماد طریقے سے کام نہیں کر رہا ہے۔ یہ کیسے ہوتا ہے، یہ کیوں ممکن ہے، اور اصل میں کون قصوروار ہے۔ یہ The Daily Diff ہے، پوسٹ مارٹم۔ شام 5:20: ایک انجینئر پروڈکشن کا اسنیپ شاٹ لیتا ہے اسٹیجنگ میں ایک لوڈ بیلنسر کی جانچ کرنے کے لیے۔ شام 7 بجے: سپیم ڈیٹا بیس پر حملہ کرتا ہے، اس کے علاوہ ایک جاب ایک گٹ لیب ملازم کو سختی سے حذف کر رہا ہے جس کی ٹرول نے بدسلوکی کی اطلاع دی تھی۔ رات 11 بجے: ریپلیکا اتنا پیچھے رہ جاتا ہے کہ پرائمری پہلے ہی خارج کر چکا ہے

0:48 وہ لاگ جس کی اسے ضرورت ہے؛ واحد حل یہ ہے کہ ریپلیکا کو صاف کیا جائے اور پرائمری کو کاپی کیا جائے دوبارہ۔ pg_basebackup بغیر کسی آؤٹ پٹ کے پھنسا رہتا ہے۔ یہ دراصل خاموشی سے پرائمری کا انتظار کر رہا ہے؛ کوئی نہیں جانتا کہ، اور رن بک نہیں کہتی۔ انجینئر، جو گیارہ بجے سائن آف کرنا چاہتا تھا، فیصلہ کرتا ہے کہ خالی ڈیٹا ڈائریکٹری مسئلہ ہے اور اسے ہٹا دیتا ہے۔ db1 پر۔ پرائمری پر۔ وہ ایک یا دو سیکنڈ بعد نوٹس کرتا ہے؛ تقریباً تین سو گیگا بائٹس میں سے،

1:11 4.5 باقی ہیں۔ بیک اپ۔ ایک: روزانہ S3 پر pg_dump۔ بالٹی خالی ہے۔ کرون جاب ایک ایپ سرور پر چلتا ہے جس میں کوئی ڈیٹا بیس نہیں ہوتا، لہذا پیکج اٹھاتا ہے 9.6 ڈیٹا بیس کے لیے PostgreSQL 9.2 بائنریز، ناکام ہوتا ہے، اور ای میل کرتا ہے ناکامی، جو DMARC کی کمی کی وجہ سے باؤنس ہوتی ہے۔ دو: Azure ڈسک اسنیپ شاٹس، فائل سرورز کے لیے فعال، ڈیٹا بیس کے لیے نہیں۔

1:32 تین: ریپلیکا، ایک گھنٹہ پہلے جان بوجھ کر صاف کر دیا گیا۔ چار: روزانہ کا اسنیپ شاٹ، 24 گھنٹے پرانا، ہر ویب ہک اسٹیجنگ سنک کے ذریعے ہٹا دیا گیا پانچ: 5:20 کا دستی اسنیپ شاٹ، ایک غیر متعلقہ ٹیسٹ کے لیے۔ وہ جیتتا ہے۔ بحال کرنے کا مطلب ہے اسٹیجنگ ڈسک کو Azure کے سستے اسٹوریج پر ساٹھ میگا بٹ فی سیکنڈ کی رفتار سے پروڈکشن میں واپس کاپی کرنا: اٹھارہ گھنٹے۔ Azure کے سستے اسٹوریج پر ساٹھ میگا بٹ فی سیکنڈ کی رفتار سے پروڈکشن میں واپس کاپی کرنا: اٹھارہ گھنٹے۔ GitLab ڈاٹ کام 1 فروری کو شام چھ بجے واپس آتا ہے۔ UTC، چھ گھنٹے کا ڈیٹا پرانا۔

1:58 git blame: دو میزبان نام ایک حرف کے فرق پر، اور پانچ بیک اپ سسٹمز جن سے کسی نے کبھی بحال نہیں کیا ہے۔ انجینئر نہیں۔ پوسٹ مارٹم، CEO کے دستخط شدہ، اسے گمنام رکھتا ہے، پروڈکشن پرامپٹ کو سرخ رنگ دیتا ہے، اور ڈیٹا کی پائیداری کو ایک مالک دیتا ہے، کیونکہ اب تک اس کا کوئی نہیں تھا۔ دھماکے کا دائرہ: اٹھارہ گھنٹے بند، چھ گھنٹے کا ڈیٹا غائب، تقریباً پانچ ہزار پروجیکٹس، پانچ ہزار تبصرے،

2:18 سات سو نئے صارفین، اور پانچ ہزار لوگ ایک پیشرفت بار دیکھ رہے ہیں۔ Hacker News لائیو دستاویز کو 1,162 پوائنٹس دیتا ہے اور ایک لائن واپس ان کے حوالے کرتا ہے: پانچ بیک اپ میں سے، کوئی نہیں۔ فیصلہ، پوسٹ مارٹم: SHIP IT، ردعمل پر۔ وہ واقعے کو عوامی طور پر چلاتے ہیں، عمل کو قصوروار ٹھہراتے ہیں، اور ایشو نمبرز کے ساتھ فکس لسٹ شائع کرتے ہیں۔ ایشو نمبرز کے ساتھ فکس لسٹ شائع کرتے ہیں۔ پیر کا عمل: ایک بیک اپ بحال کریں۔ اگر آپ نے اسے کبھی بحال نہیں کیا، تو آپ کے پاس ایک نہیں ہے۔

2:42 مجھے وہ واقعہ بھیجیں جس کے بارے میں آپ کو ابھی تک بات کرنے کی اجازت نہیں ہے، تبصروں میں، یا daily diff dot dev پر۔ اور آج کے لیے یہ فرق ہے۔ میں Axrisi سے نیکو ہوں۔ Merge responsibly۔

ذرائع

  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

متعلقہ ویڈیوز

postmortem · ur · 25 ستمبر، 2026

ایک ملی سیکنڈ کے بگ نے برطانیہ کی فضائی ٹریفک کو روک دیا۔ چھ گھنٹے۔

منگل 8 ستمبر کو صبح 10:00 بجے، NATS کے نیشنل ایئر اسپیس سسٹم (NAS) کے اندر ایک معمول کی سکواک کوڈ کی درخواست کو ایک اعلی ترجیحی پیغام نے روک دیا جبکہ یہ ایک قدر کو اپ ڈیٹ کرنے کے آدھے راستے میں تھا۔ ن

3:06 ↗
postmortem · ur · 22 ستمبر، 2026

ایک ریبوٹ نے ٹیل اسٹرا کو 2006 میں بھیج دیا: 90 لاکھ فون متاثر ہوئے۔

میلبورن میں ایک انجینئر نے صبح 2:50 پر ایک ٹائمنگ چیسس کو دوبارہ آن کیا، اور ناشتے تک آسٹریلیا کا سب سے بڑا موبائل نیٹ ورک اس بات پر متفق ہو گیا کہ یہ نومبر 2006 ہے۔ 8 جولائی 2026: ٹیل اسٹرا کے NTP چی

3:15 ↗