𝗗𝟭 𝗥𝗲𝗮𝗱 𝗥𝗲𝗽𝗹𝗶𝗰𝗮𝘀 𝗛𝗮𝗱 𝟲 𝗦𝗲𝗰𝗼𝗻𝗱𝘀 𝗼𝗳 𝗟𝗮𝗴
ടോക്കിയോയിലുള്ള ഒരു D1 റീഡ് റെപ്ലിക്ക (read replica), നോർത്ത് അമേരിക്കയിലെ ഒരു റൈറ്റിന് (write) പിന്നിലായി 6.1 സെക്കൻഡ് വൈകിപ്പോയി.
തെറ്റായ ഇംപ്രഷനുകൾ തടയുന്ന (throttling) ഒരു ട്രാക്കറിൽ നിന്നാണ് ഞാൻ ഇത് മനസ്സിലാക്കിയത്. ഡോക്യുമെന്റേഷനിൽ 'eventual consistency' എന്ന് പരാമർശിക്കുന്നുണ്ടെങ്കിലും, പ്ലാൻ ചെയ്യാൻ ആവശ്യമായ കൃത്യമായ ഒരു സമയം അത് നൽകുന്നില്ല.
യഥാർത്ഥ കണക്കുകൾ കണ്ടെത്താനായി ഞാൻ ഒരു staleness probe നിർമ്മിച്ചു. ഈ പ്രോബ് ഒരു UUID-യും ഒരു epoch-ഉം ഉപയോഗിച്ച് ഒരു റോ (row) എഴുതുന്നു. ആ റോ പ്രത്യക്ഷപ്പെടുന്നത് വരെ അത് റെപ്ലിക്കയെ പരിശോധിച്ചുകൊണ്ടിരിക്കും (polls). അതിനുശേഷം അത് ഉണ്ടാകുന്ന താമസം രേഖപ്പെടുത്തുന്നു.
ഏഷ്യയിലെ 200 പ്രോബുകളിൽ നിന്നുള്ള ഫലങ്ങൾ:
- p50: 800ms
- p95: 3,400ms
- p99: 6,100ms
നിങ്ങളുടെ പ്രൈമറി (primary) നോർത്ത് അമേരിക്കയിലും ഉപയോക്താക്കൾ ഏഷ്യയിലുമാണെങ്കിൽ ലാഗ് കൂടുതലായിരിക്കും.
എനിക്ക് ഒരു സ്കീമ എററും (schema error) നേരിടേണ്ടി വന്നു. പ്രൈമറിയിൽ ഒരു മൈഗ്രേഷൻ (migration) നടന്നു. ഒരു Worker റീസ്റ്റാർട്ട് ആയി. പുതിയ ടേബിൾ എത്തുന്നതിന് മുമ്പ് തന്നെ ആദ്യത്തെ റിക്വസ്റ്റുകൾ ഒരു റെപ്ലിക്കയിൽ എത്തി. ടേബിൾ നിലവിലില്ല എന്നാണ് എറർ കാണിച്ചത്. ടേബിൾ അവിടെ ഉണ്ടായിരുന്നു, പക്ഷേ റെപ്ലിക്ക വൈകിപ്പോയിരുന്നു.
ലാഗിനെ നേരിടുന്നതിന് പകരം അതിനെ മറികടക്കുന്ന രീതിയിൽ റൂട്ടിംഗ് (routing) ക്രമീകരിച്ചുകൊണ്ട് ഞാൻ ഇത് പരിഹരിച്ചു.
എന്റെ ഡിസൈൻ ഇതാ:
- റൈറ്റർ (writer) റോയിൽ ഒരു
written_atepoch ചേർക്കുന്നു. - റൈറ്റർ റെസ്പോൺസിൽ ഒരു
X-D1-Written-Atഹെഡർ ചേർക്കുന്നു. - റീഡർ (reader) ആ ഹെഡറിനെ റെപ്ലിക്കയിലെ ഡാറ്റയുമായി താരതമ്യം ചെയ്യുന്നു.
- റെപ്ലിക്കയിലെ ഡാറ്റ ഹെഡറിനേക്കാൾ പഴയതാണെങ്കിൽ, റീഡർ KV-യിലേക്ക് മാറുന്നു (falls back).
അതേ റീജിയണിൽ തന്നെ KV 500ms-ൽ താഴെ സമയത്തിനുള്ളിൽ പ്രവർത്തിക്കുന്നു. പ്രതിദിനം 10M റീഡുകൾ വരെ ഇത് സൗജന്യമാണ്. ക്രിട്ടിക്കൽ ഫ്ലാഗുകൾക്കായി (critical flags) പുതിയ ഡാറ്റ വേഗത്തിൽ ലഭിക്കാൻ ഇത് ഒരു ലാഭകരമായ മാർഗമാണ്.
റെപ്ലിക്ക വൈകിനിൽക്കുന്ന ആ ചെറിയ സമയത്ത് മാത്രമേ നിങ്ങൾ KV ഉപയോഗിക്കുന്നുള്ളൂ. റെപ്ലിക്ക ഡാറ്റ പുതുക്കിയാൽ (catches up) മിക്ക റീഡുകളും സാധാരണ പോലെ D1-ലേക്ക് തന്നെ എത്തും.
പൂർണ്ണമായ സ്ക്രിപ്റ്റും മൈഗ്രേഷൻ പാറ്റേണും എന്റെ വിശദമായ പോസ്റ്റിൽ ഞാൻ പങ്കുവെച്ചിട്ടുണ്ട്.