SQLite-യുടെ Write-Ahead Logging (WAL) മെക്കാനിസത്തിലെ 16 വർഷം പഴക്കമുള്ള ഒരു പിഴവ് (flaw) ഡാറ്റാബേസുകളെ നിശബ്ദമായി നശിപ്പിക്കാൻ (corrupt) സാധ്യതയുണ്ടെന്ന് Tailscale സ്ഥിരീകരിച്ചു. ഇതിനുള്ള പരിഹാരം SQLite-യുടെ 3.46.1 പതിപ്പിൽ ഉൾപ്പെടുത്തുന്നതിനായി കമ്പനി SQLite മെയിന്റനർമാരുമായി ചേർന്ന് പ്രവർത്തിച്ചു. ഈ കണ്ടെത്തൽ വളരെ പ്രധാനമാണ്, കാരണം പല ആധുനിക സേവനങ്ങളും ഇപ്പോഴും SQLite WAL മോഡിലാണ് പ്രവർത്തിക്കുന്നത്. കണ്ടെത്താനാകാത്ത ഇത്തരം ഡാറ്റാ തകരാറുകൾ കോൺഫിഗറേഷൻ ഡാറ്റ ഇല്ലാതാക്കാനും നെറ്റ്‌വർക്ക് നോഡുകളെ തകരാറിലാക്കാനും കാരണമായേക്കാം.

ഈ ബഗ് എങ്ങനെ രക്ഷപ്പെട്ടു

2010 മുതൽ ഈ ബഗ് WAL മെക്കാനിസത്തിൽ നിലനിന്നിരുന്നു. ഉയർന്ന കോൺകറൻസി ആക്സസ് പാറ്റേണുകളും (high-concurrency access patterns) ചില ഫയൽ സിസ്റ്റം പെരുമാറ്റങ്ങളും തമ്മിലുള്ള അപൂർവ്വമായ ഇടപെടൽ നിശബ്ദമായ ഡാറ്റാ തകരാറുകൾക്ക് കാരണമായി, എന്നാൽ സാധാരണ ഹെൽത്ത് ചെക്കുകൾക്ക് ഇത് കണ്ടെത്താനായില്ല.

വ്യക്തമായ എറർ മെസ്സേജുകൾ ഒന്നുമില്ലാതെ കുറച്ച് നോഡുകളുടെ സ്റ്റോർ ചെയ്ത ഡാറ്റ നഷ്ടപ്പെടുന്നത് Tailscale എഞ്ചിനീയർമാർ ആദ്യം ശ്രദ്ധിച്ചു. “is the database up?” എന്ന് ചോദിക്കുന്ന പ്രോബുകൾ (probes) വിജയകരമായ മറുപടികൾ നൽകുന്നുണ്ടായിരുന്നെങ്കിലും, കോൺഫിഗറേഷൻ എൻട്രികൾ അപ്രത്യക്ഷമായിക്കൊണ്ടിരുന്നു. ഈ പ്രശ്നം വീണ്ടും സൃഷ്ടിക്കാൻ (reproduce) WAL പാത്തിനെ സമ്മർദ്ദത്തിലാക്കുന്നതിനും ഫയൽ സിസ്റ്റം ടൈമിംഗ് ക്രമീകരിക്കുന്നതിനുമുള്ള പ്രത്യേക ടൂളുകൾ ആവശ്യമായിരുന്നു. അതുകൊണ്ടാണ് ഒരു പതിറ്റാണ്ടിലധികം ഈ പ്രശ്നം ഒളിഞ്ഞിരുന്നത്.

ആരെല്ലാം ആശങ്കപ്പെടണം

  • WAL പ്രവർത്തനക്ഷമമാക്കിയുള്ള (enabled) SQLite ഉപയോഗിക്കുന്ന ഏതൊരു ആപ്ലിക്കേഷനും, പ്രത്യേകിച്ച് ഒന്നിലധികം പ്രോസസ്സുകളോ ത്രെഡുകളോ ഒരേസമയം ഡാറ്റ എഴുതുന്ന സാഹചര്യത്തിൽ.
  • ലേറ്റൻസിയും (latency) കാഷിംഗും (caching) സമയക്രമത്തിലെ വ്യതിയാനങ്ങളെ (timing edge cases) വർദ്ധിപ്പിക്കുന്ന നോൺ-സ്റ്റാൻഡേർഡ് അല്ലെങ്കിൽ നെറ്റ്‌വർക്ക്ഡ് ഫയൽ സിസ്റ്റങ്ങളിലെ ഉപയോഗങ്ങൾ.
  • ഒരു SQLite ഫയൽ ശരിയായി കാണപ്പെടുന്നു എന്നതുകൊണ്ട് മാത്രം ഡാറ്റാ ഇന്റഗ്രിറ്റി (data integrity) ഉറപ്പാണെന്ന് കരുതുന്ന ഇൻഫ്രാസ്ട്രക്ചർ സേവനങ്ങൾ.

പരിഹാര മാർഗങ്ങൾ

  1. SQLite അപ്‌ഗ്രേഡ് ചെയ്യുക – പതിപ്പ് 3.46.1 അല്ലെങ്കിൽ അതിനുശേഷമുള്ളവയിലേക്ക് മാറുക; WAL ബഗ് ഇതിൽ പരിഹരിച്ചിട്ടുണ്ട്.
  2. ഇന്റഗ്രിറ്റി ചെക്കുകൾ നടത്തുക – ഡാറ്റാബേസിന്റെ ആന്തരിക ഘടനകൾ പരിശോധിക്കുന്നതിനായി കൃത്യമായ ഇടവേളകളിൽ PRAGMA integrity_check; അല്ലെങ്കിൽ വേഗതയേറിയ PRAGMA quick_check; ഉപയോഗിക്കുക.
  3. WAL ഉപയോഗം പരിശോധിക്കുക – കോഡ്ബേസുകളിൽ journal_mode=WAL സെറ്റിംഗുകൾ ഉണ്ടോ എന്ന് പരിശോധിക്കുകയും, നിലവിലെ കോൺകറൻസി ലെവൽ അത് ആവശ്യമാണോ എന്ന് തീരുമാനിക്കുകയും ചെയ്യുക.
  4. മോണിറ്ററിംഗ് ശക്തമാക്കുക – ഡാറ്റാബേസ് ലഭ്യമാണോ എന്ന് മാത്രം നോക്കാതെ, പ്രതീക്ഷിക്കുന്ന ഡാറ്റാ പാറ്റേണുകളോ റോ കൗണ്ടുകളോ (row counts) തമ്മിൽ താരതമ്യം ചെയ്യുന്ന ചെക്കുകൾ ചേർക്കുക.
  5. തുടർച്ചയായി ബാക്കപ്പ് എടുക്കുക – ഡാറ്റാ തകരാറുകൾ സംഭവിച്ചാൽ സുരക്ഷ ഉറപ്പാക്കാൻ, SQLite മാറ്റങ്ങൾ തത്സമയം പകർത്തുന്ന Litestream പോലുള്ള ടൂളുകൾ ഉപയോഗിക്കുക.

ഈ സംഭവം നൽകുന്ന പാഠങ്ങൾ

  • പഴയ ബഗുകൾ പുതിയ ലോഡുകളിൽ പ്രത്യക്ഷപ്പെട്ടേക്കാം – സേവനങ്ങൾ വികസിക്കുമ്പോൾ, പണ്ട് അപൂർവ്വമായിരുന്ന പാറ്റേണുകൾ സാധാരണമാവുകയും പഴയ പിഴവുകൾ വെളിപ്പെടുകയും ചെയ്യുന്നു.
  • ക്രാഷിനേക്കാൾ അപകടകാരിയാണ് നിശബ്ദമായ ഡാറ്റാ തകരാറുകൾ – ഒരു ക്രാഷ് സിസ്റ്റം റീസ്റ്റാർട്ട് ചെയ്യാൻ പ്രേരിപ്പിക്കുകയും അലേർട്ടുകൾ നൽകുകയും ചെയ്യും; എന്നാൽ നിശബ്ദമായ ഡാറ്റാ നഷ്ടം ആഴ്ചകളോളം ശ്രദ്ധിക്കപ്പെടാതെ പോകാം.
  • തുറന്ന പോസ്റ്റ്-മോർട്ടം റിപ്പോർട്ടുകൾ ഇക്കോസിസ്റ്റത്തിന് സഹായകരമാണ് – Tailscale-ന്റെ വിശദമായ റിപ്പോർട്ട് മറ്റ് ടീമുകൾക്ക് അവരുടെ ഉപയോഗങ്ങൾ വേഗത്തിൽ പരിശോധിക്കാൻ ആവശ്യമായ വിവരങ്ങൾ നൽകി.

ഇനി ശ്രദ്ധിക്കേണ്ടവ

വാർത്ത പങ്കുവെക്കുന്നതിന് മുമ്പ് തന്നെ പരിഹാരം തയ്യാറാണെന്ന് ഉറപ്പാക്കാൻ Tailscale SQLite ടീമുമായി ചേർന്ന് പ്രവർത്തിച്ചു.

ചുരുക്കത്തിൽ: 16 വർഷം ആരും ശ്രദ്ധിക്കാതെ നിലനിന്ന ഒരു ബഗ് വീണ്ടും ഉയർന്നുവന്നത്, ആധുനിക വർക്ക് ലോഡുകൾ SQLite-നെ അതിന്റെ യഥാർത്ഥ ഡെവലപ്പർമാർ വിചാരിക്കാത്ത രീതിയിൽ ഉപയോഗിച്ചതുകൊണ്ടാണ്. ലൈബ്രറി അപ്‌ഡേറ്റ് ചെയ്യുക, ഇന്റഗ്രിറ്റി ചെക്കുകൾ നടത്തുക, ഒബ്സർവബിലിറ്റി (observability) മെച്ചപ്പെടുത്തുക എന്നിവ ഇത്തരം ഒളിഞ്ഞിരിക്കുന്ന പരാജയങ്ങളിൽ നിന്ന് സംരക്ഷണം നേടാനുള്ള ഏറ്റവും വേഗത്തിലുള്ള മാർഗങ്ങളാണ്.