പത്രോണി പരാജയ കഥകൾ അല്ലെങ്കിൽ നിങ്ങളുടെ PostgreSQL ക്ലസ്റ്റർ എങ്ങനെ ക്രാഷ് ചെയ്യാം. അലക്സി ലെസോവ്സ്കി

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

ഞാൻ എന്നെ കുറിച്ച് കുറച്ച് പറയാം. ഞാൻ ഒരു സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്ററായി ആരംഭിച്ചു. വെബ് ഡെവലപ്‌മെന്റിൽ പ്രവർത്തിച്ചു. ഞാൻ 2014 മുതൽ ഡാറ്റ എഗ്രറ്റിൽ ജോലി ചെയ്യുന്നു. കമ്പനി പോസ്റ്റ്ഗ്രെസ് മേഖലയിൽ കൺസൾട്ടിങ്ങിൽ ഏർപ്പെട്ടിരിക്കുകയാണ്. ഞങ്ങൾ കൃത്യമായി പോസ്റ്റ്‌ഗ്രെസിനെ സേവിക്കുന്നു, കൂടാതെ ഞങ്ങൾ എല്ലാ ദിവസവും പോസ്റ്റ്‌ഗ്രെസിനൊപ്പം പ്രവർത്തിക്കുന്നു, അതിനാൽ പ്രവർത്തനവുമായി ബന്ധപ്പെട്ട് ഞങ്ങൾക്ക് വ്യത്യസ്ത വൈദഗ്ധ്യമുണ്ട്.

2018 അവസാനത്തോടെ, ഞങ്ങൾ പതുക്കെ പത്രോണി ഉപയോഗിക്കാൻ തുടങ്ങി. ഒപ്പം കുറച്ച് അനുഭവങ്ങളും ശേഖരിച്ചിട്ടുണ്ട്. ഞങ്ങൾ എങ്ങനെയെങ്കിലും അത് രോഗനിർണ്ണയം നടത്തി, ട്യൂൺ ചെയ്തു, ഞങ്ങളുടെ മികച്ച രീതികളിൽ എത്തി. ഈ റിപ്പോർട്ടിൽ ഞാൻ അവരെക്കുറിച്ച് സംസാരിക്കും.

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

• പോസ്റ്റ്ഗ്രേസിന് എച്ച്എ (ഉയർന്ന ലഭ്യത) ഇല്ലെന്ന് നിങ്ങളിൽ പലർക്കും അറിയാമെന്ന് ഞാൻ കരുതുന്നു. HA ലഭിക്കാൻ, നിങ്ങൾ എന്തെങ്കിലും ഇൻസ്റ്റാൾ ചെയ്യുകയും കോൺഫിഗർ ചെയ്യുകയും പരിശ്രമിക്കുകയും നേടുകയും വേണം.
• നിരവധി ടൂളുകൾ ഉണ്ട്, അവയിലൊന്നാണ് പത്രോണി എച്ച്എയെ വളരെ രസകരവും നന്നായി പരിഹരിക്കുന്നതും. എന്നാൽ ഇതെല്ലാം ഒരു ടെസ്റ്റ് ലാബിൽ ഇട്ട് പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ, എല്ലാം പ്രവർത്തിക്കുന്നത് നമുക്ക് കാണാനാകും, ചില പ്രശ്നങ്ങൾ നമുക്ക് പുനർനിർമ്മിക്കാം, പത്രോണി അവ എങ്ങനെ സേവിക്കുന്നു എന്ന് നോക്കാം. അതെല്ലാം മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് നമുക്ക് കാണാം.
• എന്നാൽ പ്രായോഗികമായി, ഞങ്ങൾ വ്യത്യസ്ത പ്രശ്നങ്ങൾ അഭിമുഖീകരിച്ചു. കൂടാതെ ഞാൻ ഈ പ്രശ്നങ്ങളെക്കുറിച്ച് സംസാരിക്കും.
• ഞങ്ങൾ അത് എങ്ങനെ കണ്ടുപിടിച്ചു, ഞങ്ങൾ എന്താണ് തിരുത്തിയത് - അത് ഞങ്ങളെ സഹായിച്ചോ ഇല്ലയോ എന്ന് ഞാൻ നിങ്ങളോട് പറയും.

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

ഞങ്ങളുടെ റിപ്പോർട്ട് ആരംഭിക്കുന്നതിന് മുമ്പ് ഒരു ചെറിയ നിരാകരണവും.

ഞങ്ങൾ നേരിട്ട ഈ പ്രശ്നങ്ങളെല്ലാം, പ്രവർത്തനത്തിന്റെ ആദ്യ 6-7-8 മാസങ്ങളിൽ ഞങ്ങൾക്ക് അവ ഉണ്ടായിരുന്നു. കാലക്രമേണ, ഞങ്ങൾ ഞങ്ങളുടെ ആന്തരിക മികച്ച രീതികളിലേക്ക് എത്തി. ഒപ്പം ഞങ്ങളുടെ പ്രശ്‌നങ്ങളും ഇല്ലാതായി. അതിനാൽ, ഏകദേശം ആറുമാസം മുമ്പ് റിപ്പോർട്ട് പ്രഖ്യാപിച്ചു, അതെല്ലാം എന്റെ തലയിൽ പുതുമയുള്ളപ്പോൾ, ഞാൻ അതെല്ലാം നന്നായി ഓർത്തു.

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

എന്താണ് പത്രോണി?

• ഇത് HA നിർമ്മിക്കുന്നതിനുള്ള ഒരു ടെംപ്ലേറ്റ് ആണ്. അതാണ് ഡോക്യുമെന്റേഷനിൽ പറയുന്നത്. എന്റെ കാഴ്ചപ്പാടിൽ, ഇത് വളരെ ശരിയായ വ്യക്തതയാണ്. നിങ്ങളുടെ എല്ലാ പ്രശ്നങ്ങളും പരിഹരിക്കുന്ന ഒരു വെള്ളി ബുള്ളറ്റല്ല പത്രോണി, അതായത്, അത് പ്രവർത്തിക്കാനും നേട്ടങ്ങൾ കൊണ്ടുവരാനും നിങ്ങൾ ശ്രമിക്കേണ്ടതുണ്ട്.
• ഇത് എല്ലാ ഡാറ്റാബേസ് സേവനത്തിലും ഇൻസ്റ്റാൾ ചെയ്തിട്ടുള്ള ഒരു ഏജന്റ് സേവനമാണ്, നിങ്ങളുടെ പോസ്റ്റ്ഗ്രെസിനുള്ള ഒരുതരം init സിസ്റ്റമാണിത്. ഇത് Postgres ആരംഭിക്കുന്നു, നിർത്തുന്നു, പുനരാരംഭിക്കുന്നു, പുനഃക്രമീകരിക്കുന്നു, നിങ്ങളുടെ ക്ലസ്റ്ററിന്റെ ടോപ്പോളജി മാറ്റുന്നു.
• അതനുസരിച്ച്, ക്ലസ്റ്ററിന്റെ അവസ്ഥ സംഭരിക്കുന്നതിന്, അതിന്റെ നിലവിലെ പ്രാതിനിധ്യം, കാണുന്നതുപോലെ, ഒരുതരം സംഭരണം ആവശ്യമാണ്. ഈ വീക്ഷണകോണിൽ നിന്ന്, പത്രോണി ഒരു ബാഹ്യ സംവിധാനത്തിൽ അവസ്ഥ സംഭരിക്കുന്നതിനുള്ള പാത സ്വീകരിച്ചു. ഇത് ഒരു വിതരണം ചെയ്ത കോൺഫിഗറേഷൻ സ്റ്റോറേജ് സിസ്റ്റമാണ്. ഇത് Etcd, കോൺസൽ, ZooKeeper അല്ലെങ്കിൽ kubernetes Etcd ആകാം, അതായത് ഈ ഓപ്ഷനുകളിലൊന്ന്.
• കൂടാതെ, അത് സജ്ജീകരിക്കുന്നതിലൂടെ മാത്രമേ നിങ്ങൾക്ക് ഓട്ടോഫയലർ ബോക്സിൽ നിന്ന് പുറത്തെടുക്കൂ എന്നതാണ് പത്രോണിയുടെ ഒരു സവിശേഷത. താരതമ്യത്തിനായി ഞങ്ങൾ Repmgr എടുക്കുകയാണെങ്കിൽ, ഫയലർ അവിടെ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്. Repmgr ഉപയോഗിച്ച്, ഞങ്ങൾക്ക് ഒരു സ്വിച്ച്ഓവർ ലഭിക്കും, എന്നാൽ ഞങ്ങൾക്ക് ഒരു ഓട്ടോഫയലർ വേണമെങ്കിൽ, അത് അധികമായി കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്. പാട്രോണിക്ക് ഇതിനകം തന്നെ ഒരു ഓട്ടോഫയലർ ബോക്‌സിന് പുറത്ത് ഉണ്ട്.
• കൂടാതെ മറ്റു പല കാര്യങ്ങളും ഉണ്ട്. ഉദാഹരണത്തിന്, കോൺഫിഗറേഷനുകളുടെ അറ്റകുറ്റപ്പണികൾ, പുതിയ പകർപ്പുകൾ പകരുക, ബാക്കപ്പ് മുതലായവ. എന്നാൽ ഇത് റിപ്പോർട്ടിന്റെ പരിധിക്കപ്പുറമാണ്, ഞാൻ അതിനെക്കുറിച്ച് സംസാരിക്കില്ല.

ഞങ്ങളുടെ ക്ലസ്റ്റർ പ്രവർത്തനക്ഷമമായി തുടരുന്നതിനും ക്ലസ്റ്റർ ടോപ്പോളജിയിലെ മാറ്റങ്ങൾ ആപ്ലിക്കേഷൻ ശ്രദ്ധിക്കാതിരിക്കുന്നതിനും ഒരു ഓട്ടോഫയൽ മികച്ചതും വിശ്വസനീയവുമായ രീതിയിൽ ചെയ്യുക എന്നതാണ് പത്രോണിയുടെ പ്രധാന ദൗത്യം എന്നതാണ് ഒരു ചെറിയ ഫലം.

എന്നാൽ നമ്മൾ പത്രോണി ഉപയോഗിക്കാൻ തുടങ്ങുമ്പോൾ, നമ്മുടെ സിസ്റ്റം കുറച്ചുകൂടി സങ്കീർണ്ണമാകുന്നു. നേരത്തെ നമുക്ക് Postgres ഉണ്ടായിരുന്നുവെങ്കിൽ, Patroni ഉപയോഗിക്കുമ്പോൾ നമുക്ക് Patroni തന്നെ ലഭിക്കും, സംസ്ഥാനം സംഭരിച്ചിരിക്കുന്ന DCS ലഭിക്കും. കൂടാതെ, എല്ലാം എങ്ങനെയെങ്കിലും പ്രവർത്തിക്കണം. അപ്പോൾ എന്ത് തെറ്റ് സംഭവിക്കാം?

തകർക്കാം:

• പോസ്റ്റ്ഗ്രെസ് തകർന്നേക്കാം. ഇത് ഒരു മാസ്റ്റർ അല്ലെങ്കിൽ ഒരു പകർപ്പ് ആകാം, അവയിലൊന്ന് പരാജയപ്പെട്ടേക്കാം.
• പത്രോണി തന്നെ തകർന്നേക്കാം.
• സംസ്ഥാനം സംഭരിച്ചിരിക്കുന്ന ഡിസിഎസ് തകർന്നേക്കാം.
• നെറ്റ്‌വർക്ക് തകരുകയും ചെയ്യാം.

ഈ പോയിന്റുകളെല്ലാം ഞാൻ റിപ്പോർട്ടിൽ പരിഗണിക്കും.

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

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

അതിനാൽ, ഒരു ഫയലർ ഉണ്ടായിരുന്നു, എന്താണ് സംഭവിച്ചതെന്ന് കൈകാര്യം ചെയ്യാൻ പോകാം.

ഫയലർ എപ്പോഴാണ് സംഭവിച്ചതെന്ന് ഇവിടെ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ട്. അതായത്, ക്ലസ്റ്റർ അവസ്ഥ മാറിയ ഈ നിമിഷത്തിൽ ഞങ്ങൾക്ക് താൽപ്പര്യമുണ്ട്.

എന്നാൽ ഫയലർ എല്ലായ്‌പ്പോഴും തൽക്ഷണം അല്ല, അതായത് സമയത്തിന്റെ ഒരു യൂണിറ്റും എടുക്കുന്നില്ല, അത് വൈകാം. ഇത് ദീർഘകാലം നിലനിൽക്കും.

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

ആദ്യത്തെ കാര്യം, ഒരു ഫയലർ സംഭവിക്കുമ്പോൾ, എന്താണ് സംഭവിച്ചതെന്നതിന്റെ കാരണം, ഫയലറിലേക്ക് നയിച്ചതിന്റെ കാരണം എന്താണെന്ന് ഞങ്ങൾ തിരയുന്നു.

ലോഗുകൾ നോക്കിയാൽ, അവ ക്ലാസിക് പത്രോണി ലോഗുകൾ ആയിരിക്കും. സെർവർ യജമാനനായി മാറിയെന്നും യജമാനന്റെ പങ്ക് ഈ നോഡിലേക്ക് കടന്നുവെന്നും അദ്ദേഹം അവരിൽ നമ്മോട് പറയുന്നു. ഇവിടെ അത് ഹൈലൈറ്റ് ചെയ്യുന്നു.

അടുത്തതായി, ഫയലർ സംഭവിച്ചത് എന്തുകൊണ്ടാണെന്ന് നമ്മൾ മനസ്സിലാക്കേണ്ടതുണ്ട്, അതായത് മാസ്റ്റർ റോൾ ഒരു നോഡിൽ നിന്ന് മറ്റൊന്നിലേക്ക് മാറാൻ കാരണമായ സംഭവങ്ങൾ എന്തൊക്കെയാണ്. ഈ സാഹചര്യത്തിൽ, എല്ലാം ലളിതമാണ്. സ്റ്റോറേജ് സിസ്റ്റവുമായി സംവദിക്കുന്നതിൽ ഞങ്ങൾക്ക് ഒരു പിശകുണ്ട്. ഡിസിഎസുമായി പ്രവർത്തിക്കാൻ കഴിയില്ലെന്ന് മാസ്റ്റർ മനസ്സിലാക്കി, അതായത്, ആശയവിനിമയത്തിൽ ഒരുതരം പ്രശ്നമുണ്ട്. ഇനി തനിക്ക് ഒരു യജമാനനാകാൻ കഴിയില്ലെന്ന് അദ്ദേഹം പറഞ്ഞു രാജിവെക്കുന്നു. "സ്വയം തരംതാഴ്ത്തപ്പെട്ടു" എന്ന ഈ വരി അത് കൃത്യമായി പറയുന്നു.

ഫൈലറിന് മുമ്പുള്ള സംഭവങ്ങൾ പരിശോധിച്ചാൽ, മാന്ത്രികന്റെ തുടർച്ചയ്ക്ക് പ്രശ്നമായ കാരണങ്ങൾ നമുക്ക് അവിടെ കാണാൻ കഴിയും.

Patroni ലോഗുകൾ നോക്കിയാൽ, നമുക്ക് ധാരാളം പിശകുകൾ, കാലഹരണപ്പെടലുകൾ എന്നിവ ഉണ്ടെന്ന് കാണാം, അതായത് Patroni ഏജന്റിന് DCS-ൽ പ്രവർത്തിക്കാൻ കഴിയില്ല. ഈ സാഹചര്യത്തിൽ, ഇത് പോർട്ട് 8500-ൽ ആശയവിനിമയം നടത്തുന്ന കോൺസൽ ഏജന്റാണ്.

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

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

ഇതൊരു തെറ്റായ അലാറമായി കണക്കാക്കാം, അല്ലെങ്കിൽ പത്രോണി എല്ലാം ശരിയായി ചെയ്തുവെന്ന് കണക്കാക്കാം. അതായത്, ക്ലസ്റ്ററിന്റെ അവസ്ഥ നിലനിർത്താൻ കഴിയില്ലെന്ന് അദ്ദേഹം മനസ്സിലാക്കുകയും തന്റെ അധികാരം നീക്കം ചെയ്യുകയും ചെയ്തു.

കോൺസൽ സെർവറുകൾ ബേസുകളുടെ അതേ ഹാർഡ്‌വെയറിലായതിനാലാണ് ഇവിടെ പ്രശ്നം ഉടലെടുത്തത്. അതനുസരിച്ച്, ഏത് ലോഡും: അത് ഡിസ്കുകളിലോ പ്രോസസറുകളിലോ ഉള്ള ലോഡ് ആണെങ്കിലും, ഇത് കോൺസൽ ക്ലസ്റ്ററുമായുള്ള ഇടപെടലിനെയും ബാധിക്കുന്നു.

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

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

ആദ്യത്തെ പ്രശ്നം, നിങ്ങൾ മനസ്സിലാക്കുന്നതുപോലെ, ലളിതമാണ്. ഞങ്ങൾ എടുത്ത് ഡിസിഎസ് ബേസിനൊപ്പം ഇട്ടു, ഞങ്ങൾക്ക് ഒരു പ്രശ്നം ലഭിച്ചു.

രണ്ടാമത്തെ പ്രശ്നം ആദ്യത്തേതിന് സമാനമാണ്. ഡി‌സി‌എസ് സിസ്റ്റത്തിൽ ഞങ്ങൾക്ക് വീണ്ടും ഇന്ററോപ്പറബിളിറ്റി പ്രശ്‌നങ്ങളുണ്ട് എന്നതിന് സമാനമാണ്.

ലോഗുകൾ പരിശോധിച്ചാൽ, നമുക്ക് വീണ്ടും ആശയവിനിമയ പിശക് ഉണ്ടെന്ന് കാണാം. എനിക്ക് ഡി‌സി‌എസുമായി സംവദിക്കാൻ കഴിയില്ല, അതിനാൽ നിലവിലെ മാസ്റ്റർ റെപ്ലിക്ക മോഡിലേക്ക് പോകുന്നു എന്ന് പത്രോണി പറയുന്നു.

പഴയ യജമാനൻ ഒരു പകർപ്പായി മാറുന്നു, ഇവിടെ പത്രോണി അത് പോലെ പ്രവർത്തിക്കുന്നു. ഇടപാട് ലോഗ് റിവൈൻഡ് ചെയ്യുന്നതിന് pg_rewind പ്രവർത്തിപ്പിക്കുകയും തുടർന്ന് പുതിയ മാസ്റ്ററുമായി ബന്ധപ്പെടാൻ പുതിയ മാസ്റ്ററുമായി ബന്ധിപ്പിക്കുകയും ചെയ്യുന്നു. ഇവിടെ പത്രോണി താൻ ചെയ്യേണ്ടതുപോലെ പ്രവർത്തിക്കുന്നു.

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

ഒരു സാധാരണ സാഹചര്യത്തിൽ, ലോഗുകൾ ഇതുപോലെ കാണപ്പെടുന്നു. ലോക്കിന്റെ ഉടമയെ പരിശോധിച്ചു. ഉദാഹരണത്തിന്, ഉടമ മാറിയെങ്കിൽ, പത്രോണി പ്രതികരിക്കേണ്ട ചില സംഭവങ്ങൾ സംഭവിക്കാം. എന്നാൽ ഈ സാഹചര്യത്തിൽ ഞങ്ങൾ സുഖമായിരിക്കുന്നു. പിശകുകൾ ആരംഭിച്ച സ്ഥലം ഞങ്ങൾ തിരയുകയാണ്.

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

ഫയൽ ചെയ്യുന്നയാളുടെ സമയവും കോൺസൽ ലോഗുകളിലെ സമയവും താരതമ്യം ചെയ്യുമ്പോൾ, കോൺസൽ ക്ലസ്റ്ററിലെ ഞങ്ങളുടെ അയൽക്കാർ കോൺസൽ ക്ലസ്റ്ററിലെ മറ്റ് അംഗങ്ങളുടെ അസ്തിത്വത്തെ സംശയിക്കാൻ തുടങ്ങിയതായി ഞങ്ങൾ കാണുന്നു.

കൂടാതെ മറ്റ് കോൺസൽ ഏജന്റുമാരുടെ ലോഗുകൾ കൂടി പരിശോധിച്ചാൽ, അവിടെ ഒരു തരത്തിലുള്ള നെറ്റ്‌വർക്ക് തകർച്ചയും നടക്കുന്നതായി കാണാം. കോൺസൽ ക്ലസ്റ്ററിലെ എല്ലാ അംഗങ്ങളും പരസ്പരം സംശയിക്കുന്നു. ഇത് ഫയലർക്കുള്ള പ്രേരണയായി.

ഈ പിശകുകൾക്ക് മുമ്പ് എന്താണ് സംഭവിച്ചതെന്ന് നിങ്ങൾ നോക്കുകയാണെങ്കിൽ, എല്ലാത്തരം പിശകുകളും ഉണ്ടെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും, ഉദാഹരണത്തിന്, ഡെഡ്‌ലൈൻ, RPC വീണു, അതായത്, കോൺസൽ ക്ലസ്റ്റർ അംഗങ്ങൾ പരസ്പരം ഇടപഴകുന്നതിൽ എന്തെങ്കിലും പ്രശ്‌നമുണ്ട്. .

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

ഓപ്ഷനുകൾ ഉണ്ട്:

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

പത്രോണി ഉപയോഗിക്കുന്ന പലർക്കും ഈ കമാൻഡ് പരിചിതമാണെന്ന് ഞാൻ കരുതുന്നു.

ഈ കമാൻഡ് ക്ലസ്റ്ററിന്റെ നിലവിലെ അവസ്ഥ കാണിക്കുന്നു. ഒറ്റനോട്ടത്തിൽ, ഈ ചിത്രം സാധാരണമാണെന്ന് തോന്നാം. ഞങ്ങൾക്ക് ഒരു മാസ്റ്ററുണ്ട്, ഞങ്ങൾക്ക് ഒരു പകർപ്പുണ്ട്, പകർപ്പെടുക്കൽ കാലതാമസമില്ല. എന്നാൽ ഈ ക്ലസ്റ്ററിന് രണ്ടല്ല, മൂന്ന് നോഡുകൾ ഉണ്ടായിരിക്കണം എന്ന് അറിയുന്നത് വരെ ഈ ചിത്രം സാധാരണമാണ്.

അതനുസരിച്ച്, ഒരു ഓട്ടോഫയൽ ഉണ്ടായിരുന്നു. ഈ ഓട്ടോഫയലിന് ശേഷം ഞങ്ങളുടെ പകർപ്പ് അപ്രത്യക്ഷമായി. എന്തുകൊണ്ടാണ് അവൾ അപ്രത്യക്ഷയായത് എന്ന് കണ്ടെത്തുകയും അവളെ തിരികെ കൊണ്ടുവരികയും പുനഃസ്ഥാപിക്കുകയും വേണം. ഞങ്ങൾ വീണ്ടും ലോഗുകളിലേക്ക് പോയി എന്തുകൊണ്ടാണ് ഞങ്ങൾക്ക് ഒരു ഓട്ടോ-ഫിൽഓവർ ഉണ്ടായതെന്ന് നോക്കുക.

ഈ സാഹചര്യത്തിൽ, രണ്ടാമത്തെ പകർപ്പ് മാസ്റ്ററായി. ഇവിടെ എല്ലാം ശരിയാണ്.

ഒപ്പം വീണതും ക്ലസ്റ്ററിൽ ഇല്ലാത്തതുമായ പകർപ്പ് നോക്കേണ്ടതുണ്ട്. ഞങ്ങൾ Patroni ലോഗുകൾ തുറന്ന് pg_rewind ഘട്ടത്തിൽ ക്ലസ്റ്ററിലേക്ക് കണക്‌റ്റ് ചെയ്യുന്ന പ്രക്രിയയിൽ ഞങ്ങൾക്ക് പ്രശ്‌നമുണ്ടായതായി കാണുന്നു. ക്ലസ്റ്ററിലേക്ക് കണക്റ്റുചെയ്യുന്നതിന്, നിങ്ങൾ ഇടപാട് ലോഗ് റിവൈൻഡ് ചെയ്യുകയും മാസ്റ്ററിൽ നിന്ന് ആവശ്യമായ ഇടപാട് ലോഗ് അഭ്യർത്ഥിക്കുകയും മാസ്റ്ററെ കണ്ടെത്തുന്നതിന് അത് ഉപയോഗിക്കുകയും വേണം.

ഈ സാഹചര്യത്തിൽ, ഞങ്ങൾക്ക് ഒരു ഇടപാട് ലോഗ് ഇല്ല, കൂടാതെ പകർപ്പ് ആരംഭിക്കാൻ കഴിയില്ല. അതനുസരിച്ച്, ഒരു പിശക് ഉപയോഗിച്ച് ഞങ്ങൾ പോസ്റ്റ്ഗ്രെസ് നിർത്തുന്നു. അതിനാൽ ഇത് ക്ലസ്റ്ററിലില്ല.

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

ഈ സംഭവങ്ങൾ നടന്നപ്പോൾ ഞാൻ ടൈംസ്റ്റാമ്പുകൾ താരതമ്യം ചെയ്തു. അവിടെ വ്യത്യാസം അക്ഷരാർത്ഥത്തിൽ 150 മില്ലിസെക്കൻഡാണ്, അതായത്, 369 മില്ലിസെക്കൻഡിൽ പൂർത്തിയാക്കിയ ചെക്ക് പോയിന്റ്, WAL സെഗ്‌മെന്റുകളുടെ പേര് മാറ്റി. അക്ഷരാർത്ഥത്തിൽ 517-ൽ, 150 മില്ലിസെക്കൻഡുകൾക്ക് ശേഷം, പഴയ പകർപ്പിൽ റിവൈൻഡ് ആരംഭിച്ചു. അതായത്, അക്ഷരാർത്ഥത്തിൽ 150 മില്ലിസെക്കൻഡ് ഞങ്ങൾക്ക് മതിയായിരുന്നു, അതിനാൽ പകർപ്പ് കണക്റ്റുചെയ്യാനും സമ്പാദിക്കാനും കഴിയില്ല.

ഓപ്ഷനുകൾ എന്തൊക്കെയാണ്?

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

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

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

ഞങ്ങൾക്ക് ഒരു ഉൽപാദന അടിത്തറയുണ്ട്. ഇതിനോടകം പദ്ധതികൾ പുരോഗമിക്കുന്നുണ്ട്.

ഒരു ഫയലർ ഉണ്ടായിരുന്നു. ഞങ്ങൾ അകത്തേക്ക് പോയി നോക്കി - എല്ലാം ക്രമത്തിലാണ്, പകർപ്പുകൾ സ്ഥലത്തുണ്ട്, റെപ്ലിക്കേഷൻ കാലതാമസമില്ല. ലോഗുകളിലും പിശകുകളൊന്നുമില്ല, എല്ലാം ക്രമത്തിലാണ്.

കുറച്ച് ഡാറ്റ ഉണ്ടായിരിക്കണമെന്ന് ഉൽപ്പന്ന ടീം പറയുന്നു, പക്ഷേ ഞങ്ങൾ അത് ഒരു ഉറവിടത്തിൽ നിന്ന് കാണുന്നു, പക്ഷേ ഞങ്ങൾ അത് ഡാറ്റാബേസിൽ കാണുന്നില്ല. അവർക്ക് എന്താണ് സംഭവിച്ചതെന്ന് നമ്മൾ മനസ്സിലാക്കേണ്ടതുണ്ട്.

pg_rewind അവരെ വിട്ടുപോയെന്ന് വ്യക്തമാണ്. ഞങ്ങൾക്ക് ഇത് പെട്ടെന്ന് മനസ്സിലായി, പക്ഷേ എന്താണ് സംഭവിക്കുന്നതെന്ന് കാണാൻ പോയി.

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

ഞങ്ങളുടെ പഴയ മാസ്റ്റർ റീബൂട്ട് ചെയ്തു. കൂടാതെ പത്രോണി ഓട്ടോറണിൽ രജിസ്റ്റർ ചെയ്തു. പത്രോണി ഉദ്ഘാടനം ചെയ്തു. തുടർന്ന് അദ്ദേഹം പോസ്റ്റ്ഗ്രെസ് ആരംഭിച്ചു. കൂടുതൽ കൃത്യമായി പറഞ്ഞാൽ, പോസ്റ്റ്‌ഗ്രെസ് ആരംഭിക്കുന്നതിന് മുമ്പും അതിനെ ഒരു പകർപ്പാക്കുന്നതിന് മുമ്പും, പത്രോണി pg_rewind പ്രോസസ്സ് ആരംഭിച്ചു. അതനുസരിച്ച്, അവൻ ഇടപാട് ലോഗുകളുടെ ഒരു ഭാഗം മായ്‌ക്കുകയും പുതിയവ ഡൗൺലോഡ് ചെയ്യുകയും കണക്‌റ്റ് ചെയ്യുകയും ചെയ്‌തു. ഇവിടെ പത്രോണി സമർത്ഥമായി പ്രവർത്തിച്ചു, അതായത് പ്രതീക്ഷിച്ചതുപോലെ. ക്ലസ്റ്റർ പുനഃസ്ഥാപിച്ചു. ഞങ്ങൾക്ക് 3 നോഡുകൾ ഉണ്ടായിരുന്നു, ഫയലറിന് ശേഷം 3 നോഡുകൾ - എല്ലാം രസകരമാണ്.

ഞങ്ങൾക്ക് കുറച്ച് ഡാറ്റ നഷ്ടപ്പെട്ടു. കൂടാതെ നമുക്ക് എത്രമാത്രം നഷ്ടമായെന്ന് മനസ്സിലാക്കണം. ഞങ്ങൾ റിവൈൻഡ് ചെയ്ത നിമിഷത്തിനായി തിരയുകയാണ്. അത്തരം ജേണൽ എൻട്രികളിൽ നമുക്ക് അത് കണ്ടെത്താനാകും. റിവൈൻഡ് തുടങ്ങി, അവിടെ എന്തെങ്കിലും ചെയ്തു, അവസാനിച്ചു.

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

ഞങ്ങൾ സാധാരണ pg_wal_lsn_diff എടുത്ത് ഈ രണ്ട് മാർക്കുകളും താരതമ്യം ചെയ്യുന്നു. ഈ സാഹചര്യത്തിൽ, നമുക്ക് 17 മെഗാബൈറ്റുകൾ ലഭിക്കും. ഒരുപാട് അല്ലെങ്കിൽ കുറച്ച്, എല്ലാവരും സ്വയം തീരുമാനിക്കുന്നു. കാരണം ഒരാൾക്ക് 17 മെഗാബൈറ്റ് അധികമല്ല, മറ്റൊരാൾക്ക് അത് ധാരാളം, അസ്വീകാര്യമാണ്. ഇവിടെ, ഓരോ വ്യക്തിയും ബിസിനസിന്റെ ആവശ്യങ്ങൾക്കനുസൃതമായി സ്വയം നിർണ്ണയിക്കുന്നു.

എന്നാൽ നമ്മൾ സ്വയം എന്താണ് കണ്ടെത്തിയത്?

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

അതിനുശേഷം മാത്രമേ നമുക്ക് ഈ ഡാറ്റ നിരസിക്കാനാകുമോ അതോ പുനഃസ്ഥാപിക്കാൻ കഴിയുമോ എന്ന് തീരുമാനിക്കേണ്ടത്, ഈ നോഡ് ഞങ്ങളുടെ ക്ലസ്റ്ററിലേക്ക് ഒരു പകർപ്പായി ബന്ധിപ്പിക്കുക.

കൂടാതെ, "maximum_lag_on_failover" പാരാമീറ്റർ ഉണ്ട്. സ്ഥിരസ്ഥിതിയായി, എന്റെ മെമ്മറി എന്നെ സേവിക്കുന്നുവെങ്കിൽ, ഈ പരാമീറ്ററിന് 1 മെഗാബൈറ്റ് മൂല്യമുണ്ട്.

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

എന്നാൽ പത്രോണി ക്ലസ്റ്ററിലെയും ഡിസിഎസിലെയും റെപ്ലിക്കേഷൻ ലാഗ് ഒരു നിശ്ചിത ഇടവേളയിൽ അപ്‌ഡേറ്റ് ചെയ്യുന്നതിൽ ഒരു പ്രശ്‌നമുണ്ട്. 30 സെക്കൻഡ് സ്ഥിരസ്ഥിതി ttl മൂല്യമാണെന്ന് ഞാൻ കരുതുന്നു.

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

ഒപ്പം നഷ്ടത്തിന്റെ സാധ്യത എപ്പോഴും നിലനിൽക്കുന്നു. ഏറ്റവും മോശം സാഹചര്യത്തിൽ, ഒരു ഫോർമുല, ശരാശരി കേസിൽ മറ്റൊരു ഫോർമുല. അതായത്, നമ്മൾ പത്രോണി നടപ്പിലാക്കാൻ ആസൂത്രണം ചെയ്യുകയും നമുക്ക് എത്രത്തോളം ഡാറ്റ നഷ്‌ടപ്പെടുമെന്ന് വിലയിരുത്തുകയും ചെയ്യുമ്പോൾ, ഈ ഫോർമുലകളെ ആശ്രയിക്കുകയും നമുക്ക് എത്ര ഡാറ്റ നഷ്‌ടപ്പെടുമെന്ന് ഏകദേശം സങ്കൽപ്പിക്കുകയും വേണം.

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

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

പോസ്റ്റ്‌ഗ്രേസിൽ തങ്ങളുടെ ഉൽപ്പന്നത്തിന് പ്രശ്‌നങ്ങളുണ്ടെന്ന് എഴുതിയ ഒരു ഉൽപ്പന്ന ടീം ഇവിടെയുണ്ട്. അതേ സമയം, മാസ്റ്റർ തന്നെ ആക്സസ് ചെയ്യാൻ കഴിയില്ല, കാരണം ഇത് SSH വഴി ലഭ്യമല്ല. കൂടാതെ ഓട്ടോഫയലും സംഭവിക്കുന്നില്ല.

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

അതേ സമയം, ഞങ്ങൾക്ക് ഡിസ്കുകളിൽ പ്രശ്‌നങ്ങളുണ്ടെന്ന് ഞങ്ങൾക്ക് മുൻകൂട്ടി അറിയാമായിരുന്നു, അതായത്, എവിടെ കുഴിക്കണം, എന്താണ് തിരയേണ്ടതെന്ന് നിരീക്ഷിക്കുന്നതിൽ നിന്ന് ഞങ്ങൾക്ക് ഇതിനകം അറിയാമായിരുന്നു.

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

ഞങ്ങൾ സിസ്റ്റം dmesg (കേർണൽ ലോഗ്) പരിശോധിച്ചു. ഒരു ഡിസ്കിൽ ഞങ്ങൾക്ക് പ്രശ്‌നങ്ങളുണ്ടെന്ന് ഞങ്ങൾ കണ്ടു. സോഫ്റ്റ്വെയർ റെയ്ഡ് ആയിരുന്നു ഡിസ്ക് സബ്സിസ്റ്റം. ഞങ്ങൾ /proc/mdstat പരിശോധിച്ചപ്പോൾ ഞങ്ങൾക്ക് ഒരു ഡ്രൈവ് നഷ്‌ടമായതായി കണ്ടു. അതായത്, 8 ഡിസ്കുകളുടെ ഒരു റെയ്ഡ് ഉണ്ട്, ഞങ്ങൾക്ക് ഒരെണ്ണം നഷ്‌ടമായി. നിങ്ങൾ സ്ലൈഡ് ശ്രദ്ധാപൂർവ്വം നോക്കുകയാണെങ്കിൽ, ഔട്ട്പുട്ടിൽ നമുക്ക് അവിടെ sde ഇല്ലെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. ഞങ്ങളിൽ, സോപാധികമായി പറഞ്ഞാൽ, ഡിസ്ക് ഡ്രോപ്പ് ഔട്ട് ആയി. ഇത് ഡിസ്ക് പ്രശ്‌നങ്ങൾക്ക് കാരണമായി, കൂടാതെ പോസ്റ്റ്‌ഗ്രെസ് ക്ലസ്റ്ററുമായി പ്രവർത്തിക്കുമ്പോൾ ആപ്ലിക്കേഷനുകളും പ്രശ്‌നങ്ങൾ നേരിട്ടു.

ഈ സാഹചര്യത്തിൽ, പത്രോണി ഞങ്ങളെ ഒരു തരത്തിലും സഹായിക്കില്ല, കാരണം സെർവറിന്റെ അവസ്ഥ, ഡിസ്കിന്റെ അവസ്ഥ നിരീക്ഷിക്കാനുള്ള ചുമതല പത്രോണിക്ക് ഇല്ല. ബാഹ്യ നിരീക്ഷണത്തിലൂടെ അത്തരം സാഹചര്യങ്ങൾ നാം നിരീക്ഷിക്കുകയും വേണം. ബാഹ്യ നിരീക്ഷണത്തിലേക്ക് ഞങ്ങൾ ഡിസ്ക് മോണിറ്ററിംഗ് വേഗത്തിൽ ചേർത്തു.

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

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

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

പിന്നെ എങ്ങനെയാണ് എല്ലാം ആരംഭിച്ചത്? മുമ്പത്തെ പ്രശ്നത്തിലെന്നപോലെ ഡിസ്ക് ബ്രേക്കുകൾ ഉപയോഗിച്ചാണ് ഇത് ആരംഭിച്ചത്. ഞങ്ങൾക്ക് ഒരു സെക്കൻഡ്, രണ്ട് കമ്മിറ്റുകൾ ഉണ്ടായിരുന്നു.

കണക്ഷനുകളിൽ ബ്രേക്കുകൾ ഉണ്ടായിരുന്നു, അതായത്, ക്ലയന്റുകൾ കീറി.

വ്യത്യസ്ത തീവ്രതയുടെ തടസ്സങ്ങൾ ഉണ്ടായിരുന്നു.

കൂടാതെ, അതനുസരിച്ച്, ഡിസ്ക് സബ്സിസ്റ്റം വളരെ പ്രതികരിക്കുന്നില്ല.

എന്നെ സംബന്ധിച്ചിടത്തോളം ഏറ്റവും നിഗൂഢമായ കാര്യം ഉടൻ തന്നെ ഷട്ട്ഡൗൺ അഭ്യർത്ഥനയാണ്. Postgres-ന് മൂന്ന് ഷട്ട്ഡൗൺ മോഡുകൾ ഉണ്ട്:

• എല്ലാ ക്ലയന്റുകളും സ്വന്തമായി വിച്ഛേദിക്കുന്നതിനായി ഞങ്ങൾ കാത്തിരിക്കുമ്പോൾ അത് മനോഹരമാണ്.
• ഞങ്ങൾ ഷട്ട്‌ഡൗണിലേക്ക് പോകുന്നതിനാൽ ക്ലയന്റുകളെ വിച്ഛേദിക്കാൻ ഞങ്ങൾ നിർബന്ധിക്കുമ്പോൾ വേഗതയുണ്ട്.
• ഉടനെയും. ഈ സാഹചര്യത്തിൽ, ഉടനടി ക്ലയന്റുകളോട് ഷട്ട് ഡൗൺ ചെയ്യാൻ പോലും പറയുന്നില്ല, ഇത് മുന്നറിയിപ്പില്ലാതെ ഷട്ട് ഡൗൺ ചെയ്യുന്നു. എല്ലാ ക്ലയന്റുകളിലേക്കും, ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ഇതിനകം ഒരു RST സന്ദേശം അയയ്‌ക്കുന്നു (കണക്ഷൻ തടസ്സപ്പെട്ടുവെന്നും ക്ലയന്റിന് കൂടുതൽ ഒന്നും പിടിക്കാനില്ലെന്നും ഒരു TCP സന്ദേശം).

ആരാണ് ഈ സിഗ്നൽ അയച്ചത്? Postgres പശ്ചാത്തല പ്രക്രിയകൾ പരസ്പരം അത്തരം സിഗ്നലുകൾ അയയ്ക്കുന്നില്ല, അതായത് ഇത് കിൽ-9 ആണ്. അവർ പരസ്പരം അത്തരം കാര്യങ്ങൾ അയയ്‌ക്കുന്നില്ല, അവർ അത്തരം കാര്യങ്ങളോട് മാത്രമേ പ്രതികരിക്കൂ, അതായത് ഇത് പോസ്റ്റ്‌ഗ്രേസിന്റെ അടിയന്തര പുനരാരംഭമാണ്. ആരാണ് അയച്ചത്, എനിക്കറിയില്ല.

ഞാൻ "അവസാന" കമാൻഡ് നോക്കി, ഞങ്ങളോടൊപ്പം ഈ സെർവറിൽ ലോഗിൻ ചെയ്ത ഒരാളെ ഞാൻ കണ്ടു, പക്ഷേ ഒരു ചോദ്യം ചോദിക്കാൻ ഞാൻ വളരെ മടിച്ചു. ഒരുപക്ഷേ അത് കൊല്ലപ്പെടാം -9. ലോഗുകളിൽ ഞാൻ കിൽ -9 കാണും, കാരണം Postgres പറയുന്നു, അത് കിൽ -9 എടുത്തു, പക്ഷേ ഞാൻ അത് ലോഗുകളിൽ കണ്ടില്ല.

കൂടുതൽ നോക്കുമ്പോൾ, പത്രോണി വളരെക്കാലമായി ലോഗിൽ എഴുതിയിട്ടില്ലെന്ന് ഞാൻ കണ്ടു - 54 സെക്കൻഡ്. ഞങ്ങൾ രണ്ട് ടൈംസ്റ്റാമ്പുകൾ താരതമ്യം ചെയ്താൽ, ഏകദേശം 54 സെക്കൻഡ് സന്ദേശങ്ങളൊന്നും ഉണ്ടായിരുന്നില്ല.

ഈ സമയത്ത് ഒരു ഓട്ടോഫയൽ ഉണ്ടായിരുന്നു. പത്രോണി ഇവിടെ വീണ്ടും ഒരു മികച്ച ജോലി ചെയ്തു. ഞങ്ങളുടെ പഴയ യജമാനൻ ലഭ്യമല്ല, അദ്ദേഹത്തിന് എന്തോ സംഭവിച്ചു. ഒരു പുതിയ മാസ്റ്ററുടെ തിരഞ്ഞെടുപ്പ് ആരംഭിച്ചു. ഇവിടെ എല്ലാം നന്നായി പ്രവർത്തിച്ചു. ഞങ്ങളുടെ pgsql01 പുതിയ നേതാവായി.

മാസ്റ്ററായി മാറിയ ഒരു പകർപ്പ് ഞങ്ങളുടെ പക്കലുണ്ട്. പിന്നെ രണ്ടാമതൊരു പ്രതികരണമുണ്ട്. രണ്ടാമത്തെ പകർപ്പിൽ പ്രശ്നങ്ങളുണ്ടായിരുന്നു. അവൾ വീണ്ടും ക്രമീകരിക്കാൻ ശ്രമിച്ചു. ഞാൻ മനസ്സിലാക്കിയതുപോലെ, അവൾ recovery.conf മാറ്റാനും Postgres പുനരാരംഭിക്കാനും പുതിയ മാസ്റ്ററുമായി ബന്ധിപ്പിക്കാനും ശ്രമിച്ചു. അവൾ ശ്രമിക്കുന്ന ഓരോ 10 സെക്കൻഡിലും അവൾ സന്ദേശങ്ങൾ എഴുതുന്നു, പക്ഷേ അവൾ വിജയിക്കുന്നില്ല.

ഈ ശ്രമങ്ങൾക്കിടയിൽ, ഉടനടി ഷട്ട്ഡൗൺ സിഗ്നൽ പഴയ മാസ്റ്ററിൽ എത്തുന്നു. മാസ്റ്റർ പുനരാരംഭിച്ചു. പഴയ മാസ്റ്റർ റീബൂട്ടിലേക്ക് പോകുന്നതിനാൽ വീണ്ടെടുക്കൽ നിർത്തുന്നു. അതായത്, പകർപ്പിന് അതിലേക്ക് കണക്റ്റുചെയ്യാൻ കഴിയില്ല, കാരണം അത് ഷട്ട്ഡൗൺ മോഡിലാണ്.

ചില ഘട്ടങ്ങളിൽ, അത് പ്രവർത്തിച്ചു, പക്ഷേ ആവർത്തനം ആരംഭിച്ചില്ല.

Recovery.conf-ൽ ഒരു പഴയ മാസ്റ്റർ വിലാസം ഉണ്ടായിരുന്നു എന്നാണ് എന്റെ ഏക അനുമാനം. ഒരു പുതിയ മാസ്റ്റർ പ്രത്യക്ഷപ്പെട്ടപ്പോൾ, രണ്ടാമത്തെ പകർപ്പ് പഴയ മാസ്റ്ററുമായി ബന്ധിപ്പിക്കാൻ ശ്രമിച്ചു.

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

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

പിന്നെ ഇവിടെ ഞാൻ ഒരു തെറ്റ് ചെയ്തു. ഞങ്ങൾ തെറ്റായ മാസ്റ്ററുമായി ബന്ധിപ്പിക്കുന്നു എന്ന എന്റെ അനുമാനം പരിശോധിക്കാൻ എനിക്ക് recovery.conf-ൽ എന്താണ് ഉള്ളതെന്ന് കാണാൻ വന്ന് കാണേണ്ടി വന്നു. എന്നാൽ പിന്നീട് ഞാൻ ഇത് കൈകാര്യം ചെയ്യുകയായിരുന്നു, അത് എനിക്ക് സംഭവിച്ചില്ല, അല്ലെങ്കിൽ പകർപ്പ് പിന്നിലാണെന്നും വീണ്ടും പൂരിപ്പിക്കേണ്ടതുണ്ടെന്നും ഞാൻ കണ്ടു, അതായത്, ഞാൻ എങ്ങനെയെങ്കിലും അശ്രദ്ധമായി പ്രവർത്തിച്ചു. ഇത് എന്റെ സംയുക്തമായിരുന്നു.

30 മിനിറ്റിനുശേഷം, അഡ്മിൻ ഇതിനകം വന്നു, അതായത് ഞാൻ പകർപ്പിൽ പത്രോണി പുനരാരംഭിച്ചു. ഞാൻ ഇതിനകം അത് അവസാനിപ്പിച്ചു, അത് വീണ്ടും നിറയ്ക്കേണ്ടിവരുമെന്ന് ഞാൻ കരുതി. ഞാൻ വിചാരിച്ചു - ഞാൻ പത്രോണി പുനരാരംഭിക്കും, ഒരുപക്ഷേ എന്തെങ്കിലും നല്ലത് സംഭവിച്ചേക്കാം. വീണ്ടെടുക്കൽ ആരംഭിച്ചു. അടിസ്ഥാനം പോലും തുറന്നു, അത് കണക്ഷനുകൾ സ്വീകരിക്കാൻ തയ്യാറായിരുന്നു.

അനുകരണം ആരംഭിച്ചു. എന്നാൽ ഒരു മിനിറ്റിനുശേഷം ഇടപാട് രേഖകൾ തനിക്ക് അനുയോജ്യമല്ലെന്ന ഒരു പിശക് അവൾ വീണു.

വീണ്ടും പുനരാരംഭിക്കാമെന്ന് ഞാൻ കരുതി. ഞാൻ വീണ്ടും പത്രോണി പുനരാരംഭിച്ചു, ഞാൻ പോസ്റ്റ്‌ഗ്രെസ് പുനരാരംഭിച്ചില്ല, പക്ഷേ അത് മാന്ത്രികമായി ഡാറ്റാബേസ് ആരംഭിക്കുമെന്ന പ്രതീക്ഷയിൽ പത്രോണി പുനരാരംഭിച്ചു.

പകർപ്പെടുക്കൽ വീണ്ടും ആരംഭിച്ചു, എന്നാൽ ഇടപാട് ലോഗിലെ അടയാളങ്ങൾ വ്യത്യസ്തമായിരുന്നു, അവ മുമ്പത്തെ ആരംഭ ശ്രമത്തിന് സമാനമായിരുന്നില്ല. ആവർത്തനം വീണ്ടും നിർത്തി. സന്ദേശം ഇതിനകം അല്പം വ്യത്യസ്തമായിരുന്നു. മാത്രമല്ല അത് എനിക്ക് അത്ര വിവരദായകമായിരുന്നില്ല.

തുടർന്ന് എനിക്ക് ഇത് സംഭവിക്കുന്നു - ഞാൻ പോസ്റ്റ്‌ഗ്രെസ് പുനരാരംഭിച്ചാലോ, ഈ സമയത്ത് ഇടപാട് ലോഗിലെ പോയിന്റ് അൽപ്പം മുന്നോട്ട് നീക്കാൻ ഞാൻ നിലവിലെ മാസ്റ്ററിൽ ഒരു ചെക്ക് പോയിന്റ് ഉണ്ടാക്കുന്നു, അങ്ങനെ മറ്റൊരു നിമിഷം മുതൽ വീണ്ടെടുക്കൽ ആരംഭിക്കും? കൂടാതെ, ഞങ്ങൾക്ക് ഇപ്പോഴും WAL-ന്റെ സ്റ്റോക്കുകൾ ഉണ്ടായിരുന്നു.

ഞാൻ പത്രോണി പുനരാരംഭിച്ചു, മാസ്റ്ററിൽ ഒന്നുരണ്ട് ചെക്ക്‌പോസ്റ്റുകൾ നടത്തി, റെപ്ലിക്ക തുറന്നപ്പോൾ അതിൽ ഒന്നുരണ്ട് റീസ്റ്റാർട്ട് പോയിന്റുകൾ. അത് സഹായിച്ചു. എന്തുകൊണ്ടാണ് ഇത് സഹായിച്ചതെന്നും അത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും ഞാൻ വളരെക്കാലം ചിന്തിച്ചു. ഒപ്പം പകർപ്പും ആരംഭിച്ചു. കൂടാതെ പകർപ്പ് ഇനി കീറിയില്ല.

എന്നെ സംബന്ധിച്ചിടത്തോളം അത്തരമൊരു പ്രശ്നം കൂടുതൽ നിഗൂഢമായ ഒന്നാണ്, അതിൽ യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിച്ചതെന്ന് ഞാൻ ഇപ്പോഴും ആശയക്കുഴപ്പത്തിലാക്കുന്നു.

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

ഫയലറിന് ശേഷം, ക്ലസ്റ്ററിനൊപ്പം എല്ലാം ക്രമത്തിലാണോയെന്ന് നിങ്ങൾ എല്ലായ്പ്പോഴും പരിശോധിക്കേണ്ടതുണ്ട്, അതായത്, ആവശ്യമായ പകർപ്പുകളുടെ എണ്ണം ഉണ്ട്, റെപ്ലിക്കേഷൻ കാലതാമസമില്ല.

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

നിങ്ങൾ പത്രോണി ഉപയോഗിക്കുമ്പോൾ, നിങ്ങൾക്ക് നിരീക്ഷണം ഉണ്ടായിരിക്കണം. ഒരു ഓട്ടോഫിലിയോവർ എപ്പോൾ സംഭവിച്ചുവെന്ന് നിങ്ങൾ എപ്പോഴും അറിഞ്ഞിരിക്കണം, കാരണം നിങ്ങൾക്ക് ഒരു ഓട്ടോഫിൽഓവർ ഉണ്ടെന്ന് നിങ്ങൾക്കറിയില്ലെങ്കിൽ, നിങ്ങൾക്ക് ക്ലസ്റ്ററിന്മേൽ നിയന്ത്രണമില്ല. അത് മോശമാണ്.

ഓരോ ഫയലിനും ശേഷം, ഞങ്ങൾ എല്ലായ്പ്പോഴും ക്ലസ്റ്റർ നേരിട്ട് പരിശോധിക്കേണ്ടതുണ്ട്. ഡിസിഎസ് സിസ്റ്റത്തിനൊപ്പം, പത്രോണിക്കൊപ്പം, സ്ട്രീമിംഗ് റെപ്ലിക്കേഷനുമായി ബന്ധപ്പെട്ട ലോഗുകളിൽ പിശകുകളൊന്നുമില്ലെന്നും, റെപ്ലിക്കേഷൻ കാലതാമസമില്ലെന്നും ഞങ്ങൾക്ക് എല്ലായ്പ്പോഴും കാലികമായ പകർപ്പുകൾ ഉണ്ടെന്നും ഉറപ്പാക്കേണ്ടതുണ്ട്.

ഓട്ടോമേഷൻ വിജയകരമായി പ്രവർത്തിക്കാൻ കഴിയും, പത്രോണി വളരെ നല്ല ഉപകരണമാണ്. ഇതിന് പ്രവർത്തിക്കാൻ കഴിയും, പക്ഷേ ഇത് ക്ലസ്റ്ററിനെ ആവശ്യമുള്ള അവസ്ഥയിലേക്ക് കൊണ്ടുവരില്ല. അതൊന്നും അറിഞ്ഞില്ലെങ്കിൽ നമ്മൾ കുഴപ്പത്തിലാകും.

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

രോഗനിർണയത്തിന്റെ പ്രശ്നത്തെ ഞാൻ എങ്ങനെ സമീപിക്കും? ഞങ്ങൾ വ്യത്യസ്ത ക്ലയന്റുകളുമായി പ്രവർത്തിക്കുന്നു, ആർക്കും ELK സ്റ്റാക്ക് ഇല്ല, കൂടാതെ 6 കൺസോളുകളും 2 ടാബുകളും തുറന്ന് ഞങ്ങൾ ലോഗുകൾ അടുക്കേണ്ടതുണ്ട്. ഒരു ടാബിൽ, ഓരോ നോഡിനുമുള്ള പത്രോണി ലോഗുകൾ ഇവയാണ്, മറ്റൊരു ടാബിൽ, ഇവ കോൺസൽ ലോഗുകൾ അല്ലെങ്കിൽ ആവശ്യമെങ്കിൽ പോസ്റ്റ്ഗ്രെസ് ആണ്. ഇത് നിർണ്ണയിക്കുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്.

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

അടുത്തതായി, ഫയലറിന് മുമ്പുള്ള ഇവന്റുകൾക്കായുള്ള ലോഗുകൾ ഞാൻ നോക്കുന്നു, അത് ഫയലറിന് മുമ്പുള്ളതാണ്, അതായത് ഫയലർ സംഭവിച്ചതിന്റെ കാരണങ്ങൾ ഞാൻ തിരയുന്നു.

അത്തരം സാഹചര്യങ്ങൾ ഉണ്ടാകാതിരിക്കാൻ എന്താണ് സംഭവിച്ചതെന്നും ഭാവിയിൽ എന്തുചെയ്യാനാകുമെന്നും മനസ്സിലാക്കുന്നതിനുള്ള ഒരു ചിത്രം ഇത് നൽകുന്നു (തത്ഫലമായി, ഫയലർ ഇല്ല).

ഞങ്ങൾ സാധാരണയായി എവിടെയാണ് നോക്കുന്നത്? ഞാൻ നോക്കുന്നു:

• ആദ്യം, പത്രോണി ലോഗുകളിലേക്ക്.
• അടുത്തതായി, പത്രോണി ലോഗുകളിൽ കണ്ടെത്തിയതിനെ ആശ്രയിച്ച് ഞാൻ പോസ്റ്റ്ഗ്രെസ് ലോഗുകൾ അല്ലെങ്കിൽ ഡിസിഎസ് ലോഗുകൾ നോക്കുന്നു.
• സിസ്റ്റം ലോഗുകൾ ചിലപ്പോൾ ഫയലറിന് കാരണമായത് എന്താണെന്ന് മനസ്സിലാക്കുന്നു.

പത്രോണിയെക്കുറിച്ച് എനിക്ക് എന്തു തോന്നുന്നു? എനിക്ക് പത്രോണിയുമായി വളരെ നല്ല ബന്ധമുണ്ട്. എന്റെ അഭിപ്രായത്തിൽ, ഇതാണ് ഇന്നത്തെ ഏറ്റവും മികച്ചത്. എനിക്ക് മറ്റ് പല ഉൽപ്പന്നങ്ങളും അറിയാം. ഇവയാണ് Stolon, Repmgr, Pg_auto_failover, PAF. 4 ഉപകരണങ്ങൾ. ഞാൻ അവയെല്ലാം പരീക്ഷിച്ചു. പത്രോണി എനിക്ക് പ്രിയപ്പെട്ടതാണ്.

അവർ എന്നോട് ചോദിച്ചാൽ: "ഞാൻ പത്രോണിയെ ശുപാർശ ചെയ്യുന്നുണ്ടോ?". ഞാൻ അതെ എന്ന് പറയും, കാരണം എനിക്ക് പത്രോണിയെ ഇഷ്ടമാണ്. ഞാൻ അത് എങ്ങനെ പാചകം ചെയ്യണമെന്ന് പഠിച്ചുവെന്ന് ഞാൻ കരുതുന്നു.

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

ആളുകൾ സ്വയം കാലിൽ വെടിയുതിർക്കുന്നതിനെക്കുറിച്ച് രസകരമായ ചില കഥകളുണ്ട്. വളരെ വിജ്ഞാനപ്രദം. അങ്ങനെ ചെയ്യേണ്ട ആവശ്യമില്ലെന്ന് നിങ്ങൾ വായിച്ച് മനസ്സിലാക്കുന്നു. ഞാൻ സ്വയം ടിക്ക് ചെയ്തു.

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

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

അത്രയേയുള്ളൂ. നിങ്ങൾക്ക് ചോദ്യങ്ങളുണ്ടെങ്കിൽ, ചോദിക്കുക.

ചോദ്യങ്ങൾ

റിപ്പോർട്ടിന് നന്ദി! ഒരു ഫയലറിന് ശേഷം നിങ്ങൾ ഇപ്പോഴും അവിടെ വളരെ ശ്രദ്ധയോടെ നോക്കേണ്ടതുണ്ടെങ്കിൽ, ഞങ്ങൾക്ക് ഒരു ഓട്ടോമാറ്റിക് ഫയലർ ആവശ്യമായി വരുന്നത് എന്തുകൊണ്ട്?

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

ഉദാഹരണത്തിന്, ഞങ്ങൾ രാവിലെ പോയി നോക്കി, അല്ലേ?

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

നന്ദി!

മികച്ച കഥയ്ക്ക് വളരെ നന്ദി! ഞങ്ങൾ ഡിസിഎസ് ക്ലസ്റ്ററിനെ പോസ്റ്റ്ഗ്രെസ് ക്ലസ്റ്ററിൽ നിന്ന് ദൂരെ എവിടെയെങ്കിലും നീക്കുകയാണെങ്കിൽ, ഈ ക്ലസ്റ്ററും ഇടയ്ക്കിടെ സർവീസ് ചെയ്യേണ്ടതുണ്ടോ? ഡി‌സി‌എസ് ക്ലസ്റ്ററിന്റെ ചില ഭാഗങ്ങൾ ഓഫാക്കേണ്ട മികച്ച സമ്പ്രദായങ്ങൾ ഏതൊക്കെയാണ്, അവയുമായി എന്തെങ്കിലും ചെയ്യേണ്ടത് മുതലായവ. ഈ മുഴുവൻ ഘടന എങ്ങനെ നിലനിൽക്കും? പിന്നെ എങ്ങനെയാണ് ഈ കാര്യങ്ങൾ ചെയ്യുന്നത്?

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

അതായത്, ഹോസ്റ്റുകളുമായി എന്തെങ്കിലും ചെയ്യുന്നതിന് മുമ്പ് എനിക്ക് പത്രോണി പ്രവർത്തനരഹിതമാക്കണമെന്നും ഫയലർ പ്രവർത്തനരഹിതമാക്കണമെന്നും എല്ലാം പ്രവർത്തനരഹിതമാക്കണമെന്നും ഞാൻ ശരിയായി മനസ്സിലാക്കിയിട്ടുണ്ടോ?

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

വളരെ നന്ദി!

നിങ്ങളുടെ റിപ്പോർട്ടിന് വളരെ നന്ദി! ഡാറ്റ നഷ്‌ടപ്പെടുന്നതിനെക്കുറിച്ച് ഉൽപ്പന്ന ടീമിന് എന്ത് തോന്നുന്നു?

ഉൽപ്പന്ന ടീമുകൾ കാര്യമാക്കുന്നില്ല, ടീം ലീഡുകൾ ആശങ്കാകുലരാണ്.

എന്തൊക്കെ ഉറപ്പുകളാണ് ഉള്ളത്?

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

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

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

രണ്ടാമത്തെ ചോദ്യത്തെ സംബന്ധിച്ച്, ഞങ്ങൾ Repmgr ഉപയോഗിക്കുകയും ചരിത്രപരമായ കാരണങ്ങളാൽ ചില ക്ലയന്റുകളുമായി ഇപ്പോഴും പ്രവർത്തിക്കുകയും ചെയ്യുന്നു. എന്ത് പറയാൻ കഴിയും? Patroni ഒരു ഓട്ടോഫയലറുമായി വരുന്നു, പ്രവർത്തനക്ഷമമാക്കേണ്ട ഒരു അധിക സവിശേഷതയായി Repmgr ഓട്ടോഫയലറുമായി വരുന്നു. ഓരോ നോഡിലും നമുക്ക് Repmgr ഡെമൺ പ്രവർത്തിപ്പിക്കേണ്ടതുണ്ട്, തുടർന്ന് നമുക്ക് ഓട്ടോഫയലർ കോൺഫിഗർ ചെയ്യാം.

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

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

ഞാൻ അത് ഉറക്കെ പറഞ്ഞില്ല, എന്നാൽ ഒരു കോറം തികയുന്നതിന് DCS ക്ലസ്റ്ററും പരാജയപ്പെടണം, അതായത് നോഡുകളുടെ ഒറ്റസംഖ്യയാണ്. ഡി‌സി‌എസ് ക്ലസ്റ്റർ ലഭ്യമല്ലാതാകുകയോ ഒരു കോറം പാലിക്കാൻ കഴിയാതെ വരികയോ ചെയ്താൽ എന്ത് സംഭവിക്കും, അതായത് ഏതെങ്കിലും തരത്തിലുള്ള നെറ്റ്‌വർക്ക് സ്പ്ലിറ്റ് അല്ലെങ്കിൽ നോഡ് പരാജയം? ഈ സാഹചര്യത്തിൽ, പത്രോണി ക്ലസ്റ്റർ വായന മാത്രം മോഡിലേക്ക് പോകുന്നു. പട്രോണി ക്ലസ്റ്ററിന് ക്ലസ്റ്ററിന്റെ അവസ്ഥയും എന്തുചെയ്യണമെന്നതും നിർണ്ണയിക്കാൻ കഴിയില്ല. ഇതിന് ഡിസിഎസുമായി ബന്ധപ്പെടാനും പുതിയ ക്ലസ്റ്റർ അവസ്ഥ അവിടെ സംഭരിക്കാനും കഴിയില്ല, അതിനാൽ മുഴുവൻ ക്ലസ്റ്ററും റീഡിലേക്ക് മാത്രം പോകുന്നു. ഒന്നുകിൽ ഓപ്പറേറ്ററിൽ നിന്നുള്ള സ്വമേധയാലുള്ള ഇടപെടലിനായി അല്ലെങ്കിൽ DCS വീണ്ടെടുക്കുന്നതിനായി കാത്തിരിക്കുന്നു.

ഏകദേശം പറഞ്ഞാൽ, അടിസ്ഥാനം പോലെ തന്നെ പ്രധാനപ്പെട്ട ഒരു സേവനമായി DCS മാറുന്നു?

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

നന്ദി!

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