WAL-G-ൽ നിന്നുള്ള ബാക്കപ്പുകൾ. 2019 ൽ എന്താണ് ഉള്ളത്? ആൻഡ്രി ബോറോഡിൻ

ആന്ദ്രേ ബോറോഡിൻ "WAL-G-യ്‌ക്കൊപ്പം ബാക്കപ്പുകൾ. 2019-ൽ എന്താണ്?"

എല്ലാവർക്കും ഹായ്! എന്റെ പേര് ആൻഡ്രി ബോറോഡിൻ. ഞാൻ Yandex-ൽ ഒരു ഡെവലപ്പറാണ്. 2016 മുതൽ എനിക്ക് PostgreSQL-ൽ താൽപ്പര്യമുണ്ട്, ഞാൻ ഡവലപ്പർമാരുമായി സംസാരിച്ചതിന് ശേഷം എല്ലാം ലളിതമാണെന്ന് അവർ പറഞ്ഞു - നിങ്ങൾ സോഴ്‌സ് കോഡ് എടുത്ത് അത് നിർമ്മിക്കുക, എല്ലാം പ്രവർത്തിക്കും. അതിനുശേഷം എനിക്ക് നിർത്താൻ കഴിയില്ല - ഞാൻ എല്ലാത്തരം വ്യത്യസ്ത കാര്യങ്ങളും എഴുതുന്നു.

ഞാൻ പ്രവർത്തിച്ചുകൊണ്ടിരിക്കുന്ന കാര്യങ്ങളിലൊന്ന് ഒരു ബാക്കപ്പ് സംവിധാനമാണ്. WAL-G. പൊതുവേ, Yandex-ൽ ഞങ്ങൾ വളരെക്കാലമായി PostgreSQL-ലെ ബാക്കപ്പ് സിസ്റ്റങ്ങളിൽ പ്രവർത്തിക്കുന്നു. ഞങ്ങൾ എങ്ങനെ ബാക്കപ്പ് സംവിധാനങ്ങൾ ഉണ്ടാക്കുന്നു എന്നതിനെക്കുറിച്ചുള്ള ആറ് റിപ്പോർട്ടുകളുടെ ഒരു പരമ്പര നിങ്ങൾക്ക് ഇന്റർനെറ്റിൽ കണ്ടെത്താനാകും. എല്ലാ വർഷവും അവർ അൽപ്പം വികസിക്കുകയും കുറച്ച് വികസിപ്പിക്കുകയും കൂടുതൽ വിശ്വസനീയമാവുകയും ചെയ്യുന്നു.

എന്നാൽ ഇന്ന് റിപ്പോർട്ട് നമ്മൾ ചെയ്ത കാര്യങ്ങൾ മാത്രമല്ല, അത് എത്ര ലളിതമാണ്, എന്താണ് എന്നതും കൂടിയാണ്. WAL-G-യെക്കുറിച്ചുള്ള എന്റെ റിപ്പോർട്ടുകൾ നിങ്ങളിൽ എത്ര പേർ ഇതിനകം കണ്ടു? കുറച്ച് ആളുകൾ കാണാത്തത് നല്ലതാണ്, കാരണം ഞാൻ ഏറ്റവും ലളിതമായ കാര്യത്തിൽ നിന്ന് ആരംഭിക്കാം.

നിങ്ങൾക്ക് പെട്ടെന്ന് ഒരു PostgreSQL ക്ലസ്റ്റർ ഉണ്ടെങ്കിൽ, എല്ലാവർക്കും അവരുടെ പക്കൽ രണ്ടെണ്ണം ഉണ്ടെന്ന് ഞാൻ കരുതുന്നു, പെട്ടെന്ന് ഇതുവരെ ബാക്കപ്പ് സിസ്റ്റം ഇല്ലെങ്കിൽ, നിങ്ങൾക്ക് ഏതെങ്കിലും S3 സംഭരണമോ Google ക്ലൗഡ് അനുയോജ്യമായ സംഭരണമോ ലഭിക്കേണ്ടതുണ്ട്.

ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് ഞങ്ങളുടെ നിലപാടിലേക്ക് വന്ന് Yandex ഒബ്ജക്റ്റ് സ്റ്റോറേജിനായി ഒരു പ്രൊമോഷണൽ കോഡ് എടുക്കാം, അത് S3 അനുയോജ്യമാണ്.

എന്നിട്ട് ഒരു ബക്കറ്റ് ഉണ്ടാക്കുക. ഇത് വിവരങ്ങൾക്കുള്ള ഒരു കണ്ടെയ്‌നർ മാത്രമാണ്.

ഒരു സേവന ഉപയോക്താവിനെ സൃഷ്ടിക്കുക.

സേവന ഉപയോക്താവിനായി ഒരു ആക്സസ് കീ സൃഷ്ടിക്കുക: aws-s3-key.

WAL-G-യുടെ ഏറ്റവും പുതിയ സ്ഥിരതയുള്ള റിലീസ് ഡൗൺലോഡ് ചെയ്യുക.

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

നിങ്ങൾ WAL-G ഡൗൺലോഡ് ചെയ്‌തുകഴിഞ്ഞാൽ, എൻവയോൺമെന്റ് വേരിയബിളുകളിലൂടെ കടന്നുപോകുന്ന ലളിതമായ “ബാക്കപ്പ് ലിസ്റ്റ്” കമാൻഡ് പ്രവർത്തിപ്പിക്കാം. കൂടാതെ ഇത് ഒബ്‌ജക്റ്റ് സ്റ്റോറേജിലേക്ക് കണക്റ്റുചെയ്യുകയും നിങ്ങളുടെ ബാക്കപ്പ് എന്താണെന്ന് പറയുകയും ചെയ്യും. ആദ്യം, തീർച്ചയായും, നിങ്ങൾക്ക് ബാക്കപ്പുകൾ ഉണ്ടാകരുത്. എല്ലാം വളരെ ലളിതമാണെന്ന് കാണിക്കുക എന്നതാണ് ഈ സ്ലൈഡിന്റെ പോയിന്റ്. എൻവയോൺമെന്റ് വേരിയബിളുകൾ സ്വീകരിക്കുകയും ഉപകമാൻഡുകൾ നടപ്പിലാക്കുകയും ചെയ്യുന്ന ഒരു കൺസോൾ കമാൻഡാണിത്.

ഇതിനുശേഷം, നിങ്ങളുടെ ആദ്യ ബാക്കപ്പ് ഉണ്ടാക്കാം. WAL-G-ൽ "ബാക്കപ്പ്-പുഷ്" എന്ന് പറയുകയും WAL-G-ൽ നിങ്ങളുടെ ക്ലസ്റ്ററിന്റെ pgdata ലൊക്കേഷൻ വ്യക്തമാക്കുകയും ചെയ്യുക. മിക്കവാറും, നിങ്ങൾക്ക് ഇതിനകം ഒരു ബാക്കപ്പ് സിസ്റ്റം ഇല്ലെങ്കിൽ, നിങ്ങൾ "ആർക്കൈവ്-മോഡ്" പ്രവർത്തനക്ഷമമാക്കേണ്ടതുണ്ടെന്ന് PostgreSQL നിങ്ങളോട് പറയും.

ഇതിനർത്ഥം നിങ്ങൾ ക്രമീകരണങ്ങളിലേക്ക് പോയി “ആർക്കൈവ്_മോഡ് = ഓൺ” ഓൺ ചെയ്യുകയും “ആർക്കൈവ്_കമാൻഡ്” ചേർക്കുകയും വേണം, ഇത് WAL-G-യിലെ ഒരു ഉപകമാൻഡ് കൂടിയാണ്. എന്നാൽ ചില കാരണങ്ങളാൽ ആളുകൾ പലപ്പോഴും ഈ വിഷയത്തിൽ ബാർ സ്ക്രിപ്റ്റുകൾ ഉപയോഗിക്കുകയും അത് WAL-G ന് ചുറ്റും പൊതിയുകയും ചെയ്യുന്നു. ദയവായി ഇത് ചെയ്യരുത്. WAL-G-ൽ കാണുന്ന പ്രവർത്തനം ഉപയോഗിക്കുക. നിങ്ങൾക്ക് എന്തെങ്കിലും നഷ്ടമായാൽ, എഴുതുക സാമൂഹികം. archive_command-ൽ പ്രവർത്തിക്കുന്ന ഒരേയൊരു പ്രോഗ്രാം ഇതാണ് എന്ന് WAL-G അനുമാനിക്കുന്നു.

Yandex ഡാറ്റാബേസ് മാനേജ്മെന്റിൽ ഉയർന്ന ലഭ്യതയുള്ള ഒരു ക്ലസ്റ്റർ സൃഷ്ടിക്കാൻ ഞങ്ങൾ പ്രധാനമായും WAL-G ഉപയോഗിക്കുന്നു.

ഇത് സാധാരണയായി ഒരു മാസ്റ്ററുടെ ടോപ്പോളജിയിലും നിരവധി പകർപ്പുകളിലും ഉപയോഗിക്കുന്നു. അതേ സമയം, ഇത് Yandex ഒബ്ജക്റ്റ് സ്റ്റോറേജിൽ ഒരു ബാക്കപ്പ് പകർപ്പ് ഉണ്ടാക്കുന്നു.

പോയിന്റ് ഇൻ ടൈം റിക്കവറി ഉപയോഗിച്ച് ഒരു ക്ലസ്റ്ററിന്റെ പകർപ്പുകൾ സൃഷ്ടിക്കുന്നതാണ് ഏറ്റവും സാധാരണമായ സാഹചര്യങ്ങൾ. എന്നാൽ ഈ സാഹചര്യത്തിൽ, ബാക്കപ്പ് സിസ്റ്റത്തിന്റെ പ്രകടനം ഞങ്ങൾക്ക് അത്ര പ്രധാനമല്ല. ബാക്കപ്പിൽ നിന്ന് ഞങ്ങൾക്ക് ഒരു പുതിയ ക്ലസ്റ്റർ അപ്‌ലോഡ് ചെയ്യേണ്ടതുണ്ട്.

സാധാരണഗതിയിൽ, ഒരു പുതിയ നോഡ് ചേർക്കുമ്പോൾ ഞങ്ങൾക്ക് ബാക്കപ്പ് സിസ്റ്റം പ്രകടനം ആവശ്യമാണ്. എന്തുകൊണ്ട് അത് പ്രധാനമാണ്? സാധാരണയായി ആളുകൾ ഒരു ക്ലസ്റ്ററിലേക്ക് ഒരു പുതിയ നോഡ് ചേർക്കുന്നു, കാരണം നിലവിലുള്ള ക്ലസ്റ്ററിന് റീഡ് ലോഡ് കൈകാര്യം ചെയ്യാൻ കഴിയില്ല. അവർക്ക് ഒരു പുതിയ പകർപ്പ് ചേർക്കേണ്ടതുണ്ട്. pg_basebackup-ൽ നിന്ന് Master-ലേക്ക് ലോഡ് ചേർത്താൽ, Master തകർന്നേക്കാം. അതിനാൽ, ആർക്കൈവിൽ നിന്ന് ഒരു പുതിയ നോഡ് വേഗത്തിൽ അപ്‌ലോഡ് ചെയ്യാൻ കഴിയുന്നത് ഞങ്ങൾക്ക് വളരെ പ്രധാനമായിരുന്നു, ഇത് മാസ്റ്ററിൽ കുറഞ്ഞ ലോഡ് സൃഷ്ടിക്കുന്നു.

ഒപ്പം സമാനമായ മറ്റൊരു സാഹചര്യവും. കണക്റ്റിവിറ്റി നഷ്ടപ്പെട്ട ഡാറ്റാ സെന്ററിൽ നിന്ന് ക്ലസ്റ്റർ മാസ്റ്റർ മാറ്റി പഴയ മാസ്റ്റർ പുനരാരംഭിക്കേണ്ടത് ഇതാണ്.

• തൽഫലമായി, കോപ്പി സിസ്റ്റത്തിന്റെ ആവശ്യകതകൾ രൂപപ്പെടുത്തുമ്പോൾ, ക്ലൗഡിൽ പ്രവർത്തിക്കുമ്പോൾ pg_basebackup ഞങ്ങൾക്ക് അനുയോജ്യമല്ലെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി.
• ഞങ്ങളുടെ ഡാറ്റ കംപ്രസ്സുചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. എന്നാൽ ബോക്സിൽ വരുന്നതല്ലാതെ മറ്റേതൊരു ബാക്കപ്പ് സിസ്റ്റവും ഡാറ്റ കംപ്രഷൻ നൽകും.
• ക്ലൗഡിലെ ഒരു ഉപയോക്താവ് ധാരാളം പ്രോസസർ കോറുകൾ വാങ്ങുന്നതിനാൽ എല്ലാം സമാന്തരമാക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു. എന്നാൽ ചില പ്രവർത്തനങ്ങളിൽ നമുക്ക് സമാന്തരത ഇല്ലെങ്കിൽ, ഒരു വലിയ എണ്ണം കോറുകൾ ഉപയോഗശൂന്യമാകും.
• ഞങ്ങൾക്ക് എൻക്രിപ്ഷൻ ആവശ്യമാണ്, കാരണം പലപ്പോഴും ഡാറ്റ നമ്മുടേതല്ല, വ്യക്തമായ ടെക്സ്റ്റിൽ സൂക്ഷിക്കാൻ കഴിയില്ല. WAL-G-ലേക്കുള്ള ഞങ്ങളുടെ സംഭാവന എൻക്രിപ്ഷനിൽ നിന്നാണ് ആരംഭിച്ചത്. ഞങ്ങൾ WAL-G-യിൽ എൻക്രിപ്ഷൻ പൂർത്തിയാക്കി, അതിന് ശേഷം ഞങ്ങളോട് ചോദിച്ചു: "ഒരുപക്ഷേ ഞങ്ങളിൽ ആരെങ്കിലും പദ്ധതി വികസിപ്പിക്കുമോ?" അതിനുശേഷം ഞാൻ ഒരു വർഷത്തിലേറെയായി WAL-G-യിൽ പ്രവർത്തിക്കുന്നു.
• ഞങ്ങൾക്ക് റിസോഴ്‌സ് ത്രോട്ടിംഗും ആവശ്യമാണ്, കാരണം കാലക്രമേണ ക്ലൗഡ് ഉപയോഗിക്കുമ്പോൾ, ചിലപ്പോൾ ആളുകൾക്ക് രാത്രിയിൽ പ്രധാനപ്പെട്ട പലചരക്ക് സാധനങ്ങൾ ഉണ്ടെന്നും ഈ ലോഡിൽ ഇടപെടാൻ കഴിയില്ലെന്നും ഞങ്ങൾ കണ്ടെത്തി. അതുകൊണ്ടാണ് ഞങ്ങൾ റിസോഴ്സ് ത്രോട്ടിംഗ് ചേർത്തത്.
• അതുപോലെ ലിസ്റ്റിംഗും മാനേജ്മെന്റും.
• ഒപ്പം സ്ഥിരീകരണവും.

ഞങ്ങൾ നിരവധി വ്യത്യസ്ത ഉപകരണങ്ങൾ നോക്കി. ഭാഗ്യവശാൽ, PostgreSQL-ൽ ഞങ്ങൾക്ക് ഒരു വലിയ തിരഞ്ഞെടുപ്പ് ഉണ്ട്. എല്ലായിടത്തും ഞങ്ങൾക്ക് എന്തെങ്കിലും നഷ്‌ടപ്പെട്ടു, ചിലത് ഒരു ചെറിയ പ്രവർത്തനം, ചിലത് ഒരു ചെറിയ സവിശേഷത.

നിലവിലുള്ള സംവിധാനങ്ങൾ പരിശോധിച്ച ശേഷം, ഞങ്ങൾ WAL-G വികസിപ്പിക്കുമെന്ന നിഗമനത്തിലെത്തി. അന്ന് അതൊരു പുതിയ പ്രൊജക്ടായിരുന്നു. ബാക്കപ്പ് സിസ്റ്റത്തിന്റെ ക്ലൗഡ് ഇൻഫ്രാസ്ട്രക്ചറിലേക്കുള്ള വികസനത്തെ സ്വാധീനിക്കുന്നത് വളരെ എളുപ്പമായിരുന്നു.

WAL-G ഒരു ബാലലൈക പോലെ ലളിതമായിരിക്കണം എന്നതാണ് ഞങ്ങൾ പാലിക്കുന്ന പ്രധാന പ്രത്യയശാസ്ത്രം.

WAL-G ന് 4 കമാൻഡുകൾ ഉണ്ട്. ഈ:

വാൾ-പുഷ് - ഷാഫ്റ്റ് ആർക്കൈവ് ചെയ്യുക.

വാൾ-ഫെച്ച് - ഒരു ഷാഫ്റ്റ് നേടുക.

ബാക്കപ്പ്-പുഷ് - ഒരു ബാക്കപ്പ് ഉണ്ടാക്കുക.

ബാക്കപ്പ്-ഫെച്ച് - ബാക്കപ്പ് സിസ്റ്റത്തിൽ നിന്ന് ഒരു ബാക്കപ്പ് നേടുക.

വാസ്തവത്തിൽ, WAL-G ന് ഈ ബാക്കപ്പുകളുടെ മാനേജ്മെന്റും ഉണ്ട്, അതായത് ചരിത്രത്തിലെ റെക്കോർഡുകളും ബാക്കപ്പുകളും ഇപ്പോൾ ആവശ്യമില്ലാത്ത ലിസ്റ്റിംഗും ഇല്ലാതാക്കലും.

ഡെൽറ്റ പകർപ്പുകൾ സൃഷ്ടിക്കുന്നതിനുള്ള പ്രവർത്തനമാണ് ഞങ്ങൾക്ക് പ്രധാന പ്രവർത്തനങ്ങളിലൊന്ന്.

ഡെൽറ്റ പകർപ്പുകൾ അർത്ഥമാക്കുന്നത് ഞങ്ങൾ മുഴുവൻ ക്ലസ്റ്ററിന്റെയും പൂർണ്ണ ബാക്കപ്പ് സൃഷ്ടിക്കുന്നില്ല, മറിച്ച് ക്ലസ്റ്ററിലെ മാറിയ ഫയലുകളുടെ മാറിയ പേജുകൾ മാത്രമാണ്. പ്രവർത്തനപരമായി ഇത് WAL ഉപയോഗിച്ച് വീണ്ടെടുക്കാനുള്ള കഴിവുമായി വളരെ സാമ്യമുള്ളതാണെന്ന് തോന്നുന്നു. എന്നാൽ നമുക്ക് ഒരു WAL സിംഗിൾ-ത്രെഡ് ഡെൽറ്റ ബാക്കപ്പ് സമാന്തരമായി റോൾ അപ്പ് ചെയ്യാം. അതനുസരിച്ച്, ഞങ്ങൾക്ക് ശനിയാഴ്ച ഒരു അടിസ്ഥാന ബാക്കപ്പ് ഉണ്ടായിരിക്കുമ്പോൾ, ഡെൽറ്റ ബാക്കപ്പുകൾ ദിവസവും, വ്യാഴാഴ്ച ഞങ്ങൾ പരാജയപ്പെടുമ്പോൾ, ഞങ്ങൾ 4 ഡെൽറ്റ ബാക്കപ്പുകളും 10 മണിക്കൂർ WAL-നും റോൾ അപ്പ് ചെയ്യേണ്ടതുണ്ട്. ഡെൽറ്റ ബാക്കപ്പുകൾ സമാന്തരമായി റോൾ ചെയ്യുന്നതിനാൽ ഏകദേശം ഒരേ സമയമെടുക്കും.

LSN-അധിഷ്‌ഠിത ഡെൽറ്റകൾ - ഇതിനർത്ഥം, ഒരു ബാക്കപ്പ് സൃഷ്‌ടിക്കുമ്പോൾ, ഞങ്ങൾ ഓരോ പേജും സംയോജിപ്പിച്ച് അതിന്റെ LSN മുമ്പത്തെ ബാക്കപ്പിന്റെ LSN-മായി പരിശോധിച്ച് അത് മാറിയെന്ന് മനസ്സിലാക്കേണ്ടതുണ്ട്. മാറ്റിയ ഡാറ്റ അടങ്ങിയിരിക്കാൻ സാധ്യതയുള്ള ഏത് പേജും ഡെൽറ്റ ബാക്കപ്പിൽ ഉണ്ടായിരിക്കണം.

ഞാൻ പറഞ്ഞതുപോലെ, സമാന്തരതയിൽ വളരെയധികം ശ്രദ്ധ ചെലുത്തി.

എന്നാൽ PostgreSQL-ലെ ആർക്കൈവ് API സ്ഥിരതയുള്ളതാണ്. PostgreSQL ഒരു WAL ഫയൽ ആർക്കൈവ് ചെയ്യുന്നു, അത് പുനഃസ്ഥാപിക്കുമ്പോൾ ഒരു WAL ഫയൽ അഭ്യർത്ഥിക്കുന്നു. എന്നാൽ "WAL-FETCH" കമാൻഡ് ഉപയോഗിച്ച് ഡാറ്റാബേസ് ഒരു WAL ഫയൽ അഭ്യർത്ഥിക്കുമ്പോൾ, നമ്മൾ "WAL-PREFETCH" കമാൻഡ് എന്ന് വിളിക്കുന്നു, അത് സമാന്തരമായി ഒബ്ജക്റ്റ് സ്റ്റോറിൽ നിന്ന് ഡാറ്റ ലഭ്യമാക്കുന്നതിന് അടുത്ത 8 ഫയലുകൾ തയ്യാറാക്കുന്നു.

ഒരു ഫയൽ ആർക്കൈവ് ചെയ്യാൻ ഡാറ്റാബേസ് ആവശ്യപ്പെടുമ്പോൾ, ഞങ്ങൾ archive_status നോക്കുകയും മറ്റ് WAL ഫയലുകൾ ഉണ്ടോ എന്ന് നോക്കുകയും ചെയ്യുന്നു. ഒപ്പം WAL സമാന്തരമായി ഡൗൺലോഡ് ചെയ്യാനും ഞങ്ങൾ ശ്രമിക്കുന്നു. ഇത് കാര്യമായ പ്രകടന നേട്ടം നൽകുകയും ആർക്കൈവ് ചെയ്യാത്ത WAL-കളുടെ എണ്ണത്തിലെ ദൂരം ഗണ്യമായി കുറയ്ക്കുകയും ചെയ്യുന്നു. പോസ്റ്റ്‌ഗ്രെഎസ്‌ക്യുഎൽ എപിഐ അല്ലാത്ത കോഡിന്റെ ഇന്റേണലുകളെക്കുറിച്ചുള്ള ഞങ്ങളുടെ അറിവിനെ ഞങ്ങൾ ആശ്രയിക്കുന്നതിനാൽ ഇത് അപകടകരമായ ഒരു സിസ്റ്റമാണെന്ന് പല ബാക്കപ്പ് സിസ്റ്റം ഡെവലപ്പർമാരും വിശ്വസിക്കുന്നു. PostgreSQL ഞങ്ങൾക്ക് ആർക്കൈവ്_സ്റ്റാറ്റസ് ഫോൾഡറിന്റെ സാന്നിധ്യം ഉറപ്പുനൽകുന്നില്ല, കൂടാതെ സെമാന്റിക്‌സ്, അവിടെയുള്ള WAL ഫയലുകൾക്കുള്ള റെഡിനസ് സിഗ്നലുകളുടെ സാന്നിധ്യം എന്നിവ ഉറപ്പുനൽകുന്നില്ല. എന്നിരുന്നാലും, ഞങ്ങൾ സോഴ്‌സ് കോഡ് പഠിക്കുകയാണ്, ഇത് അങ്ങനെയാണെന്ന് ഞങ്ങൾ കാണുകയും അത് ചൂഷണം ചെയ്യാൻ ശ്രമിക്കുകയും ചെയ്യുന്നു. PostgreSQL വികസിക്കുന്ന ദിശ ഞങ്ങൾ നിയന്ത്രിക്കുന്നു; പെട്ടെന്ന് ഈ സംവിധാനം തകരാറിലാണെങ്കിൽ, ഞങ്ങൾ അത് ഉപയോഗിക്കുന്നത് നിർത്തും.

അതിന്റെ ശുദ്ധമായ രൂപത്തിൽ, മുമ്പത്തെ ബാക്കപ്പിന് ശേഷം ഫയൽ സിസ്റ്റത്തിലെ മോഡ്-ടൈം മാറിയ ഏതെങ്കിലും ക്ലസ്റ്റർ ഫയലുകൾ LSN-അധിഷ്ഠിത WAL ഡെൽറ്റയ്ക്ക് വായിക്കേണ്ടതുണ്ട്. ഞങ്ങൾ ഇതുമായി വളരെക്കാലം ജീവിച്ചു, ഏകദേശം ഒരു വർഷം. അവസാനം ഞങ്ങൾക്ക് WAL ഡെൽറ്റകളുണ്ടെന്ന നിഗമനത്തിലെത്തി.

ഇതിനർത്ഥം, ഓരോ തവണയും നമ്മൾ WAL മാസ്റ്ററിൽ ആർക്കൈവ് ചെയ്യുമ്പോൾ, ഞങ്ങൾ അത് കംപ്രസ്സുചെയ്യുകയും എൻക്രിപ്റ്റ് ചെയ്യുകയും നെറ്റ്‌വർക്കിലേക്ക് അയയ്ക്കുകയും ചെയ്യുക മാത്രമല്ല, ഞങ്ങൾ അത് ഒരേ സമയം വായിക്കുകയും ചെയ്യുന്നു. അതിലെ രേഖകൾ ഞങ്ങൾ വിശകലനം ചെയ്യുകയും വായിക്കുകയും ചെയ്യുന്നു. ഏതൊക്കെ ബ്ലോക്കുകളാണ് മാറിയതെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുകയും ഡെൽറ്റ ഫയലുകൾ ശേഖരിക്കുകയും ചെയ്യുന്നു.

ഒരു ഡെൽറ്റ ഫയൽ WAL ഫയലുകളുടെ ഒരു നിശ്ചിത ശ്രേണിയെ വിവരിക്കുന്നു, ഈ WAL ശ്രേണിയിൽ ഏതൊക്കെ ബ്ലോക്കുകളാണ് മാറ്റിയത് എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ വിവരിക്കുന്നു. തുടർന്ന് ഈ ഡെൽറ്റ ഫയലുകളും ആർക്കൈവുചെയ്‌തു.

ഞങ്ങൾ എല്ലാം വളരെ വേഗത്തിൽ സമാന്തരമാക്കി എന്ന വസ്തുത ഇവിടെ ഞങ്ങൾ അഭിമുഖീകരിക്കുന്നു, പക്ഷേ നമുക്ക് ഒരു തുടർച്ചയായ ചരിത്രം സമാന്തരമായി വായിക്കാൻ കഴിയില്ല, കാരണം ഒരു പ്രത്യേക സെഗ്‌മെന്റിൽ മുമ്പത്തെ WAL റെക്കോർഡിന്റെ അവസാനം നമുക്ക് നേരിടാം, അത് ഇതുവരെ കണക്റ്റുചെയ്യാൻ ഒന്നുമില്ല, കാരണം സമാന്തര വായന, ഇതുവരെ ഒരു ഭൂതകാലമില്ലാത്ത ഭാവിയെ ഞങ്ങൾ ആദ്യം വിശകലനം ചെയ്യുന്നതിലേക്ക് നയിച്ചു.

തൽഫലമായി, ഞങ്ങൾക്ക് മനസ്സിലാക്കാൻ കഴിയാത്ത ഭാഗങ്ങൾ _delta_partial ഫയലുകളിൽ ഇടേണ്ടി വന്നു. തൽഫലമായി, ഞങ്ങൾ ഭൂതകാലത്തിലേക്ക് മടങ്ങുമ്പോൾ, WAL റെക്കോർഡിന്റെ ഭാഗങ്ങൾ ഒന്നായി ഒട്ടിക്കും, അതിനുശേഷം ഞങ്ങൾ അത് പാഴ്‌സ് ചെയ്യുകയും അതിൽ എന്താണ് മാറിയതെന്ന് മനസിലാക്കുകയും ചെയ്യും.

ഞങ്ങളുടെ ഷാഫ്റ്റ് പാഴ്‌സിംഗിന്റെ ചരിത്രത്തിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് ഞങ്ങൾക്ക് മനസ്സിലാകാത്ത ഒരു പോയിന്റെങ്കിലും ഉണ്ടെങ്കിൽ, അതനുസരിച്ച്, അടുത്ത ബാക്കപ്പ് സമയത്ത്, ഞങ്ങൾ ഒരു സാധാരണ എൽഎസ്‌എൻ ഉപയോഗിച്ചതുപോലെ മുഴുവൻ ക്ലസ്റ്ററും വീണ്ടും വായിക്കാൻ നിർബന്ധിതരാകും. -അധിഷ്ഠിത ഡെൽറ്റ.

തൽഫലമായി, ഞങ്ങളുടെ എല്ലാ കഷ്ടപ്പാടുകളും ഞങ്ങൾ WAL-G പാഴ്‌സിംഗ് ലൈബ്രറി ഓപ്പൺ സോഴ്‌സ് ചെയ്തു എന്ന വസ്തുതയിലേക്ക് നയിച്ചു. എനിക്കറിയാവുന്നിടത്തോളം, ഇതുവരെ ആരും ഇത് ഉപയോഗിക്കുന്നില്ല, പക്ഷേ ആർക്കെങ്കിലും താൽപ്പര്യമുണ്ടെങ്കിൽ എഴുതുക, ഉപയോഗിക്കുക, അത് പൊതുസഞ്ചയത്തിലാണ്. (അപ്ഡേറ്റ് ചെയ്ത ലിങ്ക് https://github.com/wal-g/wal-g/tree/master/internal/walparser)

തൽഫലമായി, എല്ലാ വിവര പ്രവാഹങ്ങളും വളരെ സങ്കീർണ്ണമായി കാണപ്പെടുന്നു. ഞങ്ങളുടെ മാസ്റ്റർ ഷാഫ്റ്റ് ആർക്കൈവ് ചെയ്യുകയും ഡെൽറ്റ ഫയലുകൾ ആർക്കൈവ് ചെയ്യുകയും ചെയ്യുന്നു. ബാക്കപ്പ് പകർപ്പ് നിർമ്മിക്കുന്ന പകർപ്പിന് ബാക്കപ്പുകൾക്കിടയിൽ കടന്നുപോയ സമയത്ത് ഡെൽറ്റ ഫയലുകൾ ലഭിക്കണം. ഈ സാഹചര്യത്തിൽ, ചരിത്രത്തിന്റെ ഭാഗങ്ങൾ ബൾക്ക് ആയി കൂട്ടിച്ചേർക്കുകയും പാഴ്‌സ് ചെയ്യുകയും ചെയ്യേണ്ടതുണ്ട്, കാരണം മുഴുവൻ ചരിത്രവും വലിയ സെഗ്‌മെന്റുകളിലേക്ക് യോജിക്കുന്നില്ല. ഇതിനുശേഷം മാത്രമേ പകർപ്പിന് ഒരു പൂർണ്ണ ഡെൽറ്റ ബാക്കപ്പ് ആർക്കൈവ് ചെയ്യാൻ കഴിയൂ.

ഗ്രാഫുകളിൽ എല്ലാം വളരെ ലളിതമായി തോന്നുന്നു. ഇത് ഞങ്ങളുടെ യഥാർത്ഥ ക്ലസ്റ്ററുകളിലൊന്നിൽ നിന്നുള്ള ഡൗൺലോഡാണ്. ഒരു ദിവസം കൊണ്ട് ഉണ്ടാക്കിയ LSN അടിസ്ഥാനമാക്കിയുള്ളതാണ് ഞങ്ങളുടെ പക്കൽ. LSN അടിസ്ഥാനമാക്കിയുള്ള ഡെൽറ്റ ബാക്കപ്പ് പുലർച്ചെ മൂന്ന് മുതൽ പുലർച്ചെ അഞ്ച് വരെ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഞങ്ങൾ കാണുന്നു. പ്രോസസർ കോറുകളുടെ എണ്ണത്തിലെ ലോഡ് ഇതാണ്. WAL-delta ഞങ്ങൾക്ക് ഇവിടെ ഏകദേശം 20 മിനിറ്റ് എടുത്തു. അതായത്, അത് ഗണ്യമായി വേഗത്തിലായി, എന്നാൽ അതേ സമയം നെറ്റ്‌വർക്കിൽ കൂടുതൽ തീവ്രമായ കൈമാറ്റം നടന്നു.

ഡാറ്റാബേസിന്റെ ചരിത്രത്തിൽ ഏത് ബ്ലോക്കുകളാണ് മാറിയത്, ഏത് സമയത്താണ് മാറിയത് എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഞങ്ങളുടെ പക്കലുള്ളതിനാൽ, ഞങ്ങൾ കൂടുതൽ മുന്നോട്ട് പോയി പ്രവർത്തനക്ഷമത സംയോജിപ്പിക്കാൻ തീരുമാനിച്ചു - “pg_prefaulter” എന്ന് വിളിക്കുന്ന ഒരു PostgreSQL വിപുലീകരണം.

ഇതിനർത്ഥം സ്റ്റാൻഡ്-ബൈ ബേസ് പുനഃസ്ഥാപിക്കൽ കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ, അത് അടുത്ത WAL ഫയൽ ലഭ്യമാക്കാൻ WAL-G-നോട് പറയുന്നു എന്നാണ്. സമീപഭാവിയിൽ WAL വീണ്ടെടുക്കൽ പ്രക്രിയയെ തടയുന്ന ഡാറ്റ ഏതെന്ന് ഞങ്ങൾ മനസ്സിലാക്കുകയും ഈ ബ്ലോക്കുകളിൽ ഒരു റീഡ് ഓപ്പറേഷൻ ആരംഭിക്കുകയും ചെയ്യും. SSD കൺട്രോളറുകളുടെ പ്രകടനം വർദ്ധിപ്പിക്കുന്നതിനാണ് ഇത് ചെയ്തത്. കാരണം WAL റോൾ മാറ്റേണ്ട പേജിൽ എത്തും. ഈ പേജ് ഡിസ്കിലാണ്, പേജ് കാഷെയിലില്ല. ഈ പേജ് വരുന്നതുവരെ അവൻ സമന്വയത്തോടെ കാത്തിരിക്കും. എന്നാൽ തൊട്ടടുത്തുള്ള WAL-G ആണ്, അടുത്ത ഏതാനും നൂറ് മെഗാബൈറ്റ് WAL ൽ നമുക്ക് ചില പേജുകൾ ആവശ്യമാണെന്നും അതേ സമയം അവയെ ചൂടാക്കാൻ തുടങ്ങുമെന്നും അറിയുന്നു. ഒന്നിലധികം ഡിസ്ക് ആക്‌സസ്സുകൾ സമാന്തരമായി നടപ്പിലാക്കുന്നതിനായി അവ ആരംഭിക്കുന്നു. ഇത് SSD ഡ്രൈവുകളിൽ നന്നായി പ്രവർത്തിക്കുന്നു, പക്ഷേ, നിർഭാഗ്യവശാൽ, ഒരു ഹാർഡ് ഡ്രൈവിന് ഇത് തികച്ചും ബാധകമല്ല, കാരണം ഞങ്ങളുടെ നിർദ്ദേശങ്ങളിൽ മാത്രമേ ഞങ്ങൾ ഇടപെടുകയുള്ളൂ.

ഇതാണ് ഇപ്പോൾ കോഡിലുള്ളത്.

ഞങ്ങൾ ചേർക്കാൻ ആഗ്രഹിക്കുന്ന സവിശേഷതകൾ ഉണ്ട്.

WAL-delta താരതമ്യേന കുറഞ്ഞ സമയമെടുക്കുമെന്ന് ഈ ചിത്രം കാണിക്കുന്നു. പകൽ സമയത്ത് ഡാറ്റാബേസിൽ സംഭവിച്ച മാറ്റങ്ങൾ ഇത് വായിക്കുന്നു. രാത്രിയിൽ മാത്രമല്ല, ഞങ്ങൾക്ക് WAL-ഡെൽറ്റ ചെയ്യാൻ കഴിയും, കാരണം അത് മേലിൽ ലോഡിന്റെ കാര്യമായ ഉറവിടമല്ല. വിലകുറഞ്ഞതിനാൽ നമുക്ക് ഓരോ മിനിറ്റിലും WAL-delta വായിക്കാൻ കഴിയും. ഒരു മിനിറ്റിനുള്ളിൽ നമുക്ക് ക്ലസ്റ്ററിൽ സംഭവിച്ച എല്ലാ മാറ്റങ്ങളും സ്കാൻ ചെയ്യാൻ കഴിയും. ഇതിനെ "തൽക്ഷണ WAL-ഡെൽറ്റ" എന്ന് വിളിക്കാം.

ഞങ്ങൾ ക്ലസ്റ്റർ പുനഃസ്ഥാപിക്കുമ്പോൾ, തുടർച്ചയായി ചുരുട്ടേണ്ട സ്റ്റോറികളുടെ എണ്ണം ഞങ്ങൾ കുറയ്ക്കുന്നു എന്നതാണ് കാര്യം. അതായത്, PostgreSQL റോൾ ചെയ്യുന്ന WAL-ന്റെ അളവ് കുറയ്ക്കണം, കാരണം ഇതിന് കാര്യമായ സമയമെടുക്കും.

എന്നാൽ അത് മാത്രമല്ല. ചില ബ്ലോക്കുകൾ ബാക്കപ്പ് സ്ഥിരതയിലേക്ക് മാറ്റുമെന്ന് ഞങ്ങൾക്കറിയാമെങ്കിൽ, മുൻകാലങ്ങളിൽ ഞങ്ങൾക്ക് അത് മാറ്റാൻ കഴിയില്ല. അതായത്, ഇപ്പോൾ നമുക്ക് WAL-delta ഫോർവേഡിംഗിന്റെ ഫയൽ-ബൈ-ഫയൽ ഒപ്റ്റിമൈസേഷൻ ഉണ്ട്. ഇതിനർത്ഥം, ഉദാഹരണത്തിന്, ചൊവ്വാഴ്ച ചില പട്ടികകൾ പൂർണ്ണമായും ഇല്ലാതാക്കുകയോ അല്ലെങ്കിൽ ചില ഫയലുകൾ ടേബിളിൽ നിന്ന് പൂർണ്ണമായും ഇല്ലാതാക്കുകയോ ചെയ്താൽ, തിങ്കളാഴ്ചയും ശനിയാഴ്ചയും ഡെൽറ്റ റോൾ ഓവർ ചെയ്യുമ്പോൾ, ശനിയാഴ്ചകളിലെ pg_basebackup പുനഃസ്ഥാപിക്കുമ്പോൾ, ഞങ്ങൾ ഈ ഡാറ്റ പോലും സൃഷ്ടിക്കില്ല.

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

എന്നാൽ ഇത് ഇപ്പോഴും നമ്മുടെ ഉള്ളിൽ സജീവമായി ചർച്ച ചെയ്യപ്പെടുന്ന ഒരു ആശയമാണ്, പക്ഷേ ഇത് ഇതുവരെ കോഡിൽ എത്തിയിട്ടില്ല.

WAL-G-യിൽ ഒരു ഫീച്ചർ കൂടി ഉണ്ടാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. വ്യത്യസ്‌ത ഡാറ്റാബേസുകളെ പിന്തുണയ്‌ക്കേണ്ടതും ബാക്കപ്പ് മാനേജ്‌മെന്റിനെ അതേ രീതിയിൽ സമീപിക്കാൻ ആഗ്രഹിക്കുന്നതിനാലും ഞങ്ങൾ ഇത് വിപുലീകരിക്കാൻ ആഗ്രഹിക്കുന്നു. എന്നാൽ MySQL API-കൾ തികച്ചും വ്യത്യസ്തമാണ് എന്നതാണ് പ്രശ്നം. MySQL-ൽ, PITR ഫിസിക്കൽ WAL ലോഗിനെ അടിസ്ഥാനമാക്കിയല്ല, ബിൻലോഗിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഈ ബിൻലോഗ് പൂർത്തിയായെന്നും ആർക്കൈവ് ചെയ്യേണ്ടതുണ്ടെന്നും ചില ബാഹ്യ സിസ്റ്റങ്ങളെ അറിയിക്കുന്ന ഒരു ആർക്കൈവിംഗ് സിസ്റ്റം MySQL-ൽ ഞങ്ങളുടെ പക്കലില്ല. ഡാറ്റാബേസുമായി ക്രോണിൽ എവിടെയെങ്കിലും നിൽക്കുകയും എന്തെങ്കിലും തയ്യാറാണോ എന്ന് പരിശോധിക്കുകയും ചെയ്യേണ്ടതുണ്ടോ?

അതുപോലെ, MySQL പുനഃസ്ഥാപിക്കുമ്പോൾ, എനിക്ക് അത്തരം ഫയലുകൾ ആവശ്യമാണെന്ന് സിസ്റ്റത്തോട് പറയാൻ കഴിയുന്ന ഒരു പുനഃസ്ഥാപിക്കൽ കമാൻഡും ഇല്ല. നിങ്ങളുടെ ക്ലസ്റ്റർ പുനർനിർമ്മിക്കാൻ ആരംഭിക്കുന്നതിന് മുമ്പ്, നിങ്ങൾക്ക് ആവശ്യമുള്ള ഫയലുകൾ എന്താണെന്ന് അറിയേണ്ടതുണ്ട്. നിങ്ങൾക്ക് എന്ത് ഫയലുകൾ ആവശ്യമാണെന്ന് നിങ്ങൾ തന്നെ ഊഹിക്കേണ്ടതുണ്ട്. എന്നാൽ ഈ പ്രശ്നങ്ങൾ എങ്ങനെയെങ്കിലും മറികടക്കാൻ കഴിഞ്ഞേക്കും. (വ്യക്തത: MySQL ഇതിനകം പിന്തുണയ്ക്കുന്നു)

റിപ്പോർട്ടിൽ, WAL-G നിങ്ങൾക്ക് അനുയോജ്യമല്ലാത്ത സന്ദർഭങ്ങളെക്കുറിച്ചും സംസാരിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു.

നിങ്ങൾക്ക് ഒരു സിൻക്രണസ് പകർപ്പ് ഇല്ലെങ്കിൽ, അവസാന സെഗ്‌മെന്റ് സംരക്ഷിക്കപ്പെടുമെന്ന് WAL-G ഉറപ്പുനൽകുന്നില്ല. ആർക്കൈവിംഗ് ചരിത്രത്തിന്റെ അവസാനത്തെ കുറച്ച് സെഗ്‌മെന്റുകൾക്ക് പിന്നിലാണെങ്കിൽ, അത് അപകടകരമാണ്. സിൻക്രണസ് പകർപ്പ് ഇല്ലെങ്കിൽ, WAL-G ഉപയോഗിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നില്ല. എന്നിരുന്നാലും, ഇത് പ്രധാനമായും ഒരു ക്ലൗഡ് ഇൻസ്റ്റാളേഷനായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു, ഇത് ഒരു സിൻക്രണസ് പകർപ്പുള്ള ഉയർന്ന ലഭ്യത പരിഹാരത്തെ സൂചിപ്പിക്കുന്നു, ഇത് അവസാനമായി സമർപ്പിച്ച ബൈറ്റുകളുടെ സുരക്ഷയ്ക്ക് ഉത്തരവാദിയാണ്.

ആളുകൾ ഒരേ സമയം WAL-G, WAL-E എന്നിവ പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കുന്നത് ഞാൻ പലപ്പോഴും കാണാറുണ്ട്. WAL-G-ന് WAL-E-യിൽ നിന്ന് ഒരു ഫയൽ പുനഃസ്ഥാപിക്കാനും WAL-E-ൽ നിർമ്മിച്ച ഒരു ബാക്കപ്പ് പുനഃസ്ഥാപിക്കാനും കഴിയും എന്ന അർത്ഥത്തിൽ ഞങ്ങൾ ബാക്ക്വേഡ് കോംപാറ്റിബിളിറ്റിയെ പിന്തുണയ്ക്കുന്നു. എന്നാൽ ഈ രണ്ട് സിസ്റ്റങ്ങളും സമാന്തര വാൽ-പുഷ് ഉപയോഗിക്കുന്നതിനാൽ, അവ പരസ്പരം ഫയലുകൾ മോഷ്ടിക്കാൻ തുടങ്ങുന്നു. നമ്മൾ ഇത് WAL-G-ൽ ശരിയാക്കുകയാണെങ്കിൽ, അത് ഇപ്പോഴും WAL-E-ൽ തന്നെ നിലനിൽക്കും. WAL-E-ൽ, ഇത് ആർക്കൈവ്-സ്റ്റാറ്റസ് നോക്കുന്നു, പൂർത്തിയായ ഫയലുകൾ കാണുകയും അവ ആർക്കൈവ് ചെയ്യുകയും ചെയ്യുന്നു, അതേസമയം ഈ WAL ഫയൽ നിലവിലുണ്ടെന്ന് മറ്റ് സിസ്റ്റങ്ങൾക്ക് അറിയില്ല, കാരണം PostgreSQL ഇത് രണ്ടാമതും ആർക്കൈവ് ചെയ്യാൻ ശ്രമിക്കില്ല.

WAL-G വശത്ത് ഞങ്ങൾ ഇവിടെ എന്താണ് പരിഹരിക്കാൻ പോകുന്നത്? ഈ ഫയൽ സമാന്തരമായി കൈമാറ്റം ചെയ്യപ്പെട്ടതായി ഞങ്ങൾ PostgreSQL-നെ അറിയിക്കില്ല, കൂടാതെ ഇത് ആർക്കൈവ് ചെയ്യാൻ PostgreSQL ആവശ്യപ്പെടുമ്പോൾ, ഈ മോഡ്-ടൈമും ഈ md5 ഉള്ളതുമായ ഒരു ഫയൽ ഇതിനകം ആർക്കൈവ് ചെയ്തിട്ടുണ്ടെന്ന് ഞങ്ങൾ ഇതിനകം തന്നെ അറിയും, ഞങ്ങൾ PostgreSQL എന്ന് പറയും - ശരി, അടിസ്ഥാനപരമായി ഒന്നും ചെയ്യാതെ എല്ലാം തയ്യാറാണ്.

എന്നാൽ ഈ പ്രശ്നം WAL-E വശത്ത് പരിഹരിക്കപ്പെടാൻ സാധ്യതയില്ല, അതിനാൽ WAL-G, WAL-E എന്നിവയിൽ ഫയൽ ആർക്കൈവ് ചെയ്യുന്ന ഒരു ആർക്കൈവ് കമാൻഡ് സൃഷ്ടിക്കുന്നത് നിലവിൽ അസാധ്യമാണ്.

കൂടാതെ, ഇപ്പോൾ നിങ്ങൾക്ക് WAL-G അനുയോജ്യമല്ലാത്ത സാഹചര്യങ്ങളുണ്ട്, പക്ഷേ ഞങ്ങൾ അത് തീർച്ചയായും പരിഹരിക്കും.

ഒന്നാമതായി, ഞങ്ങൾക്ക് നിലവിൽ ബിൽറ്റ്-ഇൻ ബാക്കപ്പ് സ്ഥിരീകരണം ഇല്ല. ബാക്കപ്പ് ചെയ്യുമ്പോഴോ വീണ്ടെടുക്കുമ്പോഴോ ഞങ്ങൾക്ക് സ്ഥിരീകരണം ഇല്ല. തീർച്ചയായും, ഇത് ക്ലൗഡിൽ നടപ്പിലാക്കുന്നു. എന്നാൽ ക്ലസ്റ്റർ പുനഃസ്ഥാപിച്ചുകൊണ്ട് മുൻകൂട്ടി പരിശോധിച്ചുകൊണ്ട് ഇത് നടപ്പിലാക്കുന്നു. ഉപയോക്താക്കൾക്ക് ഈ പ്രവർത്തനം നൽകാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. എന്നാൽ സ്ഥിരീകരണത്തിലൂടെ, WAL-G-ൽ ക്ലസ്റ്റർ പുനഃസ്ഥാപിക്കാനും അത് ആരംഭിക്കാനും സ്മോക്ക് ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കാനും കഴിയുമെന്ന് ഞാൻ അനുമാനിക്കുന്നു: pg_dumpal to /dev/null, amcheck index verification.

നിലവിൽ WAL-G-ൽ, WAL-ൽ നിന്നുള്ള ഒരു ബാക്കപ്പ് മാറ്റിവയ്ക്കാൻ ഒരു മാർഗവുമില്ല. അതായത്, ഞങ്ങൾ ചില വിൻഡോകളെ പിന്തുണയ്ക്കുന്നു. ഉദാഹരണത്തിന്, കഴിഞ്ഞ ഏഴ് ദിവസത്തെ സംഭരിക്കൽ, അവസാനത്തെ പത്ത് ബാക്കപ്പുകൾ സംഭരിക്കുക, അവസാനത്തെ മൂന്ന് പൂർണ്ണ ബാക്കപ്പുകൾ സംഭരിക്കുക. പലപ്പോഴും ആളുകൾ വന്ന് പറയും: "പുതുവർഷത്തിൽ സംഭവിച്ചതിന്റെ ഒരു ബാക്കപ്പ് ഞങ്ങൾക്ക് ആവശ്യമാണ്, അത് എന്നെന്നേക്കുമായി നിലനിർത്താൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു." ഇത് എങ്ങനെ ചെയ്യണമെന്ന് WAL-G-ക്ക് ഇതുവരെ അറിയില്ല. (ശ്രദ്ധിക്കുക - ഇത് ഇതിനകം പരിഹരിച്ചു. കൂടുതൽ വായിക്കുക - ബാക്കപ്പ്-മാർക്ക് ഓപ്ഷൻ ഇൻ https://github.com/wal-g/wal-g/blob/master/PostgreSQL.md)

കൂടാതെ PITR സാധൂകരിക്കുമ്പോൾ എല്ലാ ഷാഫ്റ്റ് സെഗ്‌മെന്റുകൾക്കുമായി ഞങ്ങൾക്ക് പേജ് ചെക്ക്‌സമുകളും സമഗ്രത പരിശോധനകളും ഇല്ല.

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

ഞങ്ങൾ ക്രമേണ പ്രവർത്തിച്ചുകൊണ്ടിരിക്കുന്ന മറ്റ് നിരവധി ചെറിയ പ്രശ്നങ്ങളുണ്ട്. കൂടാതെ വളരെ വിചിത്രമായ ചില കാര്യങ്ങൾ സംഭവിക്കുന്നു.

ഉദാഹരണത്തിന്, നിങ്ങൾ WAL-G ഒരു ശൂന്യമായ ബാക്കപ്പ് നൽകിയാൽ, അത് വെറുതെ വീഴും. ഉദാഹരണത്തിന്, ഒരു ശൂന്യമായ ഫോൾഡർ ബാക്കപ്പ് ചെയ്യണമെന്ന് നിങ്ങൾ അവനോട് പറഞ്ഞാൽ. pg_control ഫയൽ അവിടെ ഉണ്ടാകില്ല. തനിക്ക് എന്തെങ്കിലും മനസ്സിലാകുന്നില്ലെന്ന് അവൻ വിചാരിക്കും. സിദ്ധാന്തത്തിൽ, ഈ സാഹചര്യത്തിൽ ഉപകരണം എങ്ങനെ ഉപയോഗിക്കണമെന്ന് വിശദീകരിക്കാൻ ഉപയോക്താവിന് ഒരു സാധാരണ സന്ദേശം എഴുതേണ്ടതുണ്ട്. എന്നാൽ ഇത് പ്രോഗ്രാമിംഗിന്റെ ഒരു സവിശേഷത പോലുമല്ല, മറിച്ച് നല്ലതും മനസ്സിലാക്കാവുന്നതുമായ ഭാഷയുടെ സവിശേഷതയാണ്.

ഓഫ്‌ലൈൻ ബാക്കപ്പ് എങ്ങനെ ചെയ്യണമെന്ന് ഞങ്ങൾക്ക് അറിയില്ല. ഡാറ്റാബേസ് കള്ളമാണെങ്കിൽ, ഞങ്ങൾക്ക് അത് ബാക്കപ്പ് ചെയ്യാൻ കഴിയില്ല. എന്നാൽ ഇവിടെ എല്ലാം വളരെ ലളിതമാണ്. LSN ആരംഭിക്കുമ്പോൾ ഞങ്ങൾ ബാക്കപ്പുകൾ വിളിക്കുന്നു. നിയന്ത്രണ ഫയലിൽ നിന്ന് അടിസ്ഥാന ബേസിന്റെ LSN വായിച്ചിരിക്കണം. മാത്രമല്ല ഇത് യാഥാർത്ഥ്യമാക്കാത്ത ഒരു സവിശേഷതയാണ്. പല ബാക്കപ്പ് സിസ്റ്റങ്ങൾക്കും ഒരു അടിസ്ഥാന ഡാറ്റാബേസ് ബാക്കപ്പ് ചെയ്യാൻ കഴിയും. അത് സൗകര്യപ്രദവുമാണ്.

നിലവിൽ ഞങ്ങൾക്ക് ബാക്കപ്പ് സ്ഥലത്തിന്റെ അഭാവം ശരിയായി കൈകാര്യം ചെയ്യാൻ കഴിയുന്നില്ല. കാരണം ഞങ്ങൾ സാധാരണയായി വീട്ടിൽ വലിയ ബാക്കപ്പുകളുമായി പ്രവർത്തിക്കുന്നു. അവർ അതിലേക്ക് ചുറ്റുകയും ചെയ്തില്ല. എന്നാൽ ആരെങ്കിലും ഇപ്പോൾ Go-യിൽ പ്രോഗ്രാം ചെയ്യാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ബക്കറ്റിലേക്ക് സ്ഥലത്തിന് പുറത്തുള്ള പിശകുകൾ കൈകാര്യം ചെയ്യൽ ചേർക്കുക. പുൾ അഭ്യർത്ഥന ഞാൻ തീർച്ചയായും പരിശോധിക്കും.

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

Yandex ഡാറ്റാബേസ് മാനേജ്‌മെന്റിൽ ആയിരത്തിലധികം ക്ലസ്റ്ററുകളിൽ WAL-G പ്രവർത്തിക്കുന്നു. ഇത് പ്രതിദിനം നൂറുകണക്കിന് ടെറാബൈറ്റ് ഡാറ്റ ബാക്കപ്പ് ചെയ്യുന്നു.

ഞങ്ങളുടെ കോഡിൽ ധാരാളം TODO ഉണ്ട്. നിങ്ങൾക്ക് പ്രോഗ്രാം ചെയ്യണമെങ്കിൽ, വരൂ, ഞങ്ങൾ പുൾ അഭ്യർത്ഥനകൾക്കായി കാത്തിരിക്കുന്നു, ഞങ്ങൾ ചോദ്യങ്ങൾക്കായി കാത്തിരിക്കുന്നു.

ചോദ്യങ്ങൾ

ഗുഡ് ഈവനിംഗ്! നന്ദി! നിങ്ങൾ WAL-delta ഉപയോഗിക്കുകയാണെങ്കിൽ, നിങ്ങൾ മിക്കവാറും മുഴുവൻ പേജ് റൈറ്റുകളെയാണ് ആശ്രയിക്കുന്നത് എന്നാണ് എന്റെ അനുമാനം. അങ്ങനെയാണെങ്കിൽ, നിങ്ങൾ ടെസ്റ്റുകൾ നടത്തിയോ? നിങ്ങൾ മനോഹരമായ ഒരു ഗ്രാഫ് കാണിച്ചു. FPW ഓഫാക്കിയാൽ അത് എത്ര മനോഹരമാകും?

ഫുൾ പേജ് റൈറ്റുകൾ ഞങ്ങൾക്കായി പ്രവർത്തനക്ഷമമാക്കിയിരിക്കുന്നു, ഞങ്ങൾ അത് പ്രവർത്തനരഹിതമാക്കാൻ ശ്രമിച്ചിട്ടില്ല. അതായത്, ഒരു ഡെവലപ്പർ എന്ന നിലയിൽ ഞാൻ അത് ഓഫാക്കാൻ ശ്രമിച്ചിട്ടില്ല. ഗവേഷണം നടത്തിയ സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർ ഈ പ്രശ്നം ഗവേഷണം ചെയ്തിരിക്കാം. എന്നാൽ ഞങ്ങൾക്ക് FPW ആവശ്യമാണ്. മിക്കവാറും ആരും ഇത് അപ്രാപ്‌തമാക്കുന്നില്ല, അല്ലാത്തപക്ഷം ഒരു പകർപ്പിൽ നിന്ന് ബാക്കപ്പ് എടുക്കുന്നത് അസാധ്യമാണ്.

റിപ്പോർട്ടിന് നന്ദി! എനിക്ക് രണ്ട് ചോദ്യങ്ങളുണ്ട്. ടേബിൾസ്‌പേസുകൾക്ക് എന്ത് സംഭവിക്കും എന്നതാണ് ആദ്യത്തെ ചോദ്യം.

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

പിന്നെ രണ്ടാമത്തെ ചോദ്യവും. WAL-G അത് ഒറ്റയ്ക്ക് പ്രവർത്തിക്കുന്നുവെന്നും റാപ്പറുകൾ ആവശ്യമില്ലെന്നും നിങ്ങൾ തുടക്കത്തിൽ തന്നെ പറഞ്ഞു. ഞാൻ സ്വയം റാപ്പറുകൾ ഉപയോഗിക്കുന്നു. എന്തുകൊണ്ട് അവ ഉപയോഗിക്കാൻ പാടില്ല?

ഇത് ഒരു ബാലലൈക പോലെ ലളിതമായിരിക്കണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഇതിനർത്ഥം നിങ്ങൾക്ക് ഒരു ബാലലൈക ഒഴികെ മറ്റൊന്നും ആവശ്യമില്ല എന്നാണ്. സിസ്റ്റം ലളിതമാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. നിങ്ങൾക്ക് ഒരു സ്ക്രിപ്റ്റിൽ ചെയ്യേണ്ട പ്രവർത്തനക്ഷമതയുണ്ടെങ്കിൽ, വന്ന് ഞങ്ങളോട് പറയുക - ഞങ്ങൾ അത് Go-യിൽ ചെയ്യും.

ഗുഡ് ഈവനിംഗ്! റിപ്പോർട്ടിന് നന്ദി! GPG ഡീക്രിപ്ഷൻ ഉപയോഗിച്ച് WAL-G പ്രവർത്തിക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞില്ല. ഇത് സാധാരണയായി എൻക്രിപ്റ്റ് ചെയ്യുന്നു, പക്ഷേ ഡീക്രിപ്റ്റ് ചെയ്യാൻ ആഗ്രഹിക്കുന്നില്ല. ഇത് ഞങ്ങൾക്ക് പ്രവർത്തിക്കാത്ത ഒന്നാണോ? സ്ഥിതി നിരാശാജനകമാണ്.

GitHub-ൽ ഒരു പ്രശ്നം സൃഷ്‌ടിക്കുക, നമുക്ക് അത് കണ്ടെത്താം.

അതായത്, നിങ്ങൾ ഇത് നേരിട്ടിട്ടില്ലേ?

പിശക് റിപ്പോർട്ടിന്റെ ഒരു സവിശേഷതയുണ്ട്, അത് ഏത് തരത്തിലുള്ള ഫയലാണെന്ന് WAL-G-ക്ക് മനസ്സിലാകാത്തപ്പോൾ, അത് ചോദിക്കുന്നു: "ഒരുപക്ഷേ ഇത് എൻക്രിപ്റ്റ് ചെയ്തതാണോ?" ഒരുപക്ഷേ പ്രശ്നം എൻക്രിപ്ഷൻ അല്ല. ഈ വിഷയത്തിൽ ലോഗിംഗ് മെച്ചപ്പെടുത്താൻ ഞാൻ ആഗ്രഹിക്കുന്നു. അവൻ അത് മനസ്സിലാക്കണം. പബ്ലിക്, പ്രൈവറ്റ് കീകൾ നേടുന്നതിനുള്ള സംവിധാനം എങ്ങനെ സംഘടിപ്പിക്കപ്പെടുന്നു എന്നത് ഞങ്ങൾക്ക് ശരിക്കും ഇഷ്ടമല്ല എന്ന അർത്ഥത്തിലാണ് ഞങ്ങൾ നിലവിൽ ഈ വിഷയത്തിൽ പ്രവർത്തിക്കുന്നത്. കാരണം നമ്മൾ എക്‌സ്‌റ്റേണൽ ജിപിജി എന്ന് വിളിക്കുന്നതിനാൽ അത് അതിന്റെ കീകൾ നൽകുന്നു. തുടർന്ന് ഞങ്ങൾ ഈ കീകൾ എടുത്ത് ആന്തരിക ജിപിജിയിലേക്ക് മാറ്റുന്നു, അത് ഓപ്പൺ പിജിപിയാണ്, അത് WAL-G-യിൽ നമുക്കായി സമാഹരിച്ചിരിക്കുന്നു, അവിടെ ഞങ്ങൾ എൻക്രിപ്ഷൻ എന്ന് വിളിക്കുന്നു. ഇക്കാര്യത്തിൽ, ഞങ്ങൾ സിസ്റ്റം മെച്ചപ്പെടുത്താനും ലിബ്സോഡിയം എൻക്രിപ്ഷനെ പിന്തുണയ്ക്കാനും ആഗ്രഹിക്കുന്നു (പതിപ്പ് 0.2.15 ൽ ചേർത്തു). തീർച്ചയായും, ഡീകോഡിംഗ് പ്രവർത്തിക്കണം, നമുക്ക് അത് കണ്ടെത്താം - രണ്ട് വാക്കുകളേക്കാൾ നിങ്ങൾക്ക് ഒരു ലക്ഷണം ആവശ്യമാണ്. നിങ്ങൾക്ക് എപ്പോഴെങ്കിലും സ്പീക്കറുടെ മുറിയിൽ ഒത്തുകൂടി സിസ്റ്റം നോക്കാം. (ബാഹ്യ ജിപിജി ഇല്ലാത്ത പിജിപി എൻക്രിപ്ഷൻ - v0.2.9)

ഹലോ! റിപ്പോർട്ടിന് നന്ദി! എനിക്ക് രണ്ട് ചോദ്യങ്ങളുണ്ട്. രണ്ട് ദാതാക്കളിൽ pg_basebackup, WAL ലോഗ് ഇൻ ചെയ്യാൻ എനിക്ക് വിചിത്രമായ ഒരു ആഗ്രഹമുണ്ട്, അതായത് ഒരു ക്ലൗഡും മറ്റൊന്നും ചെയ്യാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. ഇത് ചെയ്യാൻ എന്തെങ്കിലും വഴിയുണ്ടോ?

ഇത് ഇപ്പോൾ നിലവിലില്ല, പക്ഷേ ഇതൊരു രസകരമായ ആശയമാണ്.

ഞാൻ ഒരു ദാതാവിനെ വിശ്വസിക്കുന്നില്ല, മറ്റൊരു ദാതാവിലും അത് തന്നെ വേണമെന്ന് ഞാൻ ആഗ്രഹിക്കുന്നു.

ആശയം രസകരമാണ്. സാങ്കേതികമായി, ഇത് നടപ്പിലാക്കാൻ ഒട്ടും ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല. ആശയം നഷ്‌ടപ്പെടാതിരിക്കാൻ, GitHub-ൽ ഒരു പ്രശ്‌നം ഉണ്ടാക്കാൻ എനിക്ക് നിങ്ങളോട് ആവശ്യപ്പെടാമോ?

അതെ തീർച്ചയായും.

തുടർന്ന്, വിദ്യാർത്ഥികൾ ഗൂഗിൾ സമ്മർ ഓഫ് കോഡിലേക്ക് വരുമ്പോൾ, ഞങ്ങൾ അവരെ പ്രോജക്റ്റിലേക്ക് ചേർക്കും, അതുവഴി അവരിൽ നിന്ന് കൂടുതൽ കാര്യങ്ങൾ നേടുന്നതിന് കൂടുതൽ ജോലികൾ ഉണ്ടാകും.

പിന്നെ രണ്ടാമത്തെ ചോദ്യവും. GitHub-ൽ ഒരു പ്രശ്നമുണ്ട്. ഇത് ഇതിനകം അടച്ചിട്ടുണ്ടെന്ന് ഞാൻ കരുതുന്നു. വീണ്ടെടുക്കൽ സമയത്ത് ഒരു പരിഭ്രാന്തി ഉണ്ട്. അതിനെ പരാജയപ്പെടുത്താൻ, നിങ്ങൾ ഒരു പ്രത്യേക അസംബ്ലി ഉണ്ടാക്കി. പ്രശ്നങ്ങളിൽ അത് ശരിയാണ്. ഒരു ത്രെഡിൽ വേരിയബിൾ എൻവയോൺമെന്റ് ചെയ്യാനുള്ള ഓപ്ഷനുമുണ്ട്. അതുകൊണ്ടാണ് ഇത് വളരെ സാവധാനത്തിൽ പ്രവർത്തിക്കുന്നത്. ഞങ്ങൾ ഈ പ്രശ്നം നേരിട്ടു, അത് ഇതുവരെ പരിഹരിച്ചിട്ടില്ല.

ചില കാരണങ്ങളാൽ സ്റ്റോറേജ് (CEPH) ഉയർന്ന ഏകീകൃതതയോടെ കണക്ഷനിലേക്ക് വരുമ്പോൾ അത് പുനഃസജ്ജമാക്കുന്നു എന്നതാണ് പ്രശ്നം. ഇതിന് എന്ത് ചെയ്യാൻ കഴിയും? വീണ്ടും ശ്രമിക്കുന്നതിനുള്ള യുക്തി ഇതുപോലെയാണ്. ഞങ്ങൾ ഫയൽ വീണ്ടും ഡൗൺലോഡ് ചെയ്യാൻ ശ്രമിക്കുകയാണ്. ഒരു പാസിൽ, ഞങ്ങൾക്ക് ഡൗൺലോഡ് ചെയ്യാത്ത നിരവധി ഫയലുകൾ ഉണ്ടായിരുന്നു, ലോഗിൻ ചെയ്യാത്ത എല്ലാവർക്കും ഞങ്ങൾ രണ്ടാമത്തേത് ഉണ്ടാക്കും. ഓരോ ആവർത്തനത്തിനും കുറഞ്ഞത് ഒരു ഫയലെങ്കിലും ലോഡ് ചെയ്യുന്നിടത്തോളം, ഞങ്ങൾ ആവർത്തിക്കുകയും ആവർത്തിക്കുകയും ആവർത്തിക്കുകയും ചെയ്യുന്നു. വീണ്ടും ശ്രമിക്കുന്നതിനുള്ള യുക്തി ഞങ്ങൾ മെച്ചപ്പെടുത്തി - എക്‌സ്‌പോണൻഷ്യൽ ബാക്ക്ഓഫ്. എന്നാൽ സ്റ്റോറേജ് സിസ്റ്റം വശത്ത് കണക്ഷൻ കേവലം തകരുന്നു എന്ന വസ്തുതയുമായി എന്തുചെയ്യണമെന്ന് പൂർണ്ണമായും വ്യക്തമല്ല. അതായത്, നമ്മൾ ഒരു സ്ട്രീമിലേക്ക് അപ്ലോഡ് ചെയ്യുമ്പോൾ, അത് ഈ കണക്ഷനുകളെ തകർക്കുന്നില്ല. നമുക്ക് ഇവിടെ എന്താണ് മെച്ചപ്പെടുത്താൻ കഴിയുക? ഞങ്ങൾക്ക് നെറ്റ്‌വർക്ക് ത്രോട്ടിലിംഗ് ഉണ്ട്, ഓരോ കണക്ഷനും അത് അയയ്‌ക്കുന്ന ബൈറ്റുകളുടെ എണ്ണം കൊണ്ട് പരിമിതപ്പെടുത്താം. അല്ലാത്തപക്ഷം, ഒബ്ജക്റ്റ് സ്റ്റോറേജ് സമാന്തരമായി അതിൽ നിന്ന് ഡൗൺലോഡ് ചെയ്യാനോ ഡൗൺലോഡ് ചെയ്യാനോ ഞങ്ങളെ അനുവദിക്കുന്നില്ല എന്ന വസ്തുത എങ്ങനെ കൈകാര്യം ചെയ്യണമെന്ന് എനിക്കറിയില്ല.

SLA ഇല്ലേ? അവർ എങ്ങനെയാണ് പീഡിപ്പിക്കപ്പെടാൻ അനുവദിക്കുന്നതെന്ന് അവർക്കായി എഴുതിയിട്ടില്ലേ?

ഈ ചോദ്യവുമായി വരുന്ന ആളുകൾക്ക് സാധാരണയായി അവരുടെ സ്വന്തം നിലവറയുണ്ട് എന്നതാണ് കാര്യം. അതായത്, ആമസോണിൽ നിന്നോ ഗൂഗിൾ ക്ലൗഡിൽ നിന്നോ Yandex ഒബ്‌ജക്റ്റ് സ്റ്റോറേജിൽ നിന്നോ ആരും വരുന്നില്ല.

ഒരുപക്ഷേ ചോദ്യം ഇനി നിങ്ങളുടേതല്ലായിരിക്കാം?

ഈ കേസിൽ ഇവിടെ ചോദ്യം ആരോട് പ്രശ്നമല്ല. ഇത് എങ്ങനെ കൈകാര്യം ചെയ്യണം എന്നതിനെക്കുറിച്ച് എന്തെങ്കിലും ആശയങ്ങൾ ഉണ്ടെങ്കിൽ, നമുക്ക് അത് WAL-G- ൽ ചെയ്യാം. എന്നാൽ ഇത് എങ്ങനെ കൈകാര്യം ചെയ്യണമെന്ന് എനിക്ക് ഇതുവരെ നല്ല ആശയങ്ങളൊന്നുമില്ല. ബാക്കപ്പുകളെ വ്യത്യസ്തമായി ലിസ്റ്റുചെയ്യുന്നതിനെ പിന്തുണയ്ക്കുന്ന ചില ഒബ്‌ജക്റ്റ് സ്റ്റോറേജുകളുണ്ട്. ഒബ്‌ജക്‌റ്റുകൾ ലിസ്റ്റുചെയ്യാൻ നിങ്ങൾ അവരോട് ആവശ്യപ്പെടുകയും അവർ അവിടെ ഫോൾഡർ ചേർക്കുകയും ചെയ്യുന്നു. ഇതിൽ WAL-G ഭയപ്പെടുന്നു - ഒരു ഫയലല്ലാത്ത ചില കാര്യങ്ങൾ ഇവിടെയുണ്ട്, എനിക്ക് അത് പുനഃസ്ഥാപിക്കാൻ കഴിയില്ല, അതായത് ബാക്കപ്പ് പുനഃസ്ഥാപിച്ചില്ല. അതായത്, വാസ്തവത്തിൽ, നിങ്ങൾക്ക് പൂർണ്ണമായും പുനഃസ്ഥാപിച്ച ക്ലസ്റ്റർ ഉണ്ട്, എന്നാൽ അത് നിങ്ങൾക്ക് ഒരു തെറ്റായ സ്റ്റാറ്റസ് നൽകുന്നു, കാരണം ഒബ്ജക്റ്റ് സ്റ്റോറേജ് അത് പൂർണ്ണമായി മനസ്സിലാക്കാത്ത ചില വിചിത്രമായ വിവരങ്ങൾ തിരികെ നൽകി.

ഇത് മെയിൽ ക്ലൗഡിൽ സംഭവിക്കുന്ന ഒരു കാര്യമാണ്.

നിങ്ങൾക്ക് ഒരു പുനർനിർമ്മാണം നിർമ്മിക്കാൻ കഴിയുമെങ്കിൽ ...

ഇത് സ്ഥിരമായി പുനർനിർമ്മിക്കപ്പെടുന്നു ...

ഒരു പുനരുൽപ്പാദനം ഉണ്ടെങ്കിൽ, ഞങ്ങൾ വീണ്ടും ശ്രമിക്കുന്നതിനുള്ള തന്ത്രങ്ങൾ പരീക്ഷിക്കുകയും ക്ലൗഡ് നമ്മിൽ നിന്ന് എന്താണ് ആവശ്യപ്പെടുന്നതെന്ന് മനസിലാക്കുകയും എങ്ങനെ വീണ്ടും ശ്രമിക്കാമെന്ന് കണ്ടെത്തുകയും ചെയ്യുമെന്ന് ഞാൻ കരുതുന്നു. ഒരുപക്ഷേ ഇത് മൂന്ന് കണക്ഷനുകളിൽ ഞങ്ങൾക്ക് സ്ഥിരതയുള്ളതായിരിക്കും, കണക്ഷൻ തകർക്കില്ല, തുടർന്ന് ഞങ്ങൾ ശ്രദ്ധാപൂർവ്വം മൂന്നിൽ എത്തും. കാരണം ഇപ്പോൾ ഞങ്ങൾ കണക്ഷൻ വളരെ വേഗത്തിൽ ഡ്രോപ്പ് ചെയ്യുന്നു, അതായത് 16 ത്രെഡുകൾ ഉപയോഗിച്ച് ഞങ്ങൾ ഒരു വീണ്ടെടുക്കൽ സമാരംഭിച്ചാൽ, ആദ്യത്തെ വീണ്ടും ശ്രമിച്ചതിന് ശേഷം 8 ത്രെഡുകൾ, 4 ത്രെഡുകൾ, 2 ത്രെഡുകൾ, ഒന്ന് എന്നിവ ഉണ്ടാകും. തുടർന്ന് അത് ഫയലിനെ ഒരു സ്ട്രീമിലേക്ക് വലിക്കും. പമ്പിംഗിന് ഏറ്റവും മികച്ചത് 7,5 ത്രെഡുകൾ പോലെയുള്ള ചില മാന്ത്രിക മൂല്യങ്ങൾ ഉണ്ടെങ്കിൽ, ഞങ്ങൾ അവയിൽ താമസിച്ച് മറ്റൊരു 7,5 ത്രെഡുകൾ നിർമ്മിക്കാൻ ശ്രമിക്കും. ഇതാ ഒരു ആശയം.

റിപ്പോർട്ടിന് നന്ദി! WAL-G-യിൽ പ്രവർത്തിക്കുന്നതിനുള്ള ഒരു സമ്പൂർണ്ണ വർക്ക്ഫ്ലോ എങ്ങനെയിരിക്കും? ഉദാഹരണത്തിന്, പേജുകളിലുടനീളം ഡെൽറ്റ ഇല്ലെങ്കിൽ മണ്ടത്തരമായ സാഹചര്യത്തിൽ. ഞങ്ങൾ പ്രാരംഭ ബാക്കപ്പ് എടുത്ത് നീക്കംചെയ്യുന്നു, തുടർന്ന് മുഖത്ത് നീല നിറമാകുന്നതുവരെ ഷാഫ്റ്റ് ആർക്കൈവ് ചെയ്യുന്നു. ഇവിടെ, ഞാൻ മനസ്സിലാക്കിയതുപോലെ, ഒരു തകർച്ചയുണ്ട്. ചില ഘട്ടങ്ങളിൽ നിങ്ങൾ പേജുകളുടെ ഒരു ഡെൽറ്റ ബാക്കപ്പ് ഉണ്ടാക്കേണ്ടതുണ്ട്, അതായത് ചില ബാഹ്യ പ്രക്രിയകൾ ഇതിനെ നയിക്കുന്നു അല്ലെങ്കിൽ ഇത് എങ്ങനെ സംഭവിക്കുന്നു?

ഡെൽറ്റ ബാക്കപ്പ് API വളരെ ലളിതമാണ്. അവിടെ ഒരു സംഖ്യയുണ്ട് - പരമാവധി ഡെൽറ്റ പടികൾ, അതാണ് വിളിക്കുന്നത്. ഇത് പൂജ്യത്തിലേക്ക് സ്ഥിരസ്ഥിതിയായി മാറുന്നു. നിങ്ങൾ ഒരു ബാക്കപ്പ്-പുഷ് ചെയ്യുമ്പോഴെല്ലാം, അത് ഒരു പൂർണ്ണ ബാക്കപ്പ് ഡൗൺലോഡ് ചെയ്യുന്നു എന്നാണ് ഇതിനർത്ഥം. നിങ്ങൾ അതിനെ ഏതെങ്കിലും പോസിറ്റീവ് നമ്പറിലേക്ക് മാറ്റുകയാണെങ്കിൽ, ഉദാഹരണത്തിന്, 3, അടുത്ത തവണ നിങ്ങൾ ഒരു ബാക്കപ്പ്-പുഷ് ചെയ്യുമ്പോൾ, അത് മുൻ ബാക്കപ്പുകളുടെ ചരിത്രത്തിലേക്ക് നോക്കുന്നു. നിങ്ങൾ 3 ഡെൽറ്റകളുടെ ശൃംഖലയിൽ കവിയുന്നില്ലെന്ന് അദ്ദേഹം കാണുകയും ഒരു ഡെൽറ്റ ഉണ്ടാക്കുകയും ചെയ്യുന്നു.

അതായത്, നമ്മൾ WAL-G ലോഞ്ച് ചെയ്യുമ്പോഴെല്ലാം, അത് ഒരു പൂർണ്ണ ബാക്കപ്പ് ഉണ്ടാക്കാൻ ശ്രമിക്കുമോ?

ഇല്ല, ഞങ്ങൾ WAL-G പ്രവർത്തിപ്പിക്കുന്നു, നിങ്ങളുടെ നയങ്ങൾ അനുവദിക്കുകയാണെങ്കിൽ അത് ഒരു ഡെൽറ്റ ഉണ്ടാക്കാൻ ശ്രമിക്കുന്നു.

ഏകദേശം പറഞ്ഞാൽ, ഓരോ തവണയും പൂജ്യത്തിൽ ഇത് പ്രവർത്തിപ്പിക്കുകയാണെങ്കിൽ, അത് pg_basebackup പോലെ പ്രവർത്തിക്കുമോ?

ഇല്ല, കംപ്രഷനും പാരലലിസവും ഉപയോഗിക്കുന്നതിനാൽ ഇത് ഇപ്പോഴും വേഗത്തിൽ പ്രവർത്തിക്കും. Pg_basebackup നിങ്ങളുടെ അടുത്ത് ഷാഫ്റ്റ് ഇടും. നിങ്ങൾ ആർക്കൈവിംഗ് ക്രമീകരിച്ചിട്ടുണ്ടെന്ന് WAL-G അനുമാനിക്കുന്നു. കോൺഫിഗർ ചെയ്തിട്ടില്ലെങ്കിൽ അത് മുന്നറിയിപ്പ് നൽകും.

Pg_basebackup ഷാഫ്റ്റുകൾ ഇല്ലാതെ പ്രവർത്തിപ്പിക്കാം.

അതെ, അപ്പോൾ അവർ ഏതാണ്ട് സമാനമായി പെരുമാറും. Pg_basebackup ഫയൽ സിസ്റ്റത്തിലേക്കുള്ള പകർപ്പുകൾ. പറയട്ടെ, ഞാൻ പറയാൻ മറന്ന ഒരു പുതിയ ഫീച്ചർ ഞങ്ങൾക്കുണ്ട്. നമുക്ക് ഇപ്പോൾ pg_basebackup-ൽ നിന്ന് ഫയൽ സിസ്റ്റത്തിലേക്ക് ബാക്കപ്പ് ചെയ്യാം. എന്തുകൊണ്ടാണ് ഇത് ആവശ്യമെന്ന് എനിക്കറിയില്ല, പക്ഷേ അത് അവിടെയുണ്ട്.

ഉദാഹരണത്തിന്, CephFS-ൽ. ഒബ്ജക്റ്റ് സ്റ്റോറേജ് കോൺഫിഗർ ചെയ്യാൻ എല്ലാവരും ആഗ്രഹിക്കുന്നില്ല.

അതെ, അതുകൊണ്ടായിരിക്കാം അവർ ഈ സവിശേഷതയെക്കുറിച്ച് ഒരു ചോദ്യം ചോദിച്ചത്, അതുവഴി ഞങ്ങൾക്ക് അത് ചെയ്യാൻ കഴിയും. ഞങ്ങൾ അത് ചെയ്തു.

റിപ്പോർട്ടിന് നന്ദി! ഫയൽ സിസ്റ്റത്തിലേക്ക് പകർത്തുന്നതിനെക്കുറിച്ച് ഒരു ചോദ്യം മാത്രമേയുള്ളൂ. ബോക്‌സിന് പുറത്ത്, റിമോട്ട് സ്റ്റോറേജിലേക്ക് പകർത്തുന്നതിനെ നിങ്ങൾ ഇപ്പോൾ പിന്തുണയ്ക്കുന്നുണ്ടോ, ഉദാഹരണത്തിന്, ഡാറ്റാ സെന്ററിലോ മറ്റെന്തെങ്കിലുമോ ഷെൽഫ് ഉണ്ടെങ്കിൽ?

ഈ രൂപീകരണത്തിൽ, ഇത് ബുദ്ധിമുട്ടുള്ള ഒരു ചോദ്യമാണ്. അതെ, ഞങ്ങൾ പിന്തുണയ്ക്കുന്നു, എന്നാൽ ഈ പ്രവർത്തനം ഇതുവരെ ഒരു റിലീസിലും ഉൾപ്പെടുത്തിയിട്ടില്ല. അതായത്, എല്ലാ പ്രീ-റിലീസുകളും ഇതിനെ പിന്തുണയ്ക്കുന്നു, എന്നാൽ റിലീസ് പതിപ്പുകൾ പിന്തുണയ്ക്കുന്നില്ല. ഈ പ്രവർത്തനം പതിപ്പ് 0.2 ൽ ചേർത്തു. അറിയപ്പെടുന്ന എല്ലാ ബഗുകളും ഞങ്ങൾ പരിഹരിച്ചാൽ ഉടൻ തന്നെ ഇത് തീർച്ചയായും റിലീസ് ചെയ്യും. എന്നാൽ ഇപ്പോൾ ഇത് പ്രീ-റിലീസിൽ മാത്രമേ ചെയ്യാൻ കഴിയൂ. പ്രീ-റിലീസിൽ രണ്ട് ബഗുകൾ ഉണ്ട്. WAL-E വീണ്ടെടുക്കലിലെ പ്രശ്നം, ഞങ്ങൾ അത് പരിഹരിച്ചിട്ടില്ല. ഏറ്റവും പുതിയ പ്രീ-റിലീസിൽ ഡെൽറ്റ-ബാക്കപ്പിനെക്കുറിച്ചുള്ള ഒരു ബഗ് ചേർത്തു. അതിനാൽ, റിലീസ് പതിപ്പുകൾ ഉപയോഗിക്കാൻ ഞങ്ങൾ എല്ലാവരേയും ശുപാർശ ചെയ്യുന്നു. പ്രീ-റിലീസിൽ കൂടുതൽ ബഗുകൾ ഇല്ലെങ്കിൽ, ഞങ്ങൾ Google ക്ലൗഡ്, S3-അനുയോജ്യമായ കാര്യങ്ങൾ, ഫയൽ സംഭരണം എന്നിവയെ പിന്തുണയ്ക്കുന്നുവെന്ന് പറയാം.

ഹലോ, റിപ്പോർട്ടിന് നന്ദി. ഞാൻ മനസ്സിലാക്കിയതുപോലെ, WAL-G എന്നത് ബാർമെൻ പോലെയുള്ള ഒരുതരം കേന്ദ്രീകൃത സംവിധാനമല്ലേ? ഈ ദിശയിലേക്ക് നീങ്ങാൻ നിങ്ങൾ പദ്ധതിയിടുന്നുണ്ടോ?

ഈ ദിശയിൽ നിന്ന് നമ്മൾ മാറിയതാണ് പ്രശ്നം. WAL-G അടിസ്ഥാന ഹോസ്റ്റിലും ക്ലസ്റ്റർ ഹോസ്റ്റിലും ക്ലസ്റ്ററിലെ എല്ലാ ഹോസ്റ്റുകളിലും ജീവിക്കുന്നു. ഞങ്ങൾ ആയിരക്കണക്കിന് ക്ലസ്റ്ററുകളിലേക്ക് മാറിയപ്പോൾ, ഞങ്ങൾക്ക് നിരവധി ബാർടെൻഡർ ഇൻസ്റ്റാളേഷനുകൾ ഉണ്ടായിരുന്നു. ഓരോ തവണയും അവയിൽ എന്തെങ്കിലും വീഴുമ്പോൾ, അത് ഒരു വലിയ പ്രശ്നമാണ്. അവ നന്നാക്കേണ്ടതിനാൽ, ഇപ്പോൾ ബാക്കപ്പുകൾ ഇല്ലാത്ത ക്ലസ്റ്ററുകൾ ഏതെന്ന് നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്. ബാക്കപ്പ് സിസ്റ്റങ്ങൾക്കായി ഫിസിക്കൽ ഹാർഡ്‌വെയറിന്റെ ദിശയിൽ WAL-G വികസിപ്പിക്കാൻ ഞാൻ ഉദ്ദേശിക്കുന്നില്ല. കമ്മ്യൂണിറ്റിക്ക് ഇവിടെ എന്തെങ്കിലും പ്രവർത്തനക്ഷമത വേണമെങ്കിൽ, എനിക്ക് ഒട്ടും പ്രശ്നമില്ല.

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

PS ഒരു പുതിയ പതിപ്പ് പുറത്തിറങ്ങി 0.2.15, ഇതിൽ നിങ്ങൾക്ക് .walg.json കോൺഫിഗറേഷൻ ഫയൽ ഉപയോഗിക്കാം, അത് ഡിഫോൾട്ടായി പോസ്റ്റ്ഗ്രെസ് ഹോം ഡയറക്ടറിയിൽ സ്ഥിതിചെയ്യുന്നു. നിങ്ങൾക്ക് ബാഷ് സ്ക്രിപ്റ്റുകൾ ഉപേക്ഷിക്കാം. ഉദാഹരണം .walg.json ഈ ലക്കത്തിലാണ് https://github.com/wal-g/wal-g/issues/545

വീഡിയോ:

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