𝗗𝟭 𝗥𝗲𝗮𝗱 𝗥𝗲𝗽𝗹𝗶𝗰𝗮𝘀 𝗛𝗮𝗱 𝟲 𝗦𝗲𝗰𝗼𝗻𝗱𝘀 𝗼𝗳 𝗟𝗮𝗴

టోక్యోలోని ఒక D1 రీడ్ రెప్లికా, నార్త్ అమెరికాలో జరిగిన ఒక రైట్ (write) కంటే 6.1 సెకన్లు వెనుకబడి ఉంది.

తప్పుడు ఇంప్రెషన్స్‌ను (impressions) థ్రోటలింగ్ (throttling) చేస్తున్న ట్రాకర్‌ను చూసి నేను దీనిని తెలుసుకున్నాను. డాక్యుమెంటేషన్‌లో 'eventual consistency' గురించి పేర్కొన్నారు. కానీ మీరు ప్లాన్ చేసుకోవడానికి అవసరమైన నిర్దిష్ట సమయాన్ని అది ఇవ్వదు.

అసలు గణాంకాలను తెలుసుకోవడానికి నేను ఒక 'staleness probe'ను రూపొందించాను. ఈ ప్రోబ్ ఒక UUID మరియు epochతో ఒక రో (row)ను రాస్తుంది. ఆ రో కనిపించే వరకు ఇది రెప్లికాను పోల్ (poll) చేస్తూనే ఉంటుంది. ఆ తర్వాత అది ఆలస్యాన్ని (delay) రికార్డ్ చేస్తుంది.

ఆసియాలోని 200 ప్రోబ్స్ నుండి వచ్చిన ఫలితాలు:

మీ ప్రైమరీ (primary) నార్త్ అమెరికాలో ఉండి, మీ యూజర్లు ఆసియాలో ఉంటే, ఈ లాగ్ (lag) ఎక్కువగా ఉంటుంది.

నేను ఒక స్కీమా ఎర్రర్‌ను (schema error) కూడా ఎదుర్కొన్నాను. ప్రైమరీలో ఒక మైగ్రేషన్ (migration) రన్ అయ్యింది. ఒక Worker రీస్టార్ట్ అయ్యింది. కొత్త టేబుల్ అందుబాటులోకి రాకముందే మొదటి రిక్వెస్ట్‌లు రెప్లికాను చేరుకున్నాయి. టేబుల్ లేదని ఎర్రర్ వచ్చింది. టేబుల్ అక్కడ ఉంది, కానీ రెప్లికా వెనుకబడి ఉంది.

నేను లాగ్‌ను ఎదుర్కోవడం కంటే, దాని చుట్టూ రూటింగ్ (routing) చేయడం ద్వారా దీనిని పరిష్కరించాను. నేను దానితో పోరాడను.

నా డిజైన్ ఇక్కడ ఉంది:

  1. రైటర్ (writer) రోలో ఒక written_at epochను జోడిస్తుంది.
  2. రైటర్ రెస్పాన్స్‌కు ఒక X-D1-Written-At హెడర్‌ను జోడిస్తుంది.
  3. రీడర్ ఆ హెడర్‌ను రెప్లికా నుండి వచ్చిన డేటాతో పోల్చి చూస్తుంది.
  4. ఒకవేళ రెప్లికా డేటా హెడర్ కంటే పాతది అయితే, రీడర్ KVకి మారుతుంది (falls back to KV).

అదే రీజియన్‌లో KV 500ms లోపు రన్ అవుతుంది. ఇది రోజుకు 10M రీడ్స్ వరకు ఉచితం. ఇది క్రిటికల్ ఫ్లాగ్స్ (critical flags) కోసం తాజా డేటాను పొందడానికి ఒక చౌకైన మార్గాన్ని అందిస్తుంది.

రెప్లికా వెనుకబడిన ఆ చిన్న సమయంలో మాత్రమే మీరు KVని ఉపయోగిస్తారు. రెప్లికా అప్‌డేట్ అయిన తర్వాత, చాలా రీడ్స్ సాధారణంగా D1ని చేరుకుంటాయి.

నా వివరణాత్మక పోస్ట్‌లో పూర్తి స్క్రిప్ట్ మరియు మైగ్రేషన్ ప్యాటర్న్‌ను షేర్ చేశాను.

మూలం: https://dev.to/riversea/d1-read-replicas-returned-stale-data-for-6-seconds-heres-what-i-measured-and-how-i-designed-mme