ഡ്യൂറബിൾ ഡാറ്റ സ്റ്റോറേജും Linux ഫയൽ API-കളും

ക്ലൗഡ് സിസ്റ്റങ്ങളിലെ ഡാറ്റാ സംഭരണത്തിന്റെ സുസ്ഥിരതയെക്കുറിച്ച് ഗവേഷണം നടത്തുന്നതിനിടയിൽ, അടിസ്ഥാന കാര്യങ്ങൾ എനിക്ക് മനസ്സിലായിട്ടുണ്ടെന്ന് ഉറപ്പാക്കാൻ ഞാൻ എന്നെത്തന്നെ പരീക്ഷിക്കാൻ തീരുമാനിച്ചു. ഐ NVMe സ്പെസിഫിക്കേഷൻ വായിച്ചാണ് ആരംഭിച്ചത് സുസ്ഥിരമായ ഡാറ്റാ സ്റ്റോറേജ് സംബന്ധിച്ച് എന്താണ് ഉറപ്പ് നൽകുന്നതെന്ന് മനസിലാക്കാൻ (അതായത്, ഒരു സിസ്റ്റം പരാജയത്തിന് ശേഷം ഡാറ്റ ലഭ്യമാകുമെന്ന് ഉറപ്പ് നൽകുന്നു) ഞങ്ങൾക്ക് NMVe ഡിസ്കുകൾ നൽകുന്നു. ഞാൻ ഇനിപ്പറയുന്ന പ്രധാന നിഗമനങ്ങൾ നടത്തി: ഡാറ്റ എഴുതാനുള്ള കമാൻഡ് നൽകിയ നിമിഷം മുതൽ സ്റ്റോറേജ് മീഡിയത്തിലേക്ക് എഴുതുന്നത് വരെ ഡാറ്റ കേടായതായി കണക്കാക്കണം. എന്നിരുന്നാലും, മിക്ക പ്രോഗ്രാമുകളും ഡാറ്റ റെക്കോർഡ് ചെയ്യാൻ സിസ്റ്റം കോളുകൾ വളരെ സന്തോഷത്തോടെ ഉപയോഗിക്കുന്നു.

ഈ ലേഖനത്തിൽ, Linux ഫയൽ API-കൾ നൽകുന്ന പെർസിസ്റ്റൻസ് മെക്കാനിസങ്ങൾ ഞാൻ പര്യവേക്ഷണം ചെയ്യുന്നു. എല്ലാം ഇവിടെ ലളിതമായിരിക്കണമെന്ന് തോന്നുന്നു: പ്രോഗ്രാം കമാൻഡിനെ വിളിക്കുന്നു write(), ഈ കമാൻഡിന്റെ പ്രവർത്തനം പൂർത്തിയായ ശേഷം, ഡാറ്റ സുരക്ഷിതമായി ഡിസ്കിൽ സംഭരിക്കും. പക്ഷേ write() RAM-ൽ സ്ഥിതി ചെയ്യുന്ന കേർണൽ കാഷെയിലേക്ക് ആപ്ലിക്കേഷൻ ഡാറ്റ മാത്രം പകർത്തുന്നു. ഡിസ്കിലേക്ക് ഡാറ്റ എഴുതാൻ സിസ്റ്റത്തെ നിർബന്ധിക്കുന്നതിന്, ചില അധിക സംവിധാനങ്ങൾ ഉപയോഗിക്കേണ്ടതുണ്ട്.

പൊതുവേ, ഈ മെറ്റീരിയൽ എനിക്ക് താൽപ്പര്യമുള്ള ഒരു വിഷയത്തിൽ ഞാൻ പഠിച്ച കാര്യങ്ങളുമായി ബന്ധപ്പെട്ട കുറിപ്പുകളുടെ ഒരു കൂട്ടമാണ്. ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യങ്ങളെക്കുറിച്ച് ഞങ്ങൾ വളരെ ചുരുക്കമായി സംസാരിക്കുകയാണെങ്കിൽ, സുസ്ഥിര ഡാറ്റ സംഭരണം സംഘടിപ്പിക്കുന്നതിന്, നിങ്ങൾ കമാൻഡ് ഉപയോഗിക്കേണ്ടതുണ്ട്. fdatasync() അല്ലെങ്കിൽ ഫ്ലാഗ് ഉപയോഗിച്ച് ഫയലുകൾ തുറക്കുക O_DSYNC. കോഡിൽ നിന്ന് ഡിസ്കിലേക്കുള്ള വഴിയിൽ ഡാറ്റയ്ക്ക് എന്ത് സംഭവിക്കും എന്നതിനെക്കുറിച്ച് കൂടുതലറിയാൻ നിങ്ങൾക്ക് താൽപ്പര്യമുണ്ടെങ്കിൽ, ഒന്ന് നോക്കുക ഇത് ലേഖനം.

റൈറ്റ്() ഫംഗ്ഷൻ ഉപയോഗിക്കുന്നതിന്റെ സവിശേഷതകൾ

സിസ്റ്റം കോൾ write() സ്റ്റാൻഡേർഡിൽ നിർവചിച്ചിരിക്കുന്നത് ഐഇഇഇ പോസിക്സ് ഒരു ഫയൽ ഡിസ്ക്രിപ്റ്ററിലേക്ക് ഡാറ്റ എഴുതാനുള്ള ശ്രമമായി. ജോലി വിജയകരമായി പൂർത്തിയാക്കിയ ശേഷം write() ഡാറ്റ റീഡ് ഓപ്പറേഷനുകൾ മുമ്പ് എഴുതിയ ബൈറ്റുകൾ കൃത്യമായി നൽകണം, മറ്റ് പ്രോസസ്സുകളിൽ നിന്നോ ത്രെഡുകളിൽ നിന്നോ ഡാറ്റ ആക്‌സസ് ചെയ്യുകയാണെങ്കിൽ പോലും (നോക്കൂ POSIX സ്റ്റാൻഡേർഡിന്റെ പ്രസക്തമായ വിഭാഗം). ഇത്, സാധാരണ ഫയൽ പ്രവർത്തനങ്ങളുമായുള്ള ത്രെഡുകളുടെ ഇടപെടലിനെക്കുറിച്ചുള്ള വിഭാഗത്തിൽ, രണ്ട് ത്രെഡുകൾ ഓരോന്നും ഈ ഫംഗ്ഷനുകളെ വിളിക്കുന്നുവെങ്കിൽ, ഓരോ കോളും ഒന്നുകിൽ മറ്റ് കോളിന്റെ നിർവ്വഹണം നയിക്കുന്ന എല്ലാ സൂചിപ്പിച്ച അനന്തരഫലങ്ങളും കാണണം എന്ന് പറയുന്ന ഒരു കുറിപ്പുണ്ട്. ഒരു അനന്തരഫലവും കാണുന്നില്ല. എല്ലാ ഫയൽ I/O ഓപ്പറേഷനുകളും പ്രവർത്തിക്കുന്ന ഉറവിടത്തിൽ ഒരു ലോക്ക് ഉണ്ടായിരിക്കണം എന്ന നിഗമനത്തിലേക്ക് ഇത് നയിക്കുന്നു.

ഇതിനർത്ഥം ഓപ്പറേഷൻ എന്നാണ് write() ആണാണോ? ഒരു സാങ്കേതിക കാഴ്ചപ്പാടിൽ, അതെ. ഡാറ്റ റീഡ് ഓപ്പറേഷനുകൾ എഴുതിയത് മുഴുവൻ അല്ലെങ്കിൽ ഒന്നും തന്നെ നൽകണം write(). എന്നാൽ ഓപ്പറേഷൻ write(), സ്റ്റാൻഡേർഡ് അനുസരിച്ച്, അത് എഴുതാൻ ആവശ്യപ്പെട്ടതെല്ലാം എഴുതി അവസാനിപ്പിക്കണമെന്നില്ല. ഡാറ്റയുടെ ഒരു ഭാഗം മാത്രം എഴുതാൻ അവൾക്ക് അനുവാദമുണ്ട്. ഉദാഹരണത്തിന്, ഒരേ ഫയൽ ഡിസ്ക്രിപ്റ്റർ വിവരിച്ച ഒരു ഫയലിലേക്ക് 1024 ബൈറ്റുകൾ കൂട്ടിച്ചേർക്കുന്ന രണ്ട് ത്രെഡുകൾ നമുക്ക് ഉണ്ടായിരിക്കാം. സ്റ്റാൻഡേർഡിന്റെ വീക്ഷണകോണിൽ നിന്ന്, ഓരോ റൈറ്റ് ഓപ്പറേഷനും ഫയലിലേക്ക് ഒരു ബൈറ്റ് മാത്രമേ ചേർക്കാൻ കഴിയൂ എന്നതാണ് സ്വീകാര്യമായ ഫലം. ഈ പ്രവർത്തനങ്ങൾ ആറ്റോമിക് ആയി നിലനിൽക്കും, പക്ഷേ അവ പൂർത്തിയാക്കിയ ശേഷം, അവർ ഫയലിലേക്ക് എഴുതിയ ഡാറ്റ മിശ്രിതമാകും. ഇവിടെ സ്റ്റാക്ക് ഓവർഫ്ലോ എന്ന വിഷയത്തെക്കുറിച്ചുള്ള വളരെ രസകരമായ ചർച്ച.

fsync(), fdatasync() ഫംഗ്ഷനുകൾ

ഡിസ്കിലേക്ക് ഡാറ്റ ഫ്ലഷ് ചെയ്യുന്നതിനുള്ള എളുപ്പവഴി ഫംഗ്ഷനിലേക്ക് വിളിക്കുക എന്നതാണ് fsync(). പരിഷ്കരിച്ച എല്ലാ ബ്ലോക്കുകളും കാഷെയിൽ നിന്ന് ഡിസ്കിലേക്ക് നീക്കാൻ ഈ ഫംഗ്ഷൻ ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തോട് ആവശ്യപ്പെടുന്നു. ഫയലിന്റെ എല്ലാ മെറ്റാഡാറ്റയും ഇതിൽ ഉൾപ്പെടുന്നു (ആക്സസ് സമയം, ഫയൽ പരിഷ്ക്കരണ സമയം മുതലായവ). ഈ മെറ്റാഡാറ്റ വളരെ അപൂർവമായി മാത്രമേ ആവശ്യമുള്ളൂ എന്ന് ഞാൻ വിശ്വസിക്കുന്നു, അതിനാൽ ഇത് നിങ്ങൾക്ക് പ്രധാനമല്ലെന്ന് നിങ്ങൾക്കറിയാമെങ്കിൽ, നിങ്ങൾക്ക് ഫംഗ്ഷൻ ഉപയോഗിക്കാം fdatasync(). ദി സഹായം ആ സമയത്ത് fdatasync() ഈ ഫംഗ്‌ഷന്റെ പ്രവർത്തന സമയത്ത്, ഇത്രയും മെറ്റാഡാറ്റ ഡിസ്‌കിലേക്ക് സേവ് ചെയ്യപ്പെടുന്നു, ഇത് "ഇനിപ്പറയുന്ന ഡാറ്റ റീഡിംഗ് ഓപ്പറേഷനുകളുടെ ശരിയായ നിർവ്വഹണത്തിന് ആവശ്യമാണ്." മിക്ക ആപ്ലിക്കേഷനുകളും ശ്രദ്ധിക്കുന്നത് ഇതാണ്.

സാധ്യമായ പരാജയത്തിന് ശേഷം ഫയൽ കണ്ടെത്താനാകുമെന്ന് ഈ മെക്കാനിസങ്ങൾ ഉറപ്പുനൽകുന്നില്ല എന്നതാണ് ഇവിടെ ഉയർന്നുവരുന്ന ഒരു പ്രശ്നം. പ്രത്യേകിച്ച്, ഒരു പുതിയ ഫയൽ സൃഷ്ടിക്കുമ്പോൾ, നിങ്ങൾ വിളിക്കേണ്ടതുണ്ട് fsync() അത് അടങ്ങുന്ന ഡയറക്‌ടറിക്കായി. അല്ലെങ്കിൽ, ഒരു ക്രാഷിനുശേഷം, ഈ ഫയൽ നിലവിലില്ല എന്ന് തെളിഞ്ഞേക്കാം. UNIX-ന് കീഴിൽ, ഹാർഡ് ലിങ്കുകളുടെ ഉപയോഗം കാരണം, ഒരു ഫയൽ ഒന്നിലധികം ഡയറക്ടറികളിൽ നിലനിൽക്കും എന്നതാണ് ഇതിന് കാരണം. അതിനാൽ, വിളിക്കുമ്പോൾ fsync() ഏത് ഡയറക്‌ടറി ഡാറ്റയും ഡിസ്‌കിലേക്ക് ഫ്ലഷ് ചെയ്യണമെന്ന് ഒരു ഫയലിന് അറിയാൻ മാർഗമില്ല (ഇവിടെ നിങ്ങൾക്ക് ഇതിനെക്കുറിച്ച് കൂടുതൽ വായിക്കാം). ext4 ഫയൽ സിസ്റ്റത്തിന് കഴിവുണ്ടെന്ന് തോന്നുന്നു യാന്ത്രികമായി അപേക്ഷിക്കാൻ fsync() അനുബന്ധ ഫയലുകൾ അടങ്ങുന്ന ഡയറക്‌ടറികളിലേക്ക്, എന്നാൽ മറ്റ് ഫയൽ സിസ്റ്റങ്ങളുടെ കാര്യം അങ്ങനെയാകണമെന്നില്ല.

വ്യത്യസ്ത ഫയൽ സിസ്റ്റങ്ങളിൽ ഈ സംവിധാനം വ്യത്യസ്തമായി നടപ്പിലാക്കാം. ഞാൻ ഉപയോഗിച്ചു blktrace ext4, XFS ഫയൽ സിസ്റ്റങ്ങളിൽ എന്തെല്ലാം ഡിസ്ക് ഓപ്പറേഷനുകളാണ് ഉപയോഗിക്കുന്നതെന്ന് അറിയാൻ. രണ്ടും ഫയലുകളുടെയും ഫയൽ സിസ്റ്റം ജേണലിന്റെയും ഉള്ളടക്കങ്ങൾക്കായി ഡിസ്കിലേക്ക് സാധാരണ റൈറ്റ് കമാൻഡുകൾ നൽകുന്നു, ഒരു FUA (ഫോഴ്സ് യൂണിറ്റ് ആക്സസ്, ഡിസ്കിലേക്ക് നേരിട്ട് ഡാറ്റ എഴുതുക, കാഷെ ബൈപാസ് ചെയ്യുക) നടത്തി കാഷെ ഫ്ലഷ് ചെയ്ത് പുറത്തുകടക്കുക. ഇടപാടിന്റെ വസ്‌തുത സ്ഥിരീകരിക്കാൻ അവർ അത് ചെയ്‌തേക്കാം. FUA പിന്തുണയ്ക്കാത്ത ഡ്രൈവുകളിൽ, ഇത് രണ്ട് കാഷെ ഫ്ലഷുകൾക്ക് കാരണമാകുന്നു. എന്റെ പരീക്ഷണങ്ങൾ അത് തെളിയിച്ചിട്ടുണ്ട് fdatasync() അൽപ്പം വേഗത്തിൽ fsync(). യൂട്ടിലിറ്റി blktrace എന്ന് സൂചിപ്പിക്കുന്നു fdatasync() സാധാരണയായി ഡിസ്കിലേക്ക് കുറച്ച് ഡാറ്റ എഴുതുന്നു (ext4 ൽ fsync() 20 കിബി എഴുതുന്നു, ഒപ്പം fdatasync() - 16 കിബി). കൂടാതെ, XFS ext4 നേക്കാൾ അൽപ്പം വേഗതയുള്ളതാണെന്ന് ഞാൻ കണ്ടെത്തി. ഇവിടെയും സഹായത്തോടെ blktrace എന്ന് കണ്ടുപിടിക്കാൻ കഴിഞ്ഞു fdatasync() ഡിസ്കിലേക്ക് കുറച്ച് ഡാറ്റ ഫ്ലഷ് ചെയ്യുന്നു (XFS-ൽ 4 KiB).

fsync() ഉപയോഗിക്കുമ്പോൾ അവ്യക്തമായ സാഹചര്യങ്ങൾ

അവ്യക്തമായ മൂന്ന് സാഹചര്യങ്ങളെക്കുറിച്ച് എനിക്ക് ചിന്തിക്കാൻ കഴിയും fsync()ഞാൻ പ്രായോഗികമായി കണ്ടത്.

2008ലാണ് ഇത്തരമൊരു സംഭവം ഉണ്ടായത്. ധാരാളം ഫയലുകൾ ഡിസ്കിലേക്ക് എഴുതിയാൽ ഫയർഫോക്സ് 3 ഇന്റർഫേസ് മരവിച്ചു. ഇന്റർഫേസ് നടപ്പിലാക്കുന്നത് അതിന്റെ അവസ്ഥയെക്കുറിച്ചുള്ള വിവരങ്ങൾ സംഭരിക്കുന്നതിന് ഒരു SQLite ഡാറ്റാബേസ് ഉപയോഗിച്ചതാണ് പ്രശ്നം. ഇന്റർഫേസിൽ സംഭവിച്ച ഓരോ മാറ്റത്തിനും ശേഷം, ഫംഗ്ഷൻ വിളിക്കപ്പെട്ടു fsync(), ഇത് സ്ഥിരതയുള്ള ഡാറ്റ സംഭരണത്തിന് നല്ല ഗ്യാരണ്ടി നൽകി. അപ്പോൾ ഉപയോഗിച്ച ext3 ഫയൽ സിസ്റ്റത്തിൽ, ഫംഗ്ഷൻ fsync() സിസ്റ്റത്തിലെ എല്ലാ "വൃത്തികെട്ട" പേജുകളും ഡിസ്കിലേക്ക് ഫ്ലഷ് ചെയ്തു, അനുബന്ധ ഫയലുമായി ബന്ധപ്പെട്ടവ മാത്രമല്ല. ഇതിനർത്ഥം ഫയർഫോക്സിലെ ഒരു ബട്ടണിൽ ക്ലിക്കുചെയ്യുന്നത് ഒരു മാഗ്നറ്റിക് ഡിസ്കിലേക്ക് മെഗാബൈറ്റ് ഡാറ്റ എഴുതാൻ ഇടയാക്കും, ഇതിന് നിരവധി സെക്കൻഡുകൾ എടുത്തേക്കാം. പ്രശ്നത്തിനുള്ള പരിഹാരം, ഞാൻ മനസ്സിലാക്കിയിടത്തോളം അത് ഡാറ്റാബേസുമായുള്ള ജോലി അസിൻക്രണസ് ബാക്ക്ഗ്രൗണ്ട് ടാസ്ക്കുകളിലേക്ക് മാറ്റുക എന്നതായിരുന്നു മെറ്റീരിയൽ. ഇതിനർത്ഥം ഫയർഫോക്സ് മുമ്പ് യഥാർത്ഥത്തിൽ ആവശ്യമുള്ളതിനേക്കാൾ കൂടുതൽ കർശനമായ സ്റ്റോറേജ് ആവശ്യകതകൾ നടപ്പിലാക്കിയിരുന്നു, കൂടാതെ ext3 ഫയൽ സിസ്റ്റത്തിന്റെ സവിശേഷതകൾ ഈ പ്രശ്നം കൂടുതൽ വഷളാക്കുകയേയുള്ളൂ.

രണ്ടാമത്തെ പ്രശ്നം 2009 ൽ സംഭവിച്ചു. പിന്നീട്, ഒരു സിസ്റ്റം ക്രാഷിന് ശേഷം, പുതിയ ext4 ഫയൽ സിസ്റ്റത്തിന്റെ ഉപയോക്താക്കൾക്ക് പുതുതായി സൃഷ്ടിച്ച പല ഫയലുകൾക്കും പൂജ്യം നീളം ഉണ്ടെന്ന വസ്തുത അഭിമുഖീകരിച്ചു, എന്നാൽ പഴയ ext3 ഫയൽ സിസ്റ്റത്തിൽ ഇത് സംഭവിച്ചില്ല. മുമ്പത്തെ ഖണ്ഡികയിൽ, ext3 എങ്ങനെയാണ് ഡിസ്കിലേക്ക് വളരെയധികം ഡാറ്റ ഫ്ലഷ് ചെയ്തതെന്ന് ഞാൻ സംസാരിച്ചു, ഇത് കാര്യങ്ങൾ വളരെയധികം മന്ദഗതിയിലാക്കി. fsync(). സാഹചര്യം മെച്ചപ്പെടുത്തുന്നതിന്, ഒരു പ്രത്യേക ഫയലിന് പ്രസക്തമായ "വൃത്തികെട്ട" പേജുകൾ മാത്രം ext4 ഫ്ലഷ് ചെയ്യുന്നു. മറ്റ് ഫയലുകളുടെ ഡാറ്റ ext3-നേക്കാൾ കൂടുതൽ സമയം മെമ്മറിയിൽ തുടരും. പ്രകടനം മെച്ചപ്പെടുത്തുന്നതിനാണ് ഇത് ചെയ്തത് (സ്ഥിരസ്ഥിതിയായി, ഡാറ്റ 30 സെക്കൻഡ് ഈ അവസ്ഥയിൽ തുടരും, നിങ്ങൾക്ക് ഇത് ഉപയോഗിച്ച് കോൺഫിഗർ ചെയ്യാം dirty_expire_centisecs; ഇവിടെ നിങ്ങൾക്ക് ഇതിനെക്കുറിച്ച് കൂടുതൽ വിവരങ്ങൾ കണ്ടെത്താൻ കഴിയും). ഇതിനർത്ഥം ഒരു ക്രാഷിന് ശേഷം വലിയ അളവിലുള്ള ഡാറ്റ വീണ്ടെടുക്കാനാകാത്തവിധം നഷ്‌ടപ്പെടുമെന്നാണ്. ഉപയോഗിക്കുക എന്നതാണ് ഈ പ്രശ്നത്തിനുള്ള പരിഹാരം fsync() സുസ്ഥിരമായ ഡാറ്റ സംഭരണം നൽകേണ്ടതും പരാജയങ്ങളുടെ അനന്തരഫലങ്ങളിൽ നിന്ന് അവരെ പരമാവധി സംരക്ഷിക്കേണ്ടതുമായ ആപ്ലിക്കേഷനുകളിൽ. ഫംഗ്ഷൻ fsync() ext4 നേക്കാൾ കൂടുതൽ കാര്യക്ഷമമായി ext3 ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നു. ഈ സമീപനത്തിന്റെ പോരായ്മ, അതിന്റെ ഉപയോഗം, മുമ്പത്തെപ്പോലെ, പ്രോഗ്രാമുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നത് പോലുള്ള ചില പ്രവർത്തനങ്ങളെ മന്ദഗതിയിലാക്കുന്നു എന്നതാണ്. ഇതിനെക്കുറിച്ചുള്ള വിശദാംശങ്ങൾ കാണുക ഇവിടെ и ഇവിടെ.

സംബന്ധിച്ച മൂന്നാമത്തെ പ്രശ്നം fsync(), 2018-ൽ ഉത്ഭവിച്ചത്. തുടർന്ന്, PostgreSQL പ്രോജക്റ്റിന്റെ ചട്ടക്കൂടിനുള്ളിൽ, ഫംഗ്ഷൻ ആണെങ്കിൽ എന്ന് കണ്ടെത്തി fsync() ഒരു പിശക് നേരിടുന്നു, അത് "വൃത്തികെട്ട" പേജുകളെ "വൃത്തിയുള്ളത്" എന്ന് അടയാളപ്പെടുത്തുന്നു. തൽഫലമായി, ഇനിപ്പറയുന്ന കോളുകൾ fsync() അത്തരം പേജുകൾ ഉപയോഗിച്ച് ഒന്നും ചെയ്യരുത്. ഇക്കാരണത്താൽ, പരിഷ്കരിച്ച പേജുകൾ മെമ്മറിയിൽ സൂക്ഷിക്കുന്നു, ഡിസ്കിൽ എഴുതില്ല. ഇതൊരു യഥാർത്ഥ ദുരന്തമാണ്, കാരണം കുറച്ച് ഡാറ്റ ഡിസ്കിലേക്ക് എഴുതിയിട്ടുണ്ടെന്ന് ആപ്ലിക്കേഷൻ കരുതുന്നു, പക്ഷേ വാസ്തവത്തിൽ അത് അങ്ങനെയായിരിക്കില്ല. അത്തരം പരാജയങ്ങൾ fsync() അപൂർവമാണ്, അത്തരം സാഹചര്യങ്ങളിൽ പ്രയോഗത്തിന് പ്രശ്നത്തെ നേരിടാൻ ഏതാണ്ട് ഒന്നും ചെയ്യാൻ കഴിയില്ല. ഈ ദിവസങ്ങളിൽ, ഇത് സംഭവിക്കുമ്പോൾ, PostgreSQL ഉം മറ്റ് ആപ്ലിക്കേഷനുകളും തകരാറിലാകുന്നു. ഇത്, "fsync പരാജയങ്ങളിൽ നിന്ന് അപ്ലിക്കേഷനുകൾ വീണ്ടെടുക്കാൻ കഴിയുമോ?" എന്ന മെറ്റീരിയലിൽ, ഈ പ്രശ്നം വിശദമായി പരിശോധിക്കുന്നു. നിലവിൽ ഈ പ്രശ്നത്തിനുള്ള ഏറ്റവും നല്ല പരിഹാരം ഫ്ലാഗിനൊപ്പം ഡയറക്ട് I/O ഉപയോഗിക്കുന്നതാണ് O_SYNC അല്ലെങ്കിൽ ഒരു പതാക ഉപയോഗിച്ച് O_DSYNC. ഈ സമീപനം ഉപയോഗിച്ച്, നിർദ്ദിഷ്ട ഡാറ്റ റൈറ്റ് പ്രവർത്തനങ്ങൾ നടത്തുമ്പോൾ സംഭവിക്കാനിടയുള്ള പിശകുകൾ സിസ്റ്റം റിപ്പോർട്ട് ചെയ്യും, എന്നാൽ ഈ സമീപനത്തിന് ബഫറുകൾ തന്നെ കൈകാര്യം ചെയ്യാൻ ആപ്ലിക്കേഷൻ ആവശ്യമാണ്. അതിനെക്കുറിച്ച് കൂടുതൽ വായിക്കുക ഇവിടെ и ഇവിടെ.

O_SYNC, O_DSYNC ഫ്ലാഗുകൾ ഉപയോഗിച്ച് ഫയലുകൾ തുറക്കുന്നു

സ്ഥിരമായ ഡാറ്റ സംഭരണം നൽകുന്ന ലിനക്സ് മെക്കാനിസങ്ങളെക്കുറിച്ചുള്ള ചർച്ചയിലേക്ക് നമുക്ക് മടങ്ങാം. അതായത്, നമ്മൾ സംസാരിക്കുന്നത് പതാകയുടെ ഉപയോഗത്തെക്കുറിച്ചാണ് O_SYNC അല്ലെങ്കിൽ പതാക O_DSYNC സിസ്റ്റം കോൾ ഉപയോഗിച്ച് ഫയലുകൾ തുറക്കുമ്പോൾ തുറക്കുക (). ഈ സമീപനം ഉപയോഗിച്ച്, ഓരോ കമാൻഡിനുശേഷവും ഓരോ ഡാറ്റാ റൈറ്റ് ഓപ്പറേഷൻ നടത്തുന്നു write() സിസ്റ്റത്തിന് യഥാക്രമം കമാൻഡുകൾ നൽകിയിരിക്കുന്നു fsync() и fdatasync(). ദി POSIX സവിശേഷതകൾ ഇതിനെ "സിൻക്രൊണൈസ്ഡ് I/O ഫയൽ ഇന്റഗ്രിറ്റി കംപ്ലീഷൻ" എന്നും "ഡാറ്റ ഇന്റഗ്രിറ്റി കംപ്ലീഷൻ" എന്നും വിളിക്കുന്നു. ഈ സമീപനത്തിന്റെ പ്രധാന നേട്ടം, ഡാറ്റാ സമഗ്രത ഉറപ്പാക്കാൻ ഒരു സിസ്റ്റം കോൾ മാത്രമേ എക്സിക്യൂട്ട് ചെയ്യേണ്ടതുള്ളൂ, രണ്ടല്ല (ഉദാഹരണത്തിന് - write() и fdatasync()). ഈ സമീപനത്തിന്റെ പ്രധാന പോരായ്മ, അനുബന്ധ ഫയൽ ഡിസ്ക്രിപ്റ്റർ ഉപയോഗിച്ചുള്ള എല്ലാ റൈറ്റ് പ്രവർത്തനങ്ങളും സമന്വയിപ്പിക്കപ്പെടും, ഇത് ആപ്ലിക്കേഷൻ കോഡ് രൂപപ്പെടുത്താനുള്ള കഴിവ് പരിമിതപ്പെടുത്തും.

O_DIRECT ഫ്ലാഗ് ഉപയോഗിച്ച് ഡയറക്ട് I/O ഉപയോഗിക്കുന്നു

സിസ്റ്റം കോൾ open() പതാകയെ പിന്തുണയ്ക്കുന്നു O_DIRECT, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം കാഷെ മറികടക്കുന്നതിനും I / O പ്രവർത്തനങ്ങൾ നടത്തുന്നതിനും ഡിസ്കുമായി നേരിട്ട് സംവദിക്കുന്നതിനും രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതാണ്. ഇത്, മിക്ക കേസുകളിലും, പ്രോഗ്രാം നൽകുന്ന റൈറ്റ് കമാൻഡുകൾ ഡിസ്കുമായി പ്രവർത്തിക്കാൻ ലക്ഷ്യമിട്ടുള്ള കമാൻഡുകളിലേക്ക് നേരിട്ട് വിവർത്തനം ചെയ്യപ്പെടും എന്നാണ്. പക്ഷേ, പൊതുവേ, ഈ സംവിധാനം ഫംഗ്ഷനുകൾക്ക് പകരമാവില്ല fsync() അഥവാ fdatasync(). ഡിസ്കിന് തന്നെ കഴിയും എന്നതാണ് വസ്തുത കാലതാമസം അല്ലെങ്കിൽ കാഷെ ഡാറ്റ എഴുതുന്നതിനുള്ള ഉചിതമായ കമാൻഡുകൾ. കൂടാതെ, അതിലും മോശം, ചില പ്രത്യേക സന്ദർഭങ്ങളിൽ, ഫ്ലാഗ് ഉപയോഗിക്കുമ്പോൾ I / O പ്രവർത്തനങ്ങൾ നടത്തുന്നു O_DIRECT, പ്രക്ഷേപണം പരമ്പരാഗത ബഫർ ചെയ്ത പ്രവർത്തനങ്ങളിലേക്ക്. ഈ പ്രശ്നം പരിഹരിക്കാനുള്ള എളുപ്പവഴി ഫയലുകൾ തുറക്കാൻ ഫ്ലാഗ് ഉപയോഗിക്കുക എന്നതാണ് O_DSYNC, ഓരോ റൈറ്റ് ഓപ്പറേഷനും ഒരു കോൾ വരും എന്നാണ് അർത്ഥമാക്കുന്നത് fdatasync().

XFS ഫയൽസിസ്റ്റം അടുത്തിടെ ഒരു "ഫാസ്റ്റ് പാത്ത്" ചേർത്തിട്ടുണ്ടെന്ന് മനസ്സിലായി O_DIRECT|O_DSYNC- ഡാറ്റ റെക്കോർഡുകൾ. ബ്ലോക്ക് ഉപയോഗിച്ച് തിരുത്തിയെഴുതിയാൽ O_DIRECT|O_DSYNC, തുടർന്ന് XFS, കാഷെ ഫ്ലഷ് ചെയ്യുന്നതിനുപകരം, ഉപകരണം പിന്തുണയ്ക്കുന്നുവെങ്കിൽ FUA റൈറ്റ് കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യും. യൂട്ടിലിറ്റി ഉപയോഗിച്ച് ഞാൻ ഇത് പരിശോധിച്ചു blktrace ഒരു Linux 5.4/Ubuntu 20.04 സിസ്റ്റത്തിൽ. ഈ സമീപനം കൂടുതൽ കാര്യക്ഷമമായിരിക്കണം, കാരണം ഇത് ഡിസ്കിലേക്ക് ഏറ്റവും കുറഞ്ഞ ഡാറ്റ എഴുതുകയും ഒരു പ്രവർത്തനം ഉപയോഗിക്കുകയും ചെയ്യുന്നു, രണ്ടല്ല (കാഷെ എഴുതി ഫ്ലഷ് ചെയ്യുക). എന്നതിലേക്കുള്ള ലിങ്ക് ഞാൻ കണ്ടെത്തി പാച്ച് ഈ സംവിധാനം നടപ്പിലാക്കുന്ന 2018 കേർണൽ. മറ്റ് ഫയൽ സിസ്റ്റങ്ങളിൽ ഈ ഒപ്റ്റിമൈസേഷൻ പ്രയോഗിക്കുന്നതിനെക്കുറിച്ച് ചില ചർച്ചകൾ നടക്കുന്നുണ്ട്, എന്നാൽ എനിക്കറിയാവുന്നിടത്തോളം, XFS മാത്രമാണ് ഇതുവരെ പിന്തുണയ്ക്കുന്ന ഒരേയൊരു ഫയൽസിസ്റ്റം.

sync_file_range() ഫംഗ്‌ഷൻ

ലിനക്സിന് ഒരു സിസ്റ്റം കോൾ ഉണ്ട് sync_file_range(), ഇത് ഫയലിന്റെ ഒരു ഭാഗം മാത്രം ഡിസ്കിലേക്ക് ഫ്ലഷ് ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്നു, മുഴുവൻ ഫയലും അല്ല. ഈ കോൾ ഒരു അസിൻക്രണസ് ഫ്ലഷ് ആരംഭിക്കുന്നു, അത് പൂർത്തിയാകുന്നതുവരെ കാത്തിരിക്കുകയുമില്ല. എന്നാൽ പരാമർശത്തിൽ sync_file_range() ഈ കമാൻഡ് "വളരെ അപകടകരമാണ്" എന്ന് പറയപ്പെടുന്നു. ഇത് ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്തിട്ടില്ല. സവിശേഷതകളും അപകടങ്ങളും sync_file_range() വളരെ നന്നായി വിവരിച്ചിട്ടുണ്ട് ഇത് മെറ്റീരിയൽ. പ്രത്യേകിച്ചും, കേർണൽ "വൃത്തികെട്ട" ഡാറ്റ ഡിസ്കിലേക്ക് ഫ്ലഷ് ചെയ്യുമ്പോൾ നിയന്ത്രിക്കാൻ ഈ കോൾ RocksDB ഉപയോഗിക്കുന്നതായി തോന്നുന്നു. എന്നാൽ അതേ സമയം അവിടെ, സ്ഥിരമായ ഡാറ്റ സംഭരണം ഉറപ്പാക്കാൻ, അതും ഉപയോഗിക്കുന്നു fdatasync(). ദി കോഡ് ഈ വിഷയത്തിൽ RocksDB ചില രസകരമായ അഭിപ്രായങ്ങൾ ഉണ്ട്. ഉദാഹരണത്തിന്, ഇത് കോൾ പോലെ കാണപ്പെടുന്നു sync_file_range() ZFS ഉപയോഗിക്കുമ്പോൾ, അത് ഡിസ്കിലേക്ക് ഡാറ്റ ഫ്ലഷ് ചെയ്യുന്നില്ല. അപൂർവ്വമായി ഉപയോഗിക്കുന്ന കോഡിൽ ബഗുകൾ ഉണ്ടാകാൻ സാധ്യതയുണ്ടെന്ന് അനുഭവം പറയുന്നു. അതിനാൽ, അത്യാവശ്യമല്ലാതെ ഈ സിസ്റ്റം കോൾ ഉപയോഗിക്കുന്നതിനെതിരെ ഞാൻ ഉപദേശിക്കുന്നു.

ഡാറ്റ സ്ഥിരത ഉറപ്പാക്കാൻ സഹായിക്കുന്ന സിസ്റ്റം കോളുകൾ

സ്ഥിരമായ I/O ഓപ്പറേഷനുകൾ നടത്താൻ മൂന്ന് സമീപനങ്ങളുണ്ടെന്ന് ഞാൻ നിഗമനത്തിലെത്തി. അവയ്‌ക്കെല്ലാം ഒരു ഫംഗ്‌ഷൻ കോൾ ആവശ്യമാണ് fsync() ഫയൽ സൃഷ്ടിച്ച ഡയറക്‌ടറിക്കായി. സമീപനങ്ങൾ ഇവയാണ്:

1. ഫംഗ്ഷൻ കോൾ fdatasync() അഥവാ fsync() ചടങ്ങിന് ശേഷം write() (ഉപയോഗിക്കുന്നതാണ് നല്ലത് fdatasync()).
2. ഒരു ഫ്ലാഗ് ഉപയോഗിച്ച് തുറന്ന ഒരു ഫയൽ ഡിസ്ക്രിപ്റ്റർ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്നു O_DSYNC അഥവാ O_SYNC (നല്ലത് - ഒരു പതാക ഉപയോഗിച്ച് O_DSYNC).
3. കമാൻഡ് ഉപയോഗം pwritev2() പതാകയുമായി RWF_DSYNC അഥവാ RWF_SYNC (വെയിലത്ത് ഒരു പതാക RWF_DSYNC).

പ്രകടന കുറിപ്പുകൾ

ഞാൻ പരിശോധിച്ച വിവിധ മെക്കാനിസങ്ങളുടെ പ്രകടനം ഞാൻ ശ്രദ്ധാപൂർവ്വം അളന്നിട്ടില്ല. അവരുടെ ജോലിയുടെ വേഗതയിൽ ഞാൻ ശ്രദ്ധിച്ച വ്യത്യാസങ്ങൾ വളരെ ചെറുതാണ്. ഇതിനർത്ഥം ഞാൻ തെറ്റ് ചെയ്തേക്കാം, വ്യത്യസ്ത സാഹചര്യങ്ങളിൽ ഒരേ കാര്യം വ്യത്യസ്ത ഫലങ്ങൾ ഉണ്ടാക്കിയേക്കാം എന്നാണ്. ആദ്യം, പ്രകടനത്തെ കൂടുതൽ ബാധിക്കുന്ന കാര്യങ്ങളെക്കുറിച്ച് ഞാൻ സംസാരിക്കും, തുടർന്ന് പ്രകടനത്തെ കുറച്ച് ബാധിക്കുന്നത്.

1. ഫയൽ ഡാറ്റ ഓവർറൈറ്റിംഗ് ഒരു ഫയലിലേക്ക് ഡാറ്റ കൂട്ടിച്ചേർക്കുന്നതിനേക്കാൾ വേഗതയുള്ളതാണ് (പ്രകടന നേട്ടം 2-100% ആകാം). ഒരു ഫയലിലേക്ക് ഡാറ്റ അറ്റാച്ചുചെയ്യുന്നതിന്, സിസ്റ്റം കോളിന് ശേഷവും ഫയലിന്റെ മെറ്റാഡാറ്റയിൽ അധിക മാറ്റങ്ങൾ ആവശ്യമാണ് fallocate(), എന്നാൽ ഈ ഫലത്തിന്റെ വ്യാപ്തി വ്യത്യാസപ്പെടാം. മികച്ച പ്രകടനത്തിനായി, വിളിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു fallocate() ആവശ്യമായ സ്ഥലം മുൻകൂട്ടി അനുവദിക്കുന്നതിന്. അപ്പോൾ ഈ ഇടം വ്യക്തമായി പൂജ്യങ്ങൾ കൊണ്ട് പൂരിപ്പിച്ച് വിളിക്കണം fsync(). ഫയൽ സിസ്റ്റത്തിലെ അനുബന്ധ ബ്ലോക്കുകൾ "അൺലോക്കേറ്റ്" എന്നതിനുപകരം "അലോക്കേറ്റഡ്" എന്ന് അടയാളപ്പെടുത്തുന്നതിന് ഇത് കാരണമാകും. ഇത് ഒരു ചെറിയ (ഏകദേശം 2%) പ്രകടന മെച്ചപ്പെടുത്തൽ നൽകുന്നു. കൂടാതെ, ചില ഡിസ്കുകൾക്ക് മറ്റുള്ളവയേക്കാൾ വേഗത കുറഞ്ഞ ആദ്യ ബ്ലോക്ക് ആക്സസ് ഓപ്പറേഷൻ ഉണ്ടായിരിക്കാം. ഇതിനർത്ഥം പൂജ്യങ്ങൾ ഉപയോഗിച്ച് സ്ഥലം പൂരിപ്പിക്കുന്നത് ഒരു കാര്യമായ (ഏകദേശം 100%) പ്രകടന മെച്ചപ്പെടുത്തലിലേക്ക് നയിക്കും എന്നാണ്. പ്രത്യേകിച്ചും, ഇത് ഡിസ്കുകളിൽ സംഭവിക്കാം. AWS EBS (ഇത് അനൗദ്യോഗിക ഡാറ്റയാണ്, എനിക്ക് ഇത് സ്ഥിരീകരിക്കാൻ കഴിഞ്ഞില്ല). സംഭരണത്തിന്റെ കാര്യത്തിലും ഇതുതന്നെ പോകുന്നു ജിസിപി പെർസിസ്റ്റന്റ് ഡിസ്ക് (ഇത് ഇതിനകം ഔദ്യോഗിക വിവരമാണ്, ടെസ്റ്റുകൾ സ്ഥിരീകരിച്ചു). മറ്റ് വിദഗ്ധരും ഇതുതന്നെ ചെയ്തു നിരീക്ഷണംവ്യത്യസ്ത ഡിസ്കുകളുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു.
2. കുറച്ച് സിസ്റ്റം കോളുകൾ, ഉയർന്ന പ്രകടനം (നേട്ടം ഏകദേശം 5% ആകാം). ഒരു കോൾ പോലെ തോന്നുന്നു open() പതാകയുമായി O_DSYNC അല്ലെങ്കിൽ വിളിക്കുക pwritev2() പതാകയുമായി RWF_SYNC വേഗത്തിലുള്ള കോൾ fdatasync(). ഒരേ പ്രശ്നം പരിഹരിക്കാൻ കുറച്ച് സിസ്റ്റം കോളുകൾ നടത്തേണ്ടിവരുമെന്ന വസ്തുതയിൽ ഈ സമീപനത്തിന് ഒരു പങ്കുണ്ട് എന്നതാണ് ഇവിടെയുള്ള കാര്യം എന്ന് ഞാൻ സംശയിക്കുന്നു (രണ്ടിന് പകരം ഒരു കോൾ). എന്നാൽ പ്രകടനത്തിലെ വ്യത്യാസം വളരെ ചെറുതാണ്, അതിനാൽ നിങ്ങൾക്ക് ഇത് പൂർണ്ണമായും അവഗണിക്കാനും അതിന്റെ യുക്തിയെ സങ്കീർണ്ണമാക്കാത്ത എന്തെങ്കിലും ആപ്ലിക്കേഷനിൽ ഉപയോഗിക്കാനും കഴിയും.

നിങ്ങൾക്ക് സുസ്ഥിര ഡാറ്റ സംഭരണ ​​വിഷയത്തിൽ താൽപ്പര്യമുണ്ടെങ്കിൽ, ചില ഉപയോഗപ്രദമായ മെറ്റീരിയലുകൾ ഇതാ:

• I/O ആക്സസ് രീതികൾ — ഇൻപുട്ട് / ഔട്ട്പുട്ട് മെക്കാനിസങ്ങളുടെ അടിസ്ഥാന കാര്യങ്ങളുടെ ഒരു അവലോകനം.
• ഡാറ്റ ഡിസ്കിൽ എത്തുന്നുവെന്ന് ഉറപ്പാക്കുന്നു - ആപ്ലിക്കേഷനിൽ നിന്ന് ഡിസ്കിലേക്കുള്ള വഴിയിൽ ഡാറ്റയ്ക്ക് എന്ത് സംഭവിക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള ഒരു സ്റ്റോറി.
• എപ്പോഴാണ് നിങ്ങൾ അടങ്ങുന്ന ഡയറക്ടറി fsync ചെയ്യേണ്ടത് - എപ്പോൾ ഉപയോഗിക്കണം എന്ന ചോദ്യത്തിനുള്ള ഉത്തരം fsync() ഡയറക്ടറികൾക്കായി. ഇത് ചുരുക്കത്തിൽ പറഞ്ഞാൽ, ഒരു പുതിയ ഫയൽ സൃഷ്ടിക്കുമ്പോൾ നിങ്ങൾ ഇത് ചെയ്യേണ്ടതുണ്ട്, ലിനക്സിൽ ഒരേ ഫയലിലേക്ക് നിരവധി റഫറൻസുകൾ ഉണ്ടാകാം എന്നതാണ് ഈ ശുപാർശയുടെ കാരണം.
• ലിനക്സിലെ SQL സെർവർ: FUA ഇന്റേണൽസ് — Linux പ്ലാറ്റ്‌ഫോമിലെ SQL സെർവറിൽ എങ്ങനെയാണ് സ്ഥിരമായ ഡാറ്റ സംഭരണം നടപ്പിലാക്കുന്നത് എന്നതിന്റെ ഒരു വിവരണം ഇവിടെയുണ്ട്. വിൻഡോസ്, ലിനക്സ് സിസ്റ്റം കോളുകൾ തമ്മിൽ രസകരമായ ചില താരതമ്യങ്ങൾ ഇവിടെയുണ്ട്. XFS-ന്റെ FUA ഒപ്റ്റിമൈസേഷനെ കുറിച്ച് ഞാൻ മനസ്സിലാക്കിയത് ഈ മെറ്റീരിയലിന് നന്ദിയാണെന്ന് എനിക്ക് ഏതാണ്ട് ഉറപ്പുണ്ട്.

ഒരു ഡിസ്കിൽ സുരക്ഷിതമായി സംഭരിച്ചിട്ടുണ്ടെന്ന് നിങ്ങൾ കരുതുന്ന ഡാറ്റ നഷ്ടപ്പെട്ടോ?

അവലംബം: www.habr.com