آپ کا ڈیلٹا فیڈ دیر سے آنے والے کمٹ چھوڑ دیتا ہے: قابلِ بھروسہ کرسر بنائیں

یہ وہ ناکامی ہے جو میں نے دو بار دیکھی، دو مختلف انجنوں میں۔ ایک برآمد 10:00 بجے چلتی ہے اور سب سے بلند دیکھا گیا آخری ترمیم کا ٹائم اسٹیمپ ریکارڈ کرتی ہے۔ ایک ٹرانزیکشن جو 09:58 بجے شروع ہوئی اب بھی کھلی ہے، 10:03 بجے کمٹ ہوتی ہے اور اپنے آغاز کے لمحے کا ٹائم اسٹیمپ رکھتی ہے۔ اگلی برآمد صرف 10:00 سے نئی قطاریں مانگتی ہے اور اسے کبھی نہیں دیکھتی۔ منتقلی کا حجم بہترین تھا اور ڈیٹا غلط تھا۔

اس برآمد کا پیچھا کریں جس نے ایک قطار گنوائی

واقعات کی ترتیب کا پیچھا کریں، SQL کا نہیں۔ ایپلیکیشن قطار کی تبدیلی کا وقت ٹرانزیکشن شروع ہونے پر لکھتی ہے، کمٹ ہونے پر نہیں۔ برآمد کنندہ دیوار کی گھڑی کا واٹر مارک پڑھتا ہے جب وہ ٹرانزیکشن اب بھی کھلی ہے۔ پھر ٹرانزیکشن محفوظ واٹر مارک سے پرانے تبدیلی کے وقت کے ساتھ کمٹ ہوتی ہے۔ صارف کا اگلا بیچ واٹر مارک کے بعد شروع ہوتا ہے، اس لیے قطار کرسر کے پیچھے رہ جاتی ہے اور دوبارہ کبھی منتخب نہیں ہوگی۔

کوئی چیز خرابی درج نہیں کرتی، کیونکہ کوئی چیز ناکام نہیں ہوئی۔ یہی اس قسم کے بگ کو مہنگا بناتا ہے: ڈیلٹا فیڈ تیز ہے، قطاروں کی گنتی معقول لگتی ہے، اور گمشدہ قطار ہفتوں بعد ایک مصالحتی ٹکٹ کے طور پر سامنے آتی ہے جسے کوئی دوبارہ پیدا نہیں کر سکتا۔

ترتیبی نمبروں میں دوسری وجہ سے وہی شکل کا نقص ہے۔ یکساں ID بتاتا ہے کہ اقدار کس ترتیب سے تقسیم ہوئیں، یہ نہیں کہ ٹرانزیکشنز کس ترتیب سے کمٹ ہوئیں۔ کم نمبر لینے والی ٹرانزیکشن زیادہ نمبر لینے والی کے بعد کمٹ ہو سکتی ہے، اس لیے تقسیم کی ترتیب پر مبنی کرسر بھی سوراخ چھوڑ سکتا ہے۔

پانچ وعدے جو فیڈ کو دینے ہوں گے

ٹرانسپورٹ منتخب کرنے سے پہلے ماخذ نظام سے پانچ شقوں کا معاہدہ مانگیں۔ اگر کوئی شق غائب ہو تو آپ کے پاس تبدیلی فیڈ نہیں، ایک اندازہ ہے۔

• کوریج: اندراج، تحدید اور حذف، ہر ایک کے ساتھ لاگو کرنے کے لیے ضروری مستحکم کلید۔
• حد: کرسر کی قدر کا مطلب کیا اور مستقل بیچ میں کیا ہوتا ہے۔
• مطابقت: غیر مطابق ماخذ حالتوں کو ملائے بغیر متعلقہ جدولیں کیسے پڑھی جاتی ہیں۔
• برقراری: منقطع صارف اپنی محفوظ پوزیشن سے کتنی دیر دوبارہ شروع کر سکتا ہے۔
• دوبارہ آغاز: جب وہ پوزیشن مزید درست نہ ہو تو معاون مکمل اسنیپ شاٹ۔

معاون طریقہ کار پانچوں کو پورا کر سکتا ہے۔ SQL Server کی تبدیلیوں کی نگرانی کی دستاویز ایک ٹھوس شائع شدہ مثال ہے: یہ کم از کم درست ورژن متعین کرتی ہے، تبدیلیوں کے ساتھ حذف بھی درج کرتی ہے، اور ایسی اسنیپ شاٹ ٹرانزیکشن بیان کرتی ہے جو توثیق، ورژن کی گرفت اور متعلقہ تبدیلی کے سوالات کو محیط ہو۔ یہ اس بات کی مثال ہے کہ ماخذ سے کیا مانگنا چاہیے، وہ نحو نہیں جو کسی دوسرے انجن میں چپکایا جائے۔

چیک پوائنٹ کو پائپ لائن کا حصہ سمجھ کر ڈیزائن کریں

صارف کی محفوظ پوزیشن ہی اصل اسٹیٹ مشین ہے، اس لیے اسے اسی طرح لکھیں۔ کرسر صرف اس ورک فلو سے آگے بڑھ سکتا ہے جس نے بیچ پہلے ہی لاگو کر دیا اور ہدف ٹرانزیکشن کمٹ کر دی۔

cursor  = durable_checkpoint()          # last fully applied position
batch   = extract(cursor, upper_bound)  # one consistent batch
apply(batch)                            # idempotent at the target
commit()
checkpoint(batch.upper_bound)           # only now

اگر ترسیل آدھے راستے میں ناکام ہو تو نئی ماخذ پوزیشن ایجاد کرنے کے بجائے وہی بیچ ملا دیں۔ زیادہ تازہ بالائی حد کے ساتھ دوبارہ استخراج ہی وہ راستہ ہے جس سے جزوی اطلاق مستقل خلا بنتا ہے۔ آئینے کا قاعدہ دوسری طرف بھی لاگو ہے: ہدف پر idempotent اطلاق نقول روکتا ہے اور ایسی تبدیلی کے لیے کچھ نہیں کرتا جسے استخراج نے کبھی نہیں دیکھا۔

حذف کے لیے ریکارڈ درکار ہیں، نتائج نہیں

اب بھی موجود قطاروں کا موازنہ صارف کو یہ نہیں بتا سکتا کہ کون سی کلیدیں غائب ہوئیں۔ جو ماخذ کبھی حذف درج نہیں کرتا وہ آپ کو دو نامکمل اختیار دیتا ہے: موازنے کے لیے کافی طویل کلید کی تاریخ رکھنا، یا شیڈول کے مطابق واضح مکمل مصالحت چلانا۔ دونوں لاگت والے ڈیزائن فیصلے ہیں، اور کوئی بھی اس وقت تک موجود نہیں جب تک کسی کی ملکیت نہ ہو۔

برقراری بھی اسی قسم کا فیصلہ ہے۔ ہر معاون تبدیلی فیڈ کی ایک ونڈو ہوتی ہے؛ اسے معاہدے میں بیان کریں اور خبردار کریں جب صارف کا چیک پوائنٹ اس کے قریب آئے۔ دو ہفتے کی رکاوٹ کے بعد جاگنے والے صارف کو خاموشی سے جزوی بیچ ملنے کے بجائے واضح خرابی "دوبارہ آغاز درکار ہے" پڑھنی چاہیے۔

پھر ناپیں کہ ڈیلٹا کارآمد تھا یا نہیں

ہر کلید اور ہیش کا موازنہ کرنے کی طرف لوٹنا کبھی کبھی درست ہوتا ہے، اور اس کی لاگت جاننا مناسب ہے۔ آپ اب بھی ہر قطار کی معلومات منتقل کرتے ہیں، ہیش جدولوں میں مستقل اسنیپ شاٹ نہیں دیتے، اور ہیش اسکیم نمائندگی اور تصادم کے بارے میں اپنے سوالات لاتی ہے۔ قابلِ تصدیق حد کے ساتھ کم بائٹس ہی ہدف ہیں؛ کم بائٹس جو کمٹ شدہ تبدیلی کو خاموشی سے گرا دیں وہ ڈیلٹا ہی نہیں۔

آخری ترمیم کا کالم ایک اشارہ ہے۔ جو کرسر دیر سے آنے والے کمٹ، حذف اور طویل رکاوٹ سے گزر جائے وہ معاہدہ ہے۔