𝗗𝟭 𝗥𝗲𝗮𝗱 𝗥𝗲𝗽𝗹𝗶𝗰𝗮𝘀 𝗺𝗲𝗶𝗻 𝟲 𝘀𝗲𝗰𝗼𝗻𝗱𝘀 𝗸𝗮 𝗹𝗮𝗴 𝘁𝗵𝗮

ٹوکیو (Tokyo) میں موجود ایک D1 read replica، شمالی امریکہ (North America) میں ہونے والی ایک write سے 6.1 سیکنڈ پیچھے رہ گیا۔

مجھے اس کا علم ایک ٹریکر سے ہوا جو غلط امپریشنز (impressions) کو تھروٹل (throttle) کر رہا تھا۔ ڈاکومنٹیشن میں eventual consistency کا ذکر ہے۔ یہ آپ کو منصوبہ بندی کے لیے کوئی مخصوص وقت نہیں بتاتی۔

میں نے اصل اعداد و شمار معلوم کرنے کے لیے ایک staleness probe بنایا۔ یہ probe ایک UUID اور epoch کے ساتھ ایک row لکھتا ہے۔ یہ تب تک replica کو پول (poll) کرتا رہتا ہے جب تک وہ row ظاہر نہ ہو جائے۔ پھر یہ تاخیر (delay) کو ریکارڈ کرتا ہے۔

ایشیا (Asia) میں 200 probes کے نتائج:

اگر آپ کا primary شمالی امریکہ میں ہے اور آپ کے صارفین ایشیا میں ہیں، تو لیگ (lag) زیادہ ہوتا ہے۔

مجھے ایک schema error کا بھی سامنا کرنا پڑا۔ primary پر ایک migration رن ہوئی۔ ایک Worker ری اسٹارٹ ہوا۔ پہلی درخواستیں (requests) نئی ٹیبل کے پہنچنے سے پہلے ہی replica پر پہنچ گئیں۔ ایرر (error) یہ تھا کہ ٹیبل موجود نہیں ہے۔ ٹیبل وہاں موجود تھا، لیکن replica پیچھے رہ گیا تھا۔

میں نے اسے لیگ کے گرد راؤٹنگ (routing) کر کے حل کیا۔ میں اس سے لڑتا نہیں ہوں۔

میرا ڈیزائن یہ ہے:

  1. Writer row میں ایک written_at epoch شامل کرتا ہے۔
  2. Writer ریسپانس میں ایک X-D1-Written-At ہیڈر شامل کرتا ہے۔
  3. Reader اس ہیڈر کا موازنہ replica کے ڈیٹا سے کرتا ہے۔
  4. اگر replica کا ڈیٹا ہیڈر سے پرانا ہے، تو reader KV پر فال بیک (fallback) کر جاتا ہے۔

اسی ریجن (region) میں KV 500ms سے کم وقت میں چلتا ہے۔ یہ روزانہ 10M ریڈز تک مفت ہے۔ یہ اہم فلیگز (flags) کے لیے تازہ ڈیٹا حاصل کرنے کا ایک سستا طریقہ فراہم کرتا ہے۔

آپ KV کو صرف اس مختصر وقت کے دوران استعمال کرتے ہیں جب replica پیچھے ہو۔ ایک بار جب replica برابر ہو جاتا ہے، تو زیادہ تر ریڈز معمول کے مطابق D1 پر ہی جاتی ہیں۔

میں نے اپنی تفصیلی پوسٹ میں مکمل اسکرپٹ اور migration pattern شیئر کیا ہے۔

ماخذ (Source): https://dev.to/riversea/d1-read-replicas-returned-stale-data-for-6-seconds-heres-what-i-measured-and-how-i-designed-mme