ആമുഖം

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

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

ഇപ്പോൾ മാനേജ്‌മെന്റ് അനുവദിച്ചു MIT ലൈസൻസിന് കീഴിലുള്ള ഓപ്പൺ സോഴ്‌സ് കമ്മ്യൂണിറ്റിക്ക് പ്രോജക്റ്റ് തുറക്കുക. README ഉടൻ തന്നെ ഇംഗ്ലീഷിലേക്ക് വിവർത്തനം ചെയ്യപ്പെടും (കാരണം പ്രധാന ഉപഭോക്താക്കൾ പേസ്മേക്കറും PostgreSQL ഡവലപ്പർമാരുമാകുമെന്ന് പ്രതീക്ഷിക്കുന്നു), കൂടാതെ README യുടെ പഴയ റഷ്യൻ പതിപ്പ് (ഭാഗികമായി) ഈ ലേഖനത്തിന്റെ രൂപത്തിൽ അവതരിപ്പിക്കാൻ ഞാൻ തീരുമാനിച്ചു.

വെർച്വൽ മെഷീനുകളിൽ ക്ലസ്റ്ററുകൾ വിന്യസിച്ചിരിക്കുന്നു VirtualBox. മൊത്തം 12 വെർച്വൽ മെഷീനുകൾ (ആകെ 36GiB) വിന്യസിക്കും, അവ 4 തെറ്റ്-സഹിഷ്ണുത ക്ലസ്റ്ററുകൾ (വ്യത്യസ്ത ഓപ്ഷനുകൾ) രൂപീകരിക്കും. ആദ്യത്തെ രണ്ട് ക്ലസ്റ്ററുകളിൽ രണ്ട് PostgreSQL സെർവറുകൾ അടങ്ങിയിരിക്കുന്നു, അവ വ്യത്യസ്ത ഡാറ്റാ സെന്ററുകളിലും ഒരു പൊതു സെർവറിലുമാണ്. സാക്ഷി c കോറം ഉപകരണം (മൂന്നാം ഡാറ്റാ സെന്ററിലെ വിലകുറഞ്ഞ വെർച്വൽ മെഷീനിൽ ഹോസ്റ്റ് ചെയ്‌തിരിക്കുന്നു), ഇത് അനിശ്ചിതത്വം പരിഹരിക്കുന്നു 50% / 50%, ഒരു പാർട്ടിക്ക് നിങ്ങളുടെ വോട്ട് നൽകുക. മൂന്ന് ഡാറ്റാ സെന്ററുകളിലെ മൂന്നാമത്തെ ക്ലസ്റ്റർ: ഒരു മാസ്റ്റർ, രണ്ട് അടിമകൾ, നമ്പർ കോറം ഉപകരണം. നാലാമത്തെ ക്ലസ്റ്ററിൽ നാല് PostgreSQL സെർവറുകൾ ഉൾപ്പെടുന്നു, ഓരോ ഡാറ്റാ സെന്ററിനും രണ്ട്: ഒരു മാസ്റ്റർ, ബാക്കിയുള്ള പകർപ്പുകൾ, കൂടാതെ ഉപയോഗങ്ങളും സാക്ഷി c കോറം ഉപകരണം. നാലാമത്തേതിന് രണ്ട് സെർവറുകളുടെയോ ഒരു ഡാറ്റാ സെന്ററിന്റെയോ പരാജയത്തെ നേരിടാൻ കഴിയും. ആവശ്യമെങ്കിൽ ഈ പരിഹാരം കൂടുതൽ പകർപ്പുകളിലേക്ക് സ്കെയിൽ ചെയ്യാം.

കൃത്യമായ സമയ സേവനം ntpd തെറ്റ് സഹിഷ്ണുതയ്ക്കായി വീണ്ടും ക്രമീകരിച്ചു, പക്ഷേ അത് രീതി തന്നെ ഉപയോഗിക്കുന്നു ntpd (അനാഥ മോഡ്). പങ്കിട്ട സെർവർ സാക്ഷി ഒരു സെൻട്രൽ NTP സെർവറായി പ്രവർത്തിക്കുന്നു, അതിന്റെ സമയം എല്ലാ ക്ലസ്റ്ററുകൾക്കും വിതരണം ചെയ്യുന്നു, അതുവഴി എല്ലാ സെർവറുകളും പരസ്പരം സമന്വയിപ്പിക്കുന്നു. എങ്കിൽ സാക്ഷി പരാജയപ്പെടുകയോ ഒറ്റപ്പെടുകയോ ചെയ്താൽ, ക്ലസ്റ്റർ സെർവറുകളിൽ ഒന്ന് (ക്ലസ്റ്ററിനുള്ളിൽ) അതിന്റെ സമയം വിതരണം ചെയ്യാൻ തുടങ്ങും. ഓക്സിലറി കാഷിംഗ് HTTP പ്രോക്സി വരെ ഉയർത്തി സാക്ഷി, അതിന്റെ സഹായത്തോടെ, മറ്റ് വെർച്വൽ മെഷീനുകൾക്ക് Yum റിപ്പോസിറ്ററികളിലേക്ക് ആക്സസ് ഉണ്ട്. യഥാർത്ഥത്തിൽ, കൃത്യമായ സമയവും പ്രോക്‌സികളും പോലുള്ള സേവനങ്ങൾ മിക്കവാറും സമർപ്പിത സെർവറുകളിൽ ഹോസ്റ്റ് ചെയ്യപ്പെടും, എന്നാൽ ബൂത്തിൽ അവ ഹോസ്റ്റ് ചെയ്‌തിരിക്കുന്നു സാക്ഷി വെർച്വൽ മെഷീനുകളുടെ എണ്ണവും സ്ഥലവും ലാഭിക്കാൻ മാത്രം.

പതിപ്പുകൾ

v0. VirtualBox 7-ൽ CentOS 11, PostgreSQL 6.1 എന്നിവയിൽ പ്രവർത്തിക്കുന്നു.

ക്ലസ്റ്റർ ഘടന

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

പകരം, സിസ്റ്റം കോറം എന്ന ആശയത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. എല്ലാ നോഡുകൾക്കും ഒരു ശബ്ദമുണ്ട്, കൂടാതെ എല്ലാ നോഡുകളുടെയും പകുതിയിൽ കൂടുതൽ കാണാൻ കഴിയുന്നവയ്ക്ക് മാത്രമേ പ്രവർത്തിക്കാൻ കഴിയൂ. "പകുതി + 1" എന്നതിന്റെ ഈ അളവിനെ വിളിക്കുന്നു കോറം. ക്വാറം എത്തിയില്ലെങ്കിൽ, അത് നെറ്റ്‌വർക്ക് ഐസൊലേഷനിലാണെന്നും അതിന്റെ ഉറവിടങ്ങൾ ഓഫാക്കണമെന്നും നോഡ് തീരുമാനിക്കുന്നു, അതായത്. ഇതാണ് അത് പിളർപ്പ്-മസ്തിഷ്ക സംരക്ഷണം. ഈ സ്വഭാവത്തിന് ഉത്തരവാദിയായ സോഫ്‌റ്റ്‌വെയർ പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, ഒരു വാച്ച്ഡോഗ്, ഉദാഹരണത്തിന്, IPMI അടിസ്ഥാനമാക്കി, പ്രവർത്തിക്കേണ്ടിവരും.

നോഡുകളുടെ എണ്ണം തുല്യമാണെങ്കിൽ (രണ്ട് ഡാറ്റാ സെന്ററുകളിലെ ഒരു ക്ലസ്റ്റർ), അനിശ്ചിതത്വം എന്ന് വിളിക്കപ്പെടുന്നവ ഉണ്ടാകാം 50% / 50% (ഫിഫ്റ്റി ഫിഫ്റ്റി) നെറ്റ്‌വർക്ക് ഐസൊലേഷൻ ക്ലസ്റ്ററിനെ കൃത്യമായി പകുതിയായി വിഭജിക്കുമ്പോൾ. അതിനാൽ, ഇരട്ട എണ്ണം നോഡുകൾക്കായി, ഞങ്ങൾ ചേർക്കുന്നു കോറം ഉപകരണം മൂന്നാമത്തെ ഡാറ്റാ സെന്ററിലെ ഏറ്റവും വിലകുറഞ്ഞ വെർച്വൽ മെഷീനിൽ ലോഞ്ച് ചെയ്യാൻ കഴിയുന്ന ഒരു ആവശ്യപ്പെടാത്ത ഡെമൺ ആണ്. അവൻ തന്റെ വോട്ട് സെഗ്‌മെന്റുകളിലൊന്നിന് നൽകുന്നു (അത് അവൻ കാണുന്നു), അതുവഴി 50%/50% അനിശ്ചിതത്വം പരിഹരിക്കുന്നു. കോറം ഉപകരണം ലോഞ്ച് ചെയ്യുന്ന സെർവറിന് ഞാൻ പേര് നൽകി സാക്ഷി (repmgr-ൽ നിന്നുള്ള പദാവലി, എനിക്കത് ഇഷ്ടപ്പെട്ടു).

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

തുചങ്ക1 (കോംപാക്ഷൻ ഉള്ള സർക്യൂട്ട്)

ഘടന

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

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

രണ്ട് നോഡുകളുടെ കാര്യത്തിൽ, അസിൻക്രണസ് റെപ്ലിക്കേഷനിൽ മാത്രമേ തെറ്റ് സഹിഷ്ണുത സാധ്യമാകൂ, കാരണം സിൻക്രണസ് റെപ്ലിക്കേഷനിൽ, ഒരു സ്ലേവിന്റെ പരാജയം യജമാനനെ നിർത്തുന്നതിലേക്ക് നയിക്കും.

സാക്ഷ്യം വഹിക്കുന്നതിൽ പരാജയം

സാക്ഷ്യം വഹിക്കുന്നതിൽ പരാജയം (കോറം ഉപകരണം) ഞാൻ Tuchanka1 ക്ലസ്റ്ററിനായി മാത്രം പരിഗണിക്കും, മറ്റെല്ലാവർക്കും ഇത് ഒരേ കഥയായിരിക്കും. സാക്ഷി പരാജയപ്പെട്ടാൽ, ക്ലസ്റ്റർ ഘടനയിൽ ഒന്നും മാറില്ല, എല്ലാം അത് ചെയ്തതുപോലെ തന്നെ പ്രവർത്തിക്കും. എന്നാൽ കോറം 2-ൽ 3 ആയി മാറും, അതിനാൽ തുടർന്നുള്ള ഏതെങ്കിലും പരാജയം ക്ലസ്റ്ററിന് മാരകമായിരിക്കും. അത് ഇനിയും അടിയന്തരമായി പരിഹരിക്കേണ്ടതുണ്ട്.

തുചങ്ക1 വിസമ്മതം

Tuchanka1 നായുള്ള ഡാറ്റാ സെന്ററുകളിലൊന്നിന്റെ പരാജയം. ഈ സാഹചര്യത്തിൽ സാക്ഷി രണ്ടാമത്തെ ഡാറ്റാ സെന്ററിലെ രണ്ടാമത്തെ നോഡിലേക്ക് വോട്ട് രേഖപ്പെടുത്തുന്നു. അവിടെ, മുൻ അടിമ ഒരു യജമാനനായി മാറുന്നു, തൽഫലമായി, രണ്ട് യജമാനന്മാരും ഒരേ സെർവറിൽ പ്രവർത്തിക്കുന്നു, അവരുടെ രണ്ട് ഫ്ലോട്ട് ഐപികളും അവരെ ചൂണ്ടിക്കാണിക്കുന്നു.

തുചങ്ക2 (ക്ലാസിക്കൽ)

ഘടന

രണ്ട് നോഡുകളുടെ ക്ലാസിക് സ്കീം. യജമാനൻ ഒന്നിൽ പ്രവർത്തിക്കുന്നു, അടിമ രണ്ടാമത്തേതിൽ. രണ്ടിനും അഭ്യർത്ഥനകൾ നടപ്പിലാക്കാൻ കഴിയും (സ്ലേവ് വായിക്കാൻ മാത്രം), അതിനാൽ രണ്ടും ഫ്ലോട്ട് IP വഴി ചൂണ്ടിക്കാണിക്കുന്നു: krogan2 ആണ് യജമാനൻ, krogan2s1 അടിമയാണ്. യജമാനനും അടിമക്കും തെറ്റ് സഹിഷ്ണുത ഉണ്ടായിരിക്കും.

രണ്ട് നോഡുകളുടെ കാര്യത്തിൽ, തെറ്റ് സഹിഷ്ണുത അസിൻക്രണസ് റെപ്ലിക്കേഷൻ ഉപയോഗിച്ച് മാത്രമേ സാധ്യമാകൂ, കാരണം സിൻക്രണസ് റെപ്ലിക്കേഷൻ ഉപയോഗിച്ച്, സ്ലേവിന്റെ പരാജയം യജമാനന്റെ സ്റ്റോപ്പിലേക്ക് നയിക്കും.

തുചങ്ക2 വിസമ്മതം

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

തുച്ചങ്ക4 (പല അടിമകൾ)

ഘടന

ഇതിനകം മറ്റൊരു തീവ്രത. ധാരാളം റീഡ്-ഒൺലി അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്ന ഡാറ്റാബേസുകൾ ഉണ്ട് (ഉയർന്ന ലോഡ് സൈറ്റിന്റെ ഒരു സാധാരണ കേസ്). അത്തരം അഭ്യർത്ഥനകൾ കൈകാര്യം ചെയ്യാൻ മൂന്നോ അതിലധികമോ അടിമകൾ ഉണ്ടായേക്കാവുന്ന ഒരു സാഹചര്യമാണ് Tuchanka4, എന്നാൽ ഇപ്പോഴും അധികമില്ല. വളരെയധികം അടിമകൾ ഉള്ളതിനാൽ, ഒരു ശ്രേണിപരമായ തനിപ്പകർപ്പ് സംവിധാനം കണ്ടുപിടിക്കേണ്ടത് ആവശ്യമാണ്. ഏറ്റവും കുറഞ്ഞ സാഹചര്യത്തിൽ (ചിത്രത്തിൽ), രണ്ട് ഡാറ്റാ സെന്ററുകളിൽ ഓരോന്നിനും രണ്ട് സെർവറുകൾ ഉണ്ട്, ഓരോന്നിനും ഒരു PostgreSQL ഉദാഹരണമുണ്ട്.

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

തുചങ്ക4 വിസമ്മതം

ഒരു ഡാറ്റാ സെന്റർ (അതായത്, രണ്ട് സെർവറുകൾ) പരാജയപ്പെടുകയാണെങ്കിൽ, രണ്ടാമത്തേതിന് സാക്ഷി വോട്ട് ചെയ്യുന്നു. തൽഫലമായി, രണ്ടാമത്തെ ഡാറ്റാ സെന്ററിൽ രണ്ട് സെർവറുകൾ പ്രവർത്തിക്കുന്നു: ഒന്ന് മാസ്റ്റർ പ്രവർത്തിപ്പിക്കുന്നു, കൂടാതെ മാസ്റ്റർ ഫ്ലോട്ട് ഐപി അതിലേക്ക് പോയിന്റ് ചെയ്യുന്നു (റീഡ്-റൈറ്റ് അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്നതിന്); രണ്ടാമത്തെ സെർവറിൽ സിൻക്രണസ് റെപ്ലിക്കേഷനുമായി ഒരു സ്ലേവ് പ്രവർത്തിക്കുന്നു, സ്ലേവ് ഫ്ലോട്ട് ഐപികളിലൊന്ന് അതിലേക്ക് ചൂണ്ടിക്കാണിക്കുന്നു (വായന-മാത്രം അഭ്യർത്ഥനകൾക്ക്).

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

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

തുചങ്ക3 (3 ഡാറ്റാ സെന്ററുകൾ)

ഘടന

പൂർണ്ണമായി പ്രവർത്തിക്കുന്ന മൂന്ന് ഡാറ്റാ സെന്ററുകൾ ഉള്ള ഒരു സാഹചര്യത്തിനായുള്ള ഒരു ക്ലസ്റ്ററാണിത്, അവയിൽ ഓരോന്നിനും പൂർണ്ണമായി പ്രവർത്തിക്കുന്ന ഒരു ഡാറ്റാബേസ് സെർവർ ഉണ്ട്. ഈ സാഹചര്യത്തിൽ കോറം ഉപകരണം ആവശ്യമില്ല. ഒരു ഡാറ്റാ സെന്ററിൽ ഒരു യജമാനൻ ജോലി ചെയ്യുന്നു, മറ്റ് രണ്ടെണ്ണം അടിമകളാണ്. റെപ്ലിക്കേഷൻ സിൻക്രണസ് ആണ്, ഏതെങ്കിലും (സ്ലേവ്1, സ്ലേവ്2) എന്ന് ടൈപ്പ് ചെയ്യുക, അതായത്, കമ്മിറ്റ് അംഗീകരിച്ചതായി ഏതെങ്കിലും അടിമ ആദ്യം പ്രതികരിക്കുമ്പോൾ ക്ലയന്റിന് ഒരു കമ്മിറ്റ് സ്ഥിരീകരണം ലഭിക്കും. ഉറവിടങ്ങൾ യജമാനന് ഒരു ഫ്ലോട്ട് ഐപിയും അടിമകൾക്ക് രണ്ടെണ്ണവും സൂചിപ്പിക്കുന്നു. Tuchanka4-ൽ നിന്ന് വ്യത്യസ്തമായി, മൂന്ന് ഫ്ലോട്ട് ഐപികളും തെറ്റ്-സഹിഷ്ണുതയുള്ളവയാണ്. നിങ്ങൾക്ക് ഉപയോഗിക്കാവുന്ന റീഡ്-ഒൺലി SQL അന്വേഷണങ്ങൾ ബാലൻസ് ചെയ്യാൻ sql പ്രോക്സി (പ്രത്യേക തെറ്റ് സഹിഷ്ണുതയോടെ), അല്ലെങ്കിൽ പകുതി ക്ലയന്റുകൾക്ക് ഒരു സ്ലേവ് ഫ്ലോട്ട് ഐപി നൽകുക, മറ്റേ പകുതി രണ്ടാമത്തേതിന്.

തുചങ്ക3 വിസമ്മതം

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

ഫയൽ ഘടനയുടെയും വിന്യാസത്തിന്റെയും വിശദമായ വിവരണം ഉൾപ്പെടുത്തേണ്ടതില്ലെന്ന് ഞാൻ തീരുമാനിച്ചു. ചുറ്റും കളിക്കാൻ ആഗ്രഹിക്കുന്ന ആർക്കും README-ൽ അതെല്ലാം വായിക്കാനാകും. ഞാൻ ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗിന്റെ ഒരു വിവരണം മാത്രമാണ് നൽകുന്നത്.

ഓട്ടോമാറ്റിക് ടെസ്റ്റിംഗ് സിസ്റ്റം

വിവിധ തകരാറുകൾ അനുകരിച്ച് ക്ലസ്റ്ററുകളുടെ തെറ്റ് സഹിഷ്ണുത പരിശോധിക്കുന്നതിന്, ഒരു ഓട്ടോമാറ്റിക് ടെസ്റ്റിംഗ് സിസ്റ്റം സൃഷ്ടിച്ചു. സ്ക്രിപ്റ്റ് മുഖേന ആരംഭിച്ചു test/failure. നിങ്ങൾ പരീക്ഷിക്കാൻ ആഗ്രഹിക്കുന്ന ക്ലസ്റ്ററുകളുടെ എണ്ണം സ്ക്രിപ്റ്റിന് പാരാമീറ്ററുകളായി എടുക്കാം. ഉദാഹരണത്തിന് ഈ കമാൻഡ്:

test/failure 2 3

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

ടെസ്റ്റ് ചെയ്യുന്ന ക്ലസ്റ്ററുകളുടെ എണ്ണം അനുസരിച്ച് ടെർമിനലിനെ നിരകളായി തിരിച്ചിരിക്കുന്നു; സ്ഥിരസ്ഥിതിയായി (സ്ക്രീൻഷോട്ടിൽ) നാലെണ്ണം ഉണ്ട്. Tuchanka2 ന്റെ ഉദാഹരണം ഉപയോഗിച്ച് നിരകളുടെ ഉള്ളടക്കം ഞാൻ വിവരിക്കും. സ്ക്രീൻഷോട്ടിലെ പാനലുകൾ അക്കമിട്ടിരിക്കുന്നു:

1. ടെസ്റ്റ് സ്ഥിതിവിവരക്കണക്കുകൾ ഇവിടെ പ്രദർശിപ്പിച്ചിരിക്കുന്നു. നിരകൾ:
   • പരാജയം - തെറ്റ് അനുകരിക്കുന്ന ടെസ്റ്റിന്റെ പേര് (സ്ക്രിപ്റ്റിലെ പ്രവർത്തനം).
   • പ്രതികരണം — ഗണിത ശരാശരി സമയം, ഈ സമയത്ത് ക്ലസ്റ്റർ അതിന്റെ പ്രവർത്തനക്ഷമത വീണ്ടെടുക്കുന്നു. ഒരു തകരാർ അനുകരിക്കുന്ന സ്ക്രിപ്റ്റിന്റെ തുടക്കം മുതൽ ക്ലസ്റ്റർ അതിന്റെ പ്രവർത്തനം പുനഃസ്ഥാപിക്കുകയും സേവനങ്ങൾ നൽകുന്നത് തുടരുകയും ചെയ്യുന്ന നിമിഷം വരെ ഇത് അളക്കുന്നു. സമയം വളരെ ചെറുതാണെങ്കിൽ, ഉദാഹരണത്തിന്, ആറ് സെക്കൻഡ് (ഇത് നിരവധി അടിമകളുള്ള ക്ലസ്റ്ററുകളിലാണ് സംഭവിക്കുന്നത് (തുച്ചങ്ക 3, ടുചങ്ക 4)), ഇതിനർത്ഥം തെറ്റ് അസിൻക്രണസ് സ്ലേവിലായിരുന്നുവെന്നും പ്രകടനത്തെ ഒരു തരത്തിലും ബാധിച്ചില്ല; ഇല്ലായിരുന്നു. ക്ലസ്റ്റർ സ്റ്റേറ്റ് സ്വിച്ചുകൾ.
   • വ്യതിയാനം - മൂല്യത്തിന്റെ വ്യാപനം (കൃത്യത) കാണിക്കുന്നു പ്രതികരണം സ്റ്റാൻഡേർഡ് ഡീവിയേഷൻ രീതി ഉപയോഗിച്ച്.
   • എണ്ണുക - എത്ര തവണ ഈ പരിശോധന നടത്തി.
2. ക്ലസ്റ്റർ നിലവിൽ എന്താണ് ചെയ്യുന്നതെന്ന് വിലയിരുത്താൻ ഒരു ചെറിയ ലോഗ് നിങ്ങളെ അനുവദിക്കുന്നു. പ്രവർത്തനത്തിന്റെ ആവർത്തന (ടെസ്റ്റ്) നമ്പർ, ടൈംസ്റ്റാമ്പ്, പേര് എന്നിവ പ്രദർശിപ്പിക്കും. വളരെ നേരം (> 5 മിനിറ്റ്) ഓടുന്നത് ഒരു പ്രശ്നത്തെ സൂചിപ്പിക്കുന്നു.
3. ഹൃദയം (ഹൃദയം) - നിലവിലെ സമയം. പ്രകടനത്തിന്റെ വിഷ്വൽ വിലയിരുത്തലിനായി യജമാനന്മാർ ഫ്ലോട്ട് ഐപി മാസ്റ്റർ ഉപയോഗിച്ച് നിലവിലെ സമയം അതിന്റെ ടേബിളിൽ നിരന്തരം എഴുതുന്നു. വിജയകരമാണെങ്കിൽ, ഫലം ഈ പാനലിൽ പ്രദർശിപ്പിക്കും.
4. തല്ലി (പൾസ്) - "നിലവിലെ സമയം", ഇത് മുമ്പ് സ്ക്രിപ്റ്റ് രേഖപ്പെടുത്തിയിട്ടുണ്ട് ഹൃദയം മാസ്റ്റർ, ഇപ്പോൾ വായിക്കുക അടിമ അതിന്റെ ഫ്ലോട്ട് ഐപി വഴി. അടിമയുടെ പ്രകടനവും അനുകരണവും ദൃശ്യപരമായി വിലയിരുത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു. Tuchanka1-ൽ ഫ്ലോട്ട് IP ഉള്ള അടിമകൾ ഇല്ല (സേവനങ്ങൾ നൽകുന്ന അടിമകൾ ഇല്ല), എന്നാൽ രണ്ട് സംഭവങ്ങളുണ്ട് (DBs), അതിനാൽ അത് ഇവിടെ കാണിക്കില്ല തല്ലിഒപ്പം ഹൃദയം രണ്ടാമത്തെ ഉദാഹരണം.
5. യൂട്ടിലിറ്റി ഉപയോഗിച്ച് ക്ലസ്റ്റർ ആരോഗ്യം നിരീക്ഷിക്കുന്നു pcs mon. നോഡുകളിലുടനീളം ഉറവിടങ്ങളുടെ ഘടന, വിതരണം, മറ്റ് ഉപയോഗപ്രദമായ വിവരങ്ങൾ എന്നിവ കാണിക്കുന്നു.
6. ക്ലസ്റ്ററിലെ ഓരോ വെർച്വൽ മെഷീനിൽ നിന്നുമുള്ള സിസ്റ്റം മോണിറ്ററിംഗ് ഇവിടെ പ്രദർശിപ്പിക്കും. ക്ലസ്റ്ററിന് എത്ര വെർച്വൽ മെഷീനുകൾ ഉണ്ട് എന്നതിനെ ആശ്രയിച്ച് അത്തരം കൂടുതൽ പാനലുകൾ ഉണ്ടാകാം. രണ്ട് ഗ്രാഫുകൾ സിപിയു ലോഡ് (വെർച്വൽ മെഷീനുകൾക്ക് രണ്ട് പ്രോസസ്സറുകൾ ഉണ്ട്), വെർച്വൽ മെഷീന്റെ പേര്, സിസ്റ്റം ലോഡ് (ശരാശരി 5, 10, 15 മിനിറ്റുകളിൽ കൂടുതലായതിനാൽ ലോഡ് ആവറേജ് എന്ന് പേരിട്ടു), ഡാറ്റയും മെമ്മറി അലോക്കേഷനും പ്രോസസ്സ് ചെയ്യുക.
7. ടെസ്റ്റിംഗ് നടത്തുന്ന സ്ക്രിപ്റ്റിന്റെ ട്രെയ്സ്. ഒരു തകരാർ സംഭവിച്ചാൽ - പ്രവർത്തനത്തിന്റെ പെട്ടെന്നുള്ള തടസ്സം അല്ലെങ്കിൽ അനന്തമായ കാത്തിരിപ്പ് ചക്രം - ഈ സ്വഭാവത്തിന്റെ കാരണം ഇവിടെ നിങ്ങൾക്ക് കാണാൻ കഴിയും.

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

ഓരോ പരിശോധനയും ഇനിപ്പറയുന്ന പ്രവർത്തനങ്ങൾ ഉൾക്കൊള്ളുന്നു:

1. ഒരു തകരാർ അനുകരിക്കുന്ന ഒരു ഫംഗ്‌ഷൻ സമാരംഭിക്കുക.
2. തയ്യാറാണ്? — ക്ലസ്റ്റർ പുനഃസ്ഥാപിക്കുന്നതിനായി കാത്തിരിക്കുന്നു (എല്ലാ സേവനങ്ങളും നൽകുമ്പോൾ).
3. ക്ലസ്റ്റർ വീണ്ടെടുക്കൽ സമയപരിധി കാണിക്കുന്നു (പ്രതികരണം).
4. ശരിയാക്കുക - ക്ലസ്റ്റർ "അറ്റകുറ്റപ്പണി ചെയ്യുന്നു." അതിനുശേഷം, അത് പൂർണ്ണമായും പ്രവർത്തനക്ഷമമായ അവസ്ഥയിലേക്ക് മടങ്ങുകയും അടുത്ത തകരാറിന് തയ്യാറാകുകയും വേണം.

അവർ ചെയ്യുന്ന കാര്യങ്ങളുടെ വിവരണമുള്ള ടെസ്റ്റുകളുടെ ഒരു ലിസ്റ്റ് ഇതാ:

• ഫോർക്ക്ബോംബ്: ഫോർക്ക് ബോംബ് ഉപയോഗിച്ച് "ഓഫ് ഓഫ് മെമ്മറി" സൃഷ്ടിക്കുന്നു.
• സ്ഥലമില്ല: ഹാർഡ് ഡ്രൈവ് നിറഞ്ഞിരിക്കുന്നു. എന്നാൽ ടെസ്റ്റ് പ്രതീകാത്മകമാണ്; ടെസ്റ്റിംഗ് സമയത്ത് സൃഷ്ടിക്കുന്ന നിസ്സാരമായ ലോഡ് ഉപയോഗിച്ച്, ഹാർഡ് ഡ്രൈവ് നിറയുമ്പോൾ PostgreSQL സാധാരണയായി പരാജയപ്പെടില്ല.
• പോസ്റ്റ്ഗ്രെസ്-കൊല്ലുക: കമാൻഡ് ഉപയോഗിച്ച് PostgreSQL കൊല്ലുന്നു killall -KILL postgres.
• പോസ്റ്റ്ഗ്രെസ്-സ്റ്റോപ്പ്: PostgreSQL കമാൻഡ് ഹാംഗ് ചെയ്യുന്നു killall -STOP postgres.
• പവർഓഫ്: കമാൻഡ് ഉപയോഗിച്ച് വെർച്വൽ മെഷീനെ "ഡി-എനർജിസ്" ചെയ്യുന്നു VBoxManage controlvm "виртуалка" poweroff.
• റീസെറ്റ്: കമാൻഡ് ഉപയോഗിച്ച് വെർച്വൽ മെഷീൻ ഓവർലോഡ് ചെയ്യുന്നു VBoxManage controlvm "виртуалка" reset.
• എസ്ബിഡി-സ്റ്റോപ്പ്: കമാൻഡ് ഉപയോഗിച്ച് SBD ഭൂതത്തെ സസ്പെൻഡ് ചെയ്യുന്നു killall -STOP sbd.
• ഷട്ട് ഡൗൺ: SSH വഴി വെർച്വൽ മെഷീനിലേക്ക് ഒരു കമാൻഡ് അയയ്ക്കുന്നു systemctl poweroff, സിസ്റ്റം ഭംഗിയായി ഷട്ട് ഡൗൺ ചെയ്യുന്നു.
• അൺലിങ്ക് ചെയ്യുക: നെറ്റ്‌വർക്ക് ഐസൊലേഷൻ, കമാൻഡ് VBoxManage controlvm "виртуалка" setlinkstate1 off.

സാധാരണ tmux കമാൻഡ് "kill-window" ഉപയോഗിച്ച് ടെസ്റ്റിംഗ് പൂർത്തിയാക്കുന്നു Ctrl-b &, അല്ലെങ്കിൽ "ഡിറ്റാച്ച്-ക്ലയന്റ്" കമാൻഡ് Ctrl-b d: ഈ ഘട്ടത്തിൽ പരിശോധന അവസാനിക്കുന്നു, tmux അടയുന്നു, വെർച്വൽ മെഷീനുകൾ ഓഫാക്കി.

പരിശോധനയ്ക്കിടെ കണ്ടെത്തിയ പ്രശ്നങ്ങൾ

• ഈ നിമിഷം വാച്ച് ഡോഗ് ഡെമോൺ sbd നിരീക്ഷിച്ച ഡെമണുകളെ നിർത്തുന്നതിൽ പ്രവർത്തിക്കുന്നു, പക്ഷേ അവയെ മരവിപ്പിക്കുന്നില്ല. കൂടാതെ, തൽഫലമായി, മരവിപ്പിക്കുന്നതിലേക്ക് മാത്രം നയിക്കുന്ന പിഴവുകൾ കോറോസിങ്ക് и pacemaker, എന്നാൽ തൂങ്ങിക്കിടക്കുന്നില്ല എസ്ബിഡി... പരിശോധനയ്ക്കായി കോറോസിങ്ക് ഇതിനകം PR#83 (GitHub-ൽ എസ്ബിഡി), ത്രെഡിലേക്ക് സ്വീകരിച്ചു യജമാനന്. പേസ്‌മേക്കറിന് സമാനമായ എന്തെങ്കിലും ഉണ്ടാകുമെന്ന് അവർ (PR#83-ൽ) വാഗ്ദത്തം ചെയ്തു റെഡ്ഹാറ്റ് 8 നമ്മൾ ചെയ്യും. എന്നാൽ അത്തരം "തകരാർ" ഊഹക്കച്ചവടമാണ്, അവ ഉപയോഗിച്ച് കൃത്രിമമായി എളുപ്പത്തിൽ അനുകരിക്കാനാകും, ഉദാഹരണത്തിന്, killall -STOP corosync, എന്നാൽ യഥാർത്ഥ ജീവിതത്തിൽ ഒരിക്കലും കണ്ടുമുട്ടരുത്.

• У pacemaker എന്നതിനായുള്ള പതിപ്പിൽ CentOS 7 തെറ്റായി സജ്ജീകരിച്ചിരിക്കുന്നു sync_timeout у കോറം ഉപകരണംഫലമായി ഒരു നോഡ് പരാജയപ്പെട്ടാൽ, ചില സാധ്യതകളോടെ രണ്ടാമത്തെ നോഡും റീബൂട്ട് ചെയ്യുന്നു, യജമാനൻ നീങ്ങേണ്ടതായിരുന്നു. വലുതാക്കി സുഖപ്പെടുത്തി sync_timeout у കോറം ഉപകരണം വിന്യാസ സമയത്ത് (സ്ക്രിപ്റ്റിൽ setup/setup1). ഈ ഭേദഗതി ഡെവലപ്പർമാർ അംഗീകരിച്ചില്ല pacemaker, പകരം ഈ സമയപരിധി സ്വയമേവ കണക്കാക്കുന്ന തരത്തിൽ (ചില വ്യക്തതയില്ലാത്ത ഭാവിയിൽ) ഇൻഫ്രാസ്ട്രക്ചർ പുനർരൂപകൽപ്പന ചെയ്യുമെന്ന് അവർ വാഗ്ദാനം ചെയ്തു.

• ഡാറ്റാബേസ് കോൺഫിഗറേഷൻ അത് വ്യക്തമാക്കുകയാണെങ്കിൽ LC_MESSAGES (ടെക്സ്റ്റ് സന്ദേശങ്ങൾ) യൂണികോഡ് ഉപയോഗിക്കാം, ഉദാ. ru_RU.UTF-8, പിന്നെ സ്റ്റാർട്ടപ്പിൽ പോസ്റ്റ്ഗ്രെസ് ലൊക്കേൽ UTF-8 അല്ലാത്ത ഒരു പരിതസ്ഥിതിയിൽ, ഒരു ശൂന്യമായ പരിതസ്ഥിതിയിൽ പറയുക (ഇവിടെ പേസ്‌മേക്കർ+pgsqlms(പാഫ്) ഓടുന്നു പോസ്റ്റ്ഗ്രെസ്), പിന്നെ ലോഗിൽ UTF-8 അക്ഷരങ്ങൾക്ക് പകരം ചോദ്യചിഹ്നങ്ങൾ അടങ്ങിയിരിക്കും. ഈ സാഹചര്യത്തിൽ എന്തുചെയ്യണമെന്ന് PostgreSQL ഡെവലപ്പർമാർ സമ്മതിച്ചിട്ടില്ല. ഇത് ചിലവാകും, നിങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യണം LC_MESSAGES=en_US.UTF-8 ഒരു ഡാറ്റാബേസ് ഇൻസ്റ്റൻസ് കോൺഫിഗർ ചെയ്യുമ്പോൾ (സൃഷ്ടിക്കുമ്പോൾ).

• wal_receiver_timeout സജ്ജീകരിച്ചിട്ടുണ്ടെങ്കിൽ (സ്ഥിരസ്ഥിതിയായി ഇത് 60s ആണ്), തുടർന്ന് tuchanka3, tuchanka4 ക്ലസ്റ്ററുകളിലെ മാസ്റ്ററിൽ PostgreSQL-STOP ടെസ്റ്റ് നടത്തുമ്പോൾ പകർപ്പ് പുതിയ മാസ്റ്ററുമായി വീണ്ടും ബന്ധിപ്പിക്കുന്നില്ല. അവിടെ അനുകരണം സമന്വയമാണ്, അതിനാൽ അടിമ നിർത്തുന്നു മാത്രമല്ല, പുതിയ യജമാനനും. PostgreSQL കോൺഫിഗർ ചെയ്യുമ്പോൾ wal_receiver_timeout=0 സജ്ജീകരിച്ച് പ്രവർത്തിക്കുന്നു.

• ForkBomb ടെസ്റ്റിൽ (മെമ്മറി ഓവർഫ്ലോ) PostgreSQL-ൽ പകർപ്പെടുക്കൽ മരവിപ്പിക്കുന്നത് ഞാൻ ഇടയ്ക്കിടെ നിരീക്ഷിച്ചു. ForkBomb കഴിഞ്ഞാൽ, ചിലപ്പോൾ അടിമകൾ പുതിയ യജമാനനുമായി വീണ്ടും കണക്‌റ്റ് ചെയ്‌തേക്കില്ല. tuchanka3, tuchanka4 ക്ലസ്റ്ററുകളിൽ മാത്രമേ ഞാൻ ഇത് നേരിട്ടിട്ടുള്ളൂ, അവിടെ സിൻക്രണസ് റെപ്ലിക്കേഷൻ കാരണം മാസ്റ്റർ മരവിച്ചു. ഏറെ നാളുകൾക്ക് ശേഷം (ഏകദേശം രണ്ട് മണിക്കൂർ) പ്രശ്‌നം തനിയെ പോയി. ഇത് ശരിയാക്കാൻ കൂടുതൽ ഗവേഷണം ആവശ്യമാണ്. രോഗലക്ഷണങ്ങൾ മുമ്പത്തെ ബഗിന് സമാനമാണ്, ഇത് മറ്റൊരു കാരണത്താൽ സംഭവിക്കുന്നു, എന്നാൽ അതേ അനന്തരഫലങ്ങൾ.

ക്രോഗൻ ചിത്രം എടുത്തത് ഡീവിയന്റ് കല രചയിതാവിന്റെ അനുമതിയോടെ:

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