ലിക്വിബേസ് ഉപയോഗിച്ച് കാലിൽ സ്വയം വെടിവയ്ക്കുന്നത് എങ്ങനെ ഒഴിവാക്കാം

മുമ്പൊരിക്കലും സംഭവിച്ചിട്ടില്ല, ഇതാ ഞങ്ങൾ വീണ്ടും പോകുന്നു!

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

ലേഖനത്തിൽ ഉപയോഗപ്രദമായ നുറുങ്ങുകളും റിലേഷണൽ ഡാറ്റാബേസ് മൈഗ്രേഷൻ ടൂളുകൾ, പ്രത്യേകിച്ച് ലിക്വിബേസ് എന്നിവയിൽ പ്രവർത്തിക്കുമ്പോൾ നിങ്ങൾക്ക് വീഴാവുന്ന ഏറ്റവും വ്യക്തമായ മൂന്ന് അപകടങ്ങളുടെ വിവരണവും ഉൾപ്പെടുന്നു. ജൂനിയർ, മിഡിൽ തലങ്ങളിൽ ജാവ ഡെവലപ്പർമാർക്കായി രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്നു; കൂടുതൽ പരിചയസമ്പന്നരായ ഡെവലപ്പർമാർക്ക്, ഇതിനകം അറിയാവുന്ന കാര്യങ്ങളെ രൂപപ്പെടുത്തുന്നതിനും ആവർത്തിക്കുന്നതിനും ഇത് താൽപ്പര്യമുള്ളതായിരിക്കാം.

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

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

നിങ്ങളുടെ പ്രോജക്റ്റിലേക്ക് ഒരു ലൈബ്രറി ചേർക്കുന്നതിനുള്ള സാങ്കേതികവിദ്യയുടെയും നിർദ്ദേശങ്ങളുടെയും വിവരണത്തിലേക്ക് ഞാൻ കൂടുതൽ ആഴത്തിൽ പോകില്ല; ഈ വിഷയത്തിൽ കുറച്ച് ലേഖനങ്ങൾ എഴുതിയിട്ടുണ്ട്:

• ഒരു സ്പ്രിംഗ് ബൂട്ട് ആപ്ലിക്കേഷനിൽ ഡാറ്റാബേസ് ഘടന നിയന്ത്രിക്കുന്നതിന് ലിക്വിബേസ് ഉപയോഗിക്കുന്നു. ഭാഗം 1
• ഒരു സ്പ്രിംഗ് ബൂട്ട് ആപ്ലിക്കേഷനിൽ ഡാറ്റാബേസ് ഘടന നിയന്ത്രിക്കുന്നതിന് ലിക്വിബേസ് ഉപയോഗിക്കുന്നു. ഭാഗം 2
• ലിക്വിബേസും മാവെനും
• ഡാറ്റാബേസ് മാറ്റങ്ങൾ പതിപ്പിക്കുന്നതിനുള്ള സമീപനങ്ങൾ
• ഞങ്ങൾ സ്പ്രിംഗ് എംവിസി/സെക്യൂരിറ്റി, റെസ്റ്റ്, ഹൈബർനേറ്റ്, ലിക്വിബേസ് എന്നിവ രണ്ട് വരികളായി സമാരംഭിക്കുന്നു

കൂടാതെ, ഉപയോഗപ്രദമായ നുറുങ്ങുകൾ എന്ന വിഷയത്തിൽ ഇതിനകം ഒരു മികച്ച ലേഖനം ഉണ്ടായിരുന്നു:

• തലവേദന ഇല്ലാതെ ലിക്വിബേസ് ഉപയോഗിക്കുന്നു. യഥാർത്ഥ വികസന അനുഭവത്തിൽ നിന്നുള്ള 10 നുറുങ്ങുകൾ

നുറുങ്ങുകൾ

വിയർപ്പിലും ചോരയിലും വേദനയിലും കുടിയേറിയ പ്രശ്‌നങ്ങൾ പരിഹരിച്ച് പിറന്ന എന്റെ ഉപദേശങ്ങളും അഭിപ്രായങ്ങളും പങ്കുവെക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

1. ജോലി ആരംഭിക്കുന്നതിന് മുമ്പ്, മികച്ച പരിശീലന വിഭാഗവുമായി നിങ്ങൾ സ്വയം പരിചയപ്പെടണം സൈറ്റ് ലിക്വിബേസ്

അവിടെ ലളിതവും എന്നാൽ വളരെ പ്രധാനപ്പെട്ടതുമായ കാര്യങ്ങൾ വിവരിച്ചിരിക്കുന്നു, ഇതില്ലാതെ ലൈബ്രറി ഉപയോഗിക്കുന്നത് നിങ്ങളുടെ ജീവിതത്തെ സങ്കീർണ്ണമാക്കും. ഉദാഹരണത്തിന്, മാറ്റങ്ങളെ നിയന്ത്രിക്കുന്നതിനുള്ള ഘടനാരഹിതമായ സമീപനം താമസിയാതെ അല്ലെങ്കിൽ പിന്നീട് ആശയക്കുഴപ്പത്തിലേക്കും തകർന്ന കുടിയേറ്റത്തിലേക്കും നയിക്കും. നിങ്ങൾ ഡാറ്റാബേസ് ഘടനയിലും സേവന ലോജിക്കിലും ഒരേ സമയം പരസ്പരാശ്രിത മാറ്റങ്ങൾ വരുത്തുന്നില്ലെങ്കിൽ, ഇത് ചുവന്ന പരിശോധനകളിലേക്കോ തകർന്ന അന്തരീക്ഷത്തിലേക്കോ നയിക്കാനുള്ള ഉയർന്ന സാധ്യതയുണ്ട്. കൂടാതെ, ഔദ്യോഗിക വെബ്‌സൈറ്റിൽ ലിക്വിബേസ് ഉപയോഗിക്കുന്നതിനുള്ള ശുപാർശകളിൽ പ്രധാന മൈഗ്രേഷൻ സ്‌ക്രിപ്‌റ്റുകൾക്കൊപ്പം റോൾബാക്ക് സ്‌ക്രിപ്‌റ്റുകളുടെ വികസനത്തെയും പരിശോധനയെയും കുറിച്ചുള്ള ഒരു ക്ലോസ് അടങ്ങിയിരിക്കുന്നു. ശരി, ലേഖനത്തിൽ https://habr.com/ru/post/178665/ മൈഗ്രേഷനും റോൾബാക്ക് മെക്കാനിസവും സംബന്ധിച്ച് കോഡ് ഉദാഹരണങ്ങളുണ്ട്.

2. നിങ്ങൾ മൈഗ്രേഷൻ ടൂളുകൾ ഉപയോഗിക്കാൻ തുടങ്ങിയാൽ, ഡാറ്റാബേസ് ഘടനയിൽ സ്വമേധയാലുള്ള തിരുത്തലുകൾ അനുവദിക്കരുത്

പഴഞ്ചൊല്ല് പറയുന്നതുപോലെ: "ഒരിക്കൽ പെർസിൽ, എല്ലായ്പ്പോഴും പെർസിൽ." നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ അടിസ്ഥാനം Liquibase നിയന്ത്രിക്കാൻ തുടങ്ങിയാൽ, ഏതെങ്കിലും സ്വമേധയാലുള്ള മാറ്റങ്ങൾ ഉടനടി പൊരുത്തമില്ലാത്ത അവസ്ഥയിലേക്ക് നയിക്കുന്നു, കൂടാതെ മാറ്റങ്ങളിലെ വിശ്വാസത്തിന്റെ തോത് പൂജ്യമാകും. സാധ്യതയുള്ള അപകടസാധ്യതകളിൽ ഡാറ്റാബേസ് പുനഃസ്ഥാപിക്കുന്നതിനായി ചെലവഴിച്ച നിരവധി മണിക്കൂറുകൾ ഉൾപ്പെടുന്നു; ഏറ്റവും മോശം സാഹചര്യത്തിൽ, ഒരു ഡെഡ് സെർവർ. നിങ്ങളുടെ ടീമിൽ ഒരു "പഴയ സ്കൂൾ" DBA ആർക്കിടെക്റ്റ് ഉണ്ടെങ്കിൽ, ഒരു സോപാധികമായ SQL ഡെവലപ്പറിൽ നിന്നുള്ള സ്വന്തം ധാരണ അനുസരിച്ച് ഡാറ്റാബേസ് എഡിറ്റ് ചെയ്താൽ എത്ര മോശമായ കാര്യങ്ങൾ സംഭവിക്കുമെന്ന് ക്ഷമയോടെയും ചിന്താപൂർവ്വവും അവനോട് വിശദീകരിക്കുക.

3. മാറ്റങ്ങൾ ഇതിനകം റിപ്പോസിറ്ററിയിലേക്ക് തള്ളിയിട്ടുണ്ടെങ്കിൽ, എഡിറ്റിംഗ് ഒഴിവാക്കുക

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

4. സാധ്യമെങ്കിൽ പരിശോധിച്ചുറപ്പിച്ച ഡാറ്റാബേസ് ബാക്കപ്പുകൾ ഉണ്ടായിരിക്കുക

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

5. സാധ്യമെങ്കിൽ, വികസനത്തിൽ തെളിയിക്കപ്പെട്ട ഡാറ്റാബേസ് ബാക്കപ്പുകൾ ഉപയോഗിക്കുക

ഇത് കരാറുകൾക്കും സ്വകാര്യതയ്ക്കും വിരുദ്ധമല്ലെങ്കിൽ, ഡാറ്റാബേസിൽ വ്യക്തിഗത ഡാറ്റയൊന്നുമില്ല, രണ്ട് സൂര്യനോളം ഭാരമില്ല - ലൈവ് മൈഗ്രേഷൻ സെർവറുകളിൽ ഇത് ഉപയോഗിക്കുന്നതിന് മുമ്പ്, ഡെവലപ്പറുടെ മെഷീനിൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കുമെന്ന് നിങ്ങൾക്ക് പരിശോധിച്ച് കണക്കാക്കാം. മൈഗ്രേഷൻ സമയത്ത് സാധ്യമായ പ്രശ്നങ്ങളിൽ ഏതാണ്ട് 100%.

6. ടീമിലെ മറ്റ് ഡെവലപ്പർമാരുമായി ആശയവിനിമയം നടത്തുക

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

7. നിങ്ങൾ എന്താണ് ചെയ്യുന്നതെന്ന് ചിന്തിക്കുക!

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

കുടുക്കുകൾ

മുകളിലുള്ള ഉപദേശം നിങ്ങൾ പാലിച്ചില്ലെങ്കിൽ നിങ്ങൾക്ക് വീഴാവുന്ന സാധാരണ കെണികൾ നോക്കാം, കൃത്യമായി എന്താണ് ചെയ്യേണ്ടത്?

സാഹചര്യം 1: രണ്ട് ഡെവലപ്പർമാർ ഒരേ സമയം പുതിയ മാറ്റങ്ങൾ ചേർക്കാൻ ശ്രമിക്കുന്നു

വാസ്യയും പെത്യയും പരസ്പരം അറിയാതെ ഒരു മാറ്റങ്ങളുടെ പതിപ്പ് 4 സൃഷ്ടിക്കാൻ ആഗ്രഹിക്കുന്നു. അവർ ഡാറ്റാബേസ് ഘടനയിൽ മാറ്റങ്ങൾ വരുത്തുകയും വ്യത്യസ്ത ചേഞ്ച്സെറ്റ് ഫയലുകൾ ഉപയോഗിച്ച് ഒരു പുൾ അഭ്യർത്ഥന നൽകുകയും ചെയ്തു. ഇനിപ്പറയുന്ന പ്രവർത്തന സംവിധാനം നിർദ്ദേശിക്കപ്പെടുന്നു:

എങ്ങനെ തീരുമാനിക്കും

1. എങ്ങനെയെങ്കിലും, സഹപ്രവർത്തകർ അവരുടെ മാറ്റങ്ങളുടെ ക്രമം അംഗീകരിക്കണം, ഉദാഹരണത്തിന്, പെറ്റിൻ ആദ്യം പ്രയോഗിക്കണം.
2. ആരെങ്കിലും രണ്ടാമത്തേത് സ്വയം ചേർക്കുകയും വാസ്യയുടെ മാറ്റം പതിപ്പ് 5 ഉപയോഗിച്ച് അടയാളപ്പെടുത്തുകയും വേണം. ഇത് ചെറി പിക്കിലൂടെയോ വൃത്തിയായി ലയിപ്പിക്കുന്നതിലൂടെയോ ചെയ്യാം.
3. മാറ്റങ്ങൾക്ക് ശേഷം, എടുത്ത പ്രവർത്തനങ്ങളുടെ സാധുത നിങ്ങൾ തീർച്ചയായും പരിശോധിക്കണം.
   വാസ്തവത്തിൽ, ലിക്വിബേസ് മെക്കാനിസങ്ങൾ റിപ്പോസിറ്ററിയിൽ രണ്ട് പതിപ്പ് 4 മാറ്റങ്ങളെ അനുവദിക്കും, അതിനാൽ നിങ്ങൾക്ക് എല്ലാം അതേപടി ഉപേക്ഷിക്കാം. അതായത്, വ്യത്യസ്ത പേരുകളുള്ള പതിപ്പ് 4-ൽ നിങ്ങൾക്ക് രണ്ട് മാറ്റങ്ങളുണ്ടാകും. ഈ സമീപനത്തിലൂടെ, പിന്നീട് ഡാറ്റാബേസ് പതിപ്പുകൾ നാവിഗേറ്റ് ചെയ്യുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്.

കൂടാതെ, ഹോബിറ്റുകളുടെ വീട് പോലെ ലിക്വിബേസ് പല രഹസ്യങ്ങളും സൂക്ഷിക്കുന്നു. അവയിലൊന്നാണ് സാധുതയുള്ള ചെക്ക്സം കീ, അത് പതിപ്പ് 1.7 ൽ പ്രത്യക്ഷപ്പെട്ടു കൂടാതെ ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്നതെന്തും പരിഗണിക്കാതെ തന്നെ ഒരു നിർദ്ദിഷ്ട മാറ്റത്തിനായി സാധുവായ ഹാഷ് മൂല്യം വ്യക്തമാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. പ്രമാണീകരണം https://www.liquibase.org/documentation/changeset.html ഇനിപ്പറയുന്നവ പറയുന്നു:

ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്നത് പരിഗണിക്കാതെ തന്നെ, ഈ മാറ്റം സെറ്റിന് സാധുതയുള്ളതായി കണക്കാക്കുന്ന ഒരു ചെക്ക്സം ചേർക്കുക. നിങ്ങൾ ഒരു ചേഞ്ച്‌സെറ്റ് മാറ്റേണ്ടതും അത് ഇതിനകം പ്രവർത്തിച്ച ഡാറ്റാബേസുകളിൽ പിശകുകൾ വരുത്തേണ്ടതില്ലാത്തതും പ്രാഥമികമായി ഉപയോഗിക്കുന്നു (ശുപാർശ ചെയ്ത നടപടിക്രമമല്ല)

അതെ, അതെ, ഈ നടപടിക്രമം ശുപാർശ ചെയ്തിട്ടില്ല. എന്നാൽ ചിലപ്പോൾ ഒരു ശക്തമായ ലൈറ്റ് മാന്ത്രികൻ ഇരുണ്ട ടെക്നിക്കുകളും മാസ്റ്റേഴ്സ് ചെയ്യുന്നു

സാഹചര്യം 2: ഡാറ്റയെ ആശ്രയിച്ചിരിക്കുന്ന മൈഗ്രേഷൻ

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

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

എങ്ങനെ തീരുമാനിക്കും

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

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

സാഹചര്യം 3. ലിക്വിബേസ് ഉൽപ്പാദനത്തിലേക്ക് പോയതിനുശേഷം അത് ഉപയോഗിക്കാൻ തുടങ്ങുന്നു

പ്രോജക്റ്റിൽ ലിക്വിബേസ് ഉൾപ്പെടുത്താൻ ടീം ലീഡ് പെറ്റിയയോട് ആവശ്യപ്പെട്ടുവെന്ന് കരുതുക, എന്നാൽ പ്രോജക്റ്റ് ഇതിനകം നിർമ്മാണത്തിലാണ്, കൂടാതെ നിലവിലുള്ള ഒരു ഡാറ്റാബേസ് ഘടനയുമുണ്ട്.

അതനുസരിച്ച്, ഏതെങ്കിലും പുതിയ സെർവറുകളിലോ ഡവലപ്പർ മെഷീനുകളിലോ, ഈ ടേബിളുകൾ ആദ്യം മുതൽ പുനർനിർമ്മിക്കണം, നിലവിലുള്ള പരിതസ്ഥിതി സ്ഥിരമായ അവസ്ഥയിൽ തുടരണം, പുതിയ മാറ്റങ്ങൾ സ്വീകരിക്കാൻ തയ്യാറായിരിക്കണം.

എങ്ങനെ തീരുമാനിക്കും

കൂടാതെ, നിരവധി മാർഗങ്ങളുണ്ട്:

• ഒരു പുതിയ പരിതസ്ഥിതി ആരംഭിക്കുമ്പോൾ സ്വമേധയാ പ്രയോഗിക്കേണ്ട ഒരു പ്രത്യേക സ്ക്രിപ്റ്റ് ഉണ്ടായിരിക്കുക എന്നതാണ് ആദ്യത്തേതും ഏറ്റവും വ്യക്തവുമായത്.
• രണ്ടാമത്തേത് വ്യക്തമല്ല, മറ്റൊരു ലിക്വിബേസ് സന്ദർഭത്തിലുള്ള ഒരു ലിക്വിബേസ് മൈഗ്രേഷൻ ഉണ്ടായിരിക്കുകയും അത് പ്രയോഗിക്കുകയും ചെയ്യുക. Liquibase സന്ദർഭത്തെക്കുറിച്ച് നിങ്ങൾക്ക് ഇവിടെ കൂടുതൽ വായിക്കാം: https://www.liquibase.org/documentation/contexts.html. പൊതുവേ, ഇത് വിജയകരമായി ഉപയോഗിക്കാൻ കഴിയുന്ന രസകരമായ ഒരു സംവിധാനമാണ്, ഉദാഹരണത്തിന്, പരിശോധനയ്ക്കായി.
• മൂന്നാമത്തെ പാതയിൽ നിരവധി ഘട്ടങ്ങളുണ്ട്. ആദ്യം, നിലവിലുള്ള പട്ടികകൾക്കായി ഒരു മൈഗ്രേഷൻ സൃഷ്ടിക്കേണ്ടതുണ്ട്. അപ്പോൾ അത് ചില പരിതസ്ഥിതിയിൽ പ്രയോഗിക്കണം, അങ്ങനെ അതിന്റെ ഹാഷ് തുക ലഭിക്കും. ഞങ്ങളുടെ ശൂന്യമല്ലാത്ത സെർവറിൽ ശൂന്യമായ ലിക്വിബേസ് ടേബിളുകൾ സമാരംഭിക്കുക എന്നതാണ് അടുത്ത ഘട്ടം, കൂടാതെ മാറ്റങ്ങളുടെ ഉപയോഗത്തിന്റെ ചരിത്രമുള്ള പട്ടികയിൽ, ഡാറ്റാബേസിൽ ഇതിനകം നിലവിലുള്ള മാറ്റങ്ങളുള്ള "പ്രയോഗിച്ചതുപോലെ" മാറ്റങ്ങളെക്കുറിച്ച് നിങ്ങൾക്ക് സ്വമേധയാ ഒരു റെക്കോർഡ് ഇടാം. . അങ്ങനെ, നിലവിലുള്ള ഒരു സെർവറിൽ, ചരിത്ര കൗണ്ട്ഡൗൺ പതിപ്പ് 2 മുതൽ ആരംഭിക്കും, കൂടാതെ എല്ലാ പുതിയ പരിതസ്ഥിതികളും ഒരേപോലെ പ്രവർത്തിക്കും.
  

സാഹചര്യം 4. മൈഗ്രേഷനുകൾ വളരെ വലുതായിത്തീരുന്നു, പൂർത്തിയാക്കാൻ സമയമില്ല

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

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

എങ്ങനെ തീരുമാനിക്കും

അത്തരം സന്ദർഭങ്ങളിൽ, നിങ്ങളുടെ പ്രോജക്റ്റ് ഇതിനകം തന്നെ വലുതാണ്, ഒരുപക്ഷേ പ്രായപൂർത്തിയായവർ പോലും, ലിക്വിബേസ് ഒരു പ്രത്യേക ബാഹ്യ ഉപകരണമായി പ്രവർത്തിക്കാൻ തുടങ്ങുന്നു. ഒരു ലൈബ്രറി എന്ന നിലയിൽ ലിക്വിബേസ് ഒരു ജാർ ഫയലിലേക്ക് സമാഹരിച്ചിരിക്കുന്നു, കൂടാതെ ഒരു പ്രോജക്റ്റിനുള്ളിലോ സ്വതന്ത്രമായോ ഒരു ഡിപൻഡൻസിയായി പ്രവർത്തിക്കാൻ കഴിയും എന്നതാണ് വസ്തുത.

ഒറ്റപ്പെട്ട മോഡിൽ, നിങ്ങളുടെ CI/CD പരിതസ്ഥിതിയിലേക്കോ നിങ്ങളുടെ സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാരുടെയും വിന്യാസ വിദഗ്ധരുടെയും ശക്തമായ ചുമലുകളിലേക്കോ മൈഗ്രേഷനുകൾ നടപ്പിലാക്കുന്നത് നിങ്ങൾക്ക് ഉപേക്ഷിക്കാവുന്നതാണ്. ഇത് ചെയ്യുന്നതിന് നിങ്ങൾക്ക് Liquibase കമാൻഡ് ലൈൻ ആവശ്യമാണ് https://www.liquibase.org/documentation/command_line.html. ഈ മോഡിൽ, ആവശ്യമായ എല്ലാ മൈഗ്രേഷനുകളും നടത്തിയതിന് ശേഷം ആപ്ലിക്കേഷൻ സമാരംഭിക്കുന്നത് സാധ്യമാകും.

തീരുമാനം

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

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