𝗗𝟭 𝗥𝗲𝗮𝗱 𝗥𝗲𝗽𝗹𝗶𝗰𝗮𝘀 માં ૬ સેકન્ડનો લેગ હતો
ટોક્યોમાં રહેલું એક D1 read replica, ઉત્તર અમેરિકામાં થયેલા એક write કરતા 6.1 સેકન્ડ પાછળ રહી ગયું હતું.
મને આ વાત એક ટ્રેકર દ્વારા જાણવા મળી જે ખોટી ઇમ્પ્રેશન્સ (impressions) ને થ્રોટલ (throttle) કરી રહ્યું હતું. ડોક્યુમેન્ટેશનમાં 'eventual consistency' નો ઉલ્લેખ છે, પરંતુ તે તમને પ્લાનિંગ કરવા માટે કોઈ ચોક્કસ સમય આપતું નથી.
વાસ્તવિક આંકડા મેળવવા માટે મેં એક staleness probe બનાવ્યું. આ probe એક UUID અને epoch સાથે એક row લખે છે. જ્યાં સુધી તે row દેખાય નહીં ત્યાં સુધી તે replica ને poll કરે છે. ત્યારબાદ તે delay નો રેકોર્ડ રાખે છે.
એશિયામાં 200 probes ના પરિણામો:
- p50: 800ms
- p95: 3,400ms
- p99: 6,100ms
જો તમારું primary ઉત્તર અમેરિકામાં હોય અને તમારા યુઝર્સ એશિયામાં હોય, તો lag વધારે હોય છે.
મને schema error નો પણ સામનો કરવો પડ્યો. Primary પર એક migration ચાલ્યું. એક Worker રીસ્ટાર્ટ થયો. નવી table આવે તે પહેલાં જ પ્રથમ requests replica પર પહોંચી ગઈ. એરર મુજબ table અસ્તિત્વમાં નહોતું. Table ત્યાં જ હતું, પરંતુ replica પાછળ રહી ગયું હતું.
મેં lag ની આસપાસ routing કરીને આ સમસ્યાનો ઉકેલ લાવ્યો. હું તેની સામે લડતો નથી.
મારું design આ મુજબ છે:
- Writer row માં written_at epoch ઉમેરે છે.
- Writer response માં X-D1-Written-At header ઉમેરે છે.
- Reader તે header ની replica ના ડેટા સાથે સરખામણી કરે છે.
- જો replica ડેટા header કરતા જૂનો હોય, તો reader KV નો ઉપયોગ કરે છે.
KV તે જ રિજનમાં 500ms થી ઓછા સમયમાં ચાલે છે. તે દિવસના 10M reads સુધી મફત છે. આ રીતે critical flags માટે તાજો ડેટા મેળવવાનો એક સસ્તો રસ્તો મળે છે.
તમે KV નો ઉપયોગ માત્ર તે ટૂંકા સમય માટે જ કરો છો જ્યારે replica પાછળ હોય છે. એકવાર replica અપડેટ થઈ જાય પછી મોટાભાગના reads સામાન્ય રીતે D1 પર જ થાય છે.
મેં મારા વિગતવાર પોસ્ટમાં સંપૂર્ણ script અને migration pattern શેર કરી છે.