പരാജയ ക്ലസ്റ്റർ PostgreSQL + Patroni. നടപ്പാക്കൽ അനുഭവം

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

ഞങ്ങൾക്ക് വളരെ ലോഡുചെയ്ത സേവനമുണ്ട്: ലോകമെമ്പാടുമുള്ള 2,5 ദശലക്ഷം ഉപയോക്താക്കൾ, പ്രതിദിനം 50K+ സജീവ ഉപയോക്താക്കൾ. അയർലണ്ടിലെ ഒരു പ്രദേശത്തെ ആമസോണിലാണ് സെർവറുകൾ സ്ഥിതി ചെയ്യുന്നത്: 100+ വ്യത്യസ്ത സെർവറുകൾ നിരന്തരം പ്രവർത്തിക്കുന്നു, അതിൽ ഏതാണ്ട് 50 ഡാറ്റാബേസുകളാണുള്ളത്.

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

എന്തുകൊണ്ടാണ് ഞങ്ങൾ റെഡിസിൽ നിന്ന് PostgreSQL-ലേക്ക് മാറിയത്

തുടക്കത്തിൽ, സെർവറിന്റെ റാമിൽ എല്ലാ ഡാറ്റയും സംഭരിക്കുന്ന ഒരു കീ-വാല്യൂ സ്റ്റോറായ റെഡിസുമായി ഞങ്ങളുടെ സേവനം പ്രവർത്തിച്ചു.

റെഡിസിന്റെ ഗുണങ്ങൾ:

1. ഉയർന്ന പ്രതികരണ വേഗത, കാരണം എല്ലാം മെമ്മറിയിൽ സൂക്ഷിച്ചിരിക്കുന്നു;
2. ബാക്കപ്പിന്റെയും പകർപ്പിന്റെയും എളുപ്പം.

ഞങ്ങൾക്ക് റെഡിസിന്റെ ദോഷങ്ങൾ:

1. യഥാർത്ഥ ഇടപാടുകളൊന്നുമില്ല. ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ തലത്തിൽ അവരെ അനുകരിക്കാൻ ഞങ്ങൾ ശ്രമിച്ചു. നിർഭാഗ്യവശാൽ, ഇത് എല്ലായ്പ്പോഴും നന്നായി പ്രവർത്തിക്കില്ല, വളരെ സങ്കീർണ്ണമായ കോഡ് എഴുതേണ്ടതുണ്ട്.
2. മെമ്മറിയുടെ അളവ് അനുസരിച്ച് ഡാറ്റയുടെ അളവ് പരിമിതപ്പെടുത്തിയിരിക്കുന്നു. ഡാറ്റയുടെ അളവ് കൂടുന്നതിനനുസരിച്ച്, മെമ്മറി വർദ്ധിക്കും, അവസാനം, തിരഞ്ഞെടുത്ത ഉദാഹരണത്തിന്റെ സവിശേഷതകളിലേക്ക് ഞങ്ങൾ പ്രവർത്തിക്കും, ഇത് AWS-ൽ ഉദാഹരണത്തിന്റെ തരം മാറ്റാൻ ഞങ്ങളുടെ സേവനം നിർത്തേണ്ടതുണ്ട്.
3. കുറഞ്ഞ ലേറ്റൻസി ലെവൽ നിരന്തരം നിലനിർത്തേണ്ടത് ആവശ്യമാണ്, കാരണം. ഞങ്ങൾക്ക് വളരെയധികം അഭ്യർത്ഥനകളുണ്ട്. ഞങ്ങൾക്ക് ഒപ്റ്റിമൽ ഡിലേ ലെവൽ 17-20 എംഎസ് ആണ്. 30-40 എംഎസ് തലത്തിൽ, ഞങ്ങളുടെ അപേക്ഷയിൽ നിന്നുള്ള അഭ്യർത്ഥനകൾക്കും സേവനത്തിന്റെ നിലവാരത്തകർച്ചയ്ക്കും ദീർഘമായ പ്രതികരണങ്ങൾ ലഭിക്കും. നിർഭാഗ്യവശാൽ, 2018 സെപ്റ്റംബറിൽ ഞങ്ങൾക്ക് ഇത് സംഭവിച്ചു, ചില കാരണങ്ങളാൽ റെഡിസിനൊപ്പമുള്ള ഒരു സംഭവത്തിന് പതിവിലും 2 മടങ്ങ് കൂടുതൽ ലേറ്റൻസി ലഭിച്ചപ്പോൾ. പ്രശ്‌നം പരിഹരിക്കാൻ, ഷെഡ്യൂൾ ചെയ്യാത്ത അറ്റകുറ്റപ്പണികൾക്കായി ഞങ്ങൾ ഉച്ചയോടെ സേവനം നിർത്തുകയും പ്രശ്‌നകരമായ റെഡിസ് ഉദാഹരണം മാറ്റിസ്ഥാപിക്കുകയും ചെയ്തു.
4. കോഡിലെ ചെറിയ പിഴവുകൾ ഉണ്ടായാലും ഡാറ്റാ പൊരുത്തക്കേട് ലഭിക്കാൻ എളുപ്പമാണ്, തുടർന്ന് ഈ ഡാറ്റ ശരിയാക്കാൻ കോഡ് എഴുതാൻ ധാരാളം സമയം ചെലവഴിക്കുന്നു.

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

ഞങ്ങൾ ഇതിനകം 1,5 വർഷമായി ഒരു പുതിയ ഡാറ്റാബേസിലേക്ക് നീങ്ങുന്നു, കൂടാതെ ഡാറ്റയുടെ ഒരു ചെറിയ ഭാഗം മാത്രമേ നീക്കിയിട്ടുള്ളൂ, അതിനാൽ ഇപ്പോൾ ഞങ്ങൾ Redis, PostgreSQL എന്നിവയുമായി ഒരേസമയം പ്രവർത്തിക്കുന്നു. ഡാറ്റാബേസുകൾക്കിടയിൽ ഡാറ്റ ചലിക്കുന്നതിന്റെയും സ്വിച്ചുചെയ്യുന്നതിന്റെയും ഘട്ടങ്ങളെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾ എഴുതിയിരിക്കുന്നു എന്റെ സഹപ്രവർത്തകന്റെ ലേഖനം.

ഞങ്ങൾ ആദ്യം നീങ്ങാൻ തുടങ്ങിയപ്പോൾ, ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ ഡാറ്റാബേസുമായി നേരിട്ട് പ്രവർത്തിക്കുകയും മാസ്റ്റർ Redis, PostgreSQL എന്നിവ ആക്സസ് ചെയ്യുകയും ചെയ്തു. PostgreSQL ക്ലസ്റ്ററിൽ ഒരു മാസ്റ്ററും അസിൻക്രണസ് റെപ്ലിക്കേഷനോടുകൂടിയ ഒരു പകർപ്പും അടങ്ങിയിരിക്കുന്നു. ഡാറ്റാബേസ് സ്കീം ഇങ്ങനെയായിരുന്നു:

PgBouncer നടപ്പിലാക്കുന്നു

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

കണക്ഷൻ മാനേജർക്കായി ഞങ്ങൾക്ക് രണ്ട് ഓപ്ഷനുകൾ ഉണ്ടായിരുന്നു: Pgpool, PgBouncer. എന്നാൽ ആദ്യത്തേത് ഡാറ്റാബേസുമായി പ്രവർത്തിക്കുന്ന ട്രാൻസാഷണൽ മോഡിനെ പിന്തുണയ്ക്കുന്നില്ല, അതിനാൽ ഞങ്ങൾ PgBouncer തിരഞ്ഞെടുത്തു.

ഞങ്ങൾ ഇനിപ്പറയുന്ന വർക്ക് സ്കീം സജ്ജീകരിച്ചു: ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ ഒരു PgBouncer ആക്സസ് ചെയ്യുന്നു, അതിന് പിന്നിൽ PostgreSQL മാസ്റ്ററുകളുണ്ട്, കൂടാതെ ഓരോ മാസ്റ്ററിന് പിന്നിലും അസമന്വിത പകർപ്പുള്ള ഒരു പകർപ്പുണ്ട്.


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

PgBouncer പരാജയം

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

അതിനുശേഷം, PgBouncer, PostgreSQL ക്ലസ്റ്ററുകളുടെ തെറ്റ് സഹിഷ്ണുതയെക്കുറിച്ച് ഞങ്ങൾ ഗൗരവമായി ചിന്തിച്ചു, കാരണം ഞങ്ങളുടെ AWS അക്കൗണ്ടിലെ ഏത് സംഭവത്തിലും സമാനമായ സാഹചര്യം സംഭവിക്കാം.

ഞങ്ങൾ PgBouncer fault tolerance സ്‌കീം ഇനിപ്പറയുന്ന രീതിയിൽ നിർമ്മിച്ചു: എല്ലാ ആപ്ലിക്കേഷൻ സെർവറുകളും നെറ്റ്‌വർക്ക് ലോഡ് ബാലൻസർ ആക്‌സസ് ചെയ്യുന്നു, അതിന് പിന്നിൽ രണ്ട് PgBouncers ഉണ്ട്. ഓരോ PgBouncer ഓരോ ഷാർഡിന്റെയും ഒരേ PostgreSQL മാസ്റ്ററെ നോക്കുന്നു. ഒരു AWS ഇൻസ്റ്റൻസ് ക്രാഷ് വീണ്ടും സംഭവിക്കുകയാണെങ്കിൽ, എല്ലാ ട്രാഫിക്കും മറ്റൊരു PgBouncer വഴി റീഡയറക്‌ട് ചെയ്യപ്പെടും. AWS ആണ് നെറ്റ്‌വർക്ക് ലോഡ് ബാലൻസർ പരാജയം നൽകുന്നത്.

ഈ സ്കീം പുതിയ PgBouncer സെർവറുകൾ ചേർക്കുന്നത് എളുപ്പമാക്കുന്നു.

ഒരു PostgreSQL പരാജയ ക്ലസ്റ്റർ സൃഷ്ടിക്കുക

ഈ പ്രശ്നം പരിഹരിക്കുമ്പോൾ, ഞങ്ങൾ വ്യത്യസ്ത ഓപ്ഷനുകൾ പരിഗണിച്ചു: സ്വയം എഴുതിയ പരാജയം, repmgr, AWS RDS, Patroni.

സ്വയം എഴുതിയ സ്ക്രിപ്റ്റുകൾ

അവർക്ക് മാസ്റ്ററുടെ ജോലി നിരീക്ഷിക്കാനും അത് പരാജയപ്പെടുകയാണെങ്കിൽ, മാസ്റ്ററിലേക്ക് പകർപ്പ് പ്രൊമോട്ട് ചെയ്യാനും PgBouncer കോൺഫിഗറേഷൻ അപ്‌ഡേറ്റ് ചെയ്യാനും കഴിയും.

ഈ സമീപനത്തിന്റെ പ്രയോജനങ്ങൾ പരമാവധി ലാളിത്യമാണ്, കാരണം നിങ്ങൾ സ്വയം സ്ക്രിപ്റ്റുകൾ എഴുതുകയും അവ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കൃത്യമായി മനസ്സിലാക്കുകയും ചെയ്യുന്നു.

പരിഗണന:

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

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

Repmgr

PostgreSQL ക്ലസ്റ്ററുകൾക്കുള്ള റെപ്ലിക്കേഷൻ മാനേജർ, ഒരു PostgreSQL ക്ലസ്റ്ററിന്റെ പ്രവർത്തനം നിയന്ത്രിക്കാനാകും. അതേ സമയം, ഇതിന് ബോക്സിന് പുറത്ത് ഒരു യാന്ത്രിക പരാജയം ഇല്ല, അതിനാൽ ജോലിക്കായി നിങ്ങൾ പൂർത്തിയാക്കിയ പരിഹാരത്തിന് മുകളിൽ നിങ്ങളുടെ സ്വന്തം "റാപ്പർ" എഴുതേണ്ടതുണ്ട്. അതിനാൽ എല്ലാം സ്വയം എഴുതിയ സ്ക്രിപ്റ്റുകളേക്കാൾ സങ്കീർണ്ണമായേക്കാം, അതിനാൽ ഞങ്ങൾ Repmgr പോലും പരീക്ഷിച്ചില്ല.

AWS RDS

ഞങ്ങൾക്ക് ആവശ്യമുള്ളതെല്ലാം പിന്തുണയ്ക്കുന്നു, ബാക്കപ്പുകൾ എങ്ങനെ നിർമ്മിക്കാമെന്ന് അറിയാം, കണക്ഷനുകളുടെ ഒരു കുളം നിലനിർത്തുന്നു. ഇതിന് സ്വയമേവയുള്ള സ്വിച്ചിംഗ് ഉണ്ട്: മാസ്റ്റർ മരിക്കുമ്പോൾ, പകർപ്പ് പുതിയ മാസ്റ്ററായി മാറുന്നു, കൂടാതെ AWS dns റെക്കോർഡ് പുതിയ മാസ്റ്ററിലേക്ക് മാറ്റുന്നു, അതേസമയം പകർപ്പുകൾ വ്യത്യസ്ത AZ-കളിൽ സ്ഥാപിക്കാൻ കഴിയും.

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

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

കൂടാതെ, AWS RDS സാധാരണ വിലയേക്കാൾ ഇരട്ടി ചെലവേറിയതാണ്, ഇത് ഈ പരിഹാരം ഉപേക്ഷിക്കുന്നതിനുള്ള പ്രധാന കാരണമാണ്.

പത്രോണി

നല്ല ഡോക്യുമെന്റേഷൻ, ഓട്ടോമാറ്റിക് പരാജയം, ഗിത്തബിലെ സോഴ്സ് കോഡ് എന്നിവ ഉപയോഗിച്ച് PostgreSQL കൈകാര്യം ചെയ്യുന്നതിനുള്ള ഒരു പൈത്തൺ ടെംപ്ലേറ്റാണിത്.

പത്രോണിയുടെ ഗുണങ്ങൾ:

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

പരിഗണന:

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

തൽഫലമായി, ഒരു പരാജയ ക്ലസ്റ്റർ സൃഷ്ടിക്കാൻ ഞങ്ങൾ പത്രോണി തിരഞ്ഞെടുത്തു.

പത്രോണി നടപ്പാക്കൽ പ്രക്രിയ

പത്രോണിക്ക് മുമ്പ്, ഞങ്ങൾക്ക് ഒരു മാസ്റ്ററിന്റെ കോൺഫിഗറേഷനിൽ 12 PostgreSQL ഷാർഡുകളും അസിൻക്രണസ് റെപ്ലിക്കേഷനോടുകൂടിയ ഒരു പകർപ്പും ഉണ്ടായിരുന്നു. ആപ്ലിക്കേഷൻ സെർവറുകൾ നെറ്റ്‌വർക്ക് ലോഡ് ബാലൻസറിലൂടെ ഡാറ്റാബേസുകൾ ആക്‌സസ് ചെയ്‌തു, അതിന് പിന്നിൽ PgBouncer ഉള്ള രണ്ട് സന്ദർഭങ്ങളും അവയ്ക്ക് പിന്നിൽ എല്ലാ PostgreSQL സെർവറുകളും ഉണ്ടായിരുന്നു.


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

കോൺസലിനൊപ്പം പത്രോണി എങ്ങനെ പ്രവർത്തിക്കുന്നു

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

പത്രോണിയെ കോൺസലുമായി ബന്ധിപ്പിക്കുന്നതിന്, കോൺസുലുമായി ഞങ്ങൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെ ആശ്രയിച്ച്, ഓപ്ഷണലായി കണക്ഷൻ സ്കീമിനെ ആശ്രയിച്ച്, http അല്ലെങ്കിൽ https ഫോർമാറ്റിൽ നിങ്ങൾ ഒരു ഹോസ്റ്റ് വ്യക്തമാക്കേണ്ടതുണ്ടെന്ന് പറയുന്ന ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ പഠിച്ചാൽ മതിയാകും:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

ഇത് ലളിതമായി തോന്നുന്നു, പക്ഷേ ഇവിടെയാണ് അപകടങ്ങൾ ആരംഭിക്കുന്നത്. കോൺസലിനൊപ്പം, https വഴിയുള്ള ഒരു സുരക്ഷിത കണക്ഷനിലൂടെ ഞങ്ങൾ പ്രവർത്തിക്കുന്നു, ഞങ്ങളുടെ കണക്ഷൻ കോൺഫിഗറേഷൻ ഇതുപോലെ കാണപ്പെടും:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

എന്നാൽ അത് പ്രവർത്തിക്കുന്നില്ല. സ്റ്റാർട്ടപ്പിൽ, പത്രോണിക്ക് കോൺസലുമായി ബന്ധിപ്പിക്കാൻ കഴിയില്ല, കാരണം അത് എന്തായാലും http വഴി പോകാൻ ശ്രമിക്കുന്നു.

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

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

കോൺസൽ-ടെംപ്ലേറ്റ്

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

ഒരു പരിഹാരം തേടി, ഞങ്ങൾ ഒരു ലേഖനം കണ്ടെത്തി (നിർഭാഗ്യവശാൽ ഞാൻ തലക്കെട്ട് ഓർക്കുന്നില്ല) അവിടെ PgBouncer-ഉം Patroni-ഉം ജോടിയാക്കാൻ Сonsul-template വളരെയധികം സഹായിച്ചു എന്ന് എഴുതിയിരുന്നു. കോൺസൽ ടെംപ്ലേറ്റ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് അന്വേഷിക്കാൻ ഇത് ഞങ്ങളെ പ്രേരിപ്പിച്ചു.

കോൺസൽ ടെംപ്ലേറ്റ് കോൺസലിലെ PostgreSQL ക്ലസ്റ്ററിന്റെ കോൺഫിഗറേഷൻ നിരന്തരം നിരീക്ഷിക്കുന്നു. ലീഡർ മാറുമ്പോൾ, അത് PgBouncer കോൺഫിഗറേഷൻ അപ്ഡേറ്റ് ചെയ്യുകയും അത് വീണ്ടും ലോഡുചെയ്യാൻ ഒരു കമാൻഡ് അയയ്ക്കുകയും ചെയ്യുന്നു.

ടെംപ്ലേറ്റിന്റെ ഒരു വലിയ പ്ലസ്, അത് കോഡായി സംഭരിച്ചിരിക്കുന്നു എന്നതാണ്, അതിനാൽ ഒരു പുതിയ ഷാർഡ് ചേർക്കുമ്പോൾ, ഒരു പുതിയ പ്രതിബദ്ധത ഉണ്ടാക്കുകയും ടെംപ്ലേറ്റ് യാന്ത്രികമായി അപ്‌ഡേറ്റ് ചെയ്യുകയും, കോഡ് തത്വമായി ഇൻഫ്രാസ്ട്രക്ചറിനെ പിന്തുണയ്ക്കുകയും ചെയ്താൽ മതി.

പത്രോണിക്കൊപ്പം പുതിയ വാസ്തുവിദ്യ

തൽഫലമായി, ഞങ്ങൾക്ക് ഇനിപ്പറയുന്ന ജോലിയുടെ സ്കീം ലഭിച്ചു:


എല്ലാ ആപ്ലിക്കേഷൻ സെർവറുകളും ബാലൻസറിലേക്ക് പ്രവേശിക്കുന്നു → അതിന് പിന്നിൽ PgBouncer ന്റെ രണ്ട് സന്ദർഭങ്ങളുണ്ട് → ഓരോ സന്ദർഭത്തിലും, കോൺസൽ ടെംപ്ലേറ്റ് സമാരംഭിക്കുന്നു, അത് ഓരോ Patroni ക്ലസ്റ്ററിന്റെയും നില നിരീക്ഷിക്കുകയും PgBouncer കോൺഫിഗറിൻറെ പ്രസക്തി നിരീക്ഷിക്കുകയും ചെയ്യുന്നു, അത് നിലവിലെ നേതാവിന് അഭ്യർത്ഥനകൾ അയയ്ക്കുന്നു. ഓരോ ക്ലസ്റ്ററിന്റെയും.

മാനുവൽ ടെസ്റ്റിംഗ്

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

10-20 സെക്കൻഡിനുള്ളിൽ സ്റ്റിക്കർ തിരികെ വന്നു, തുടർന്ന് വീണ്ടും സാധാരണഗതിയിൽ നീങ്ങാൻ തുടങ്ങി. ഇതിനർത്ഥം പത്രോണി ക്ലസ്റ്റർ ശരിയായി പ്രവർത്തിച്ചുവെന്നാണ്: അത് നേതാവിനെ മാറ്റി, കോൺസുലിലേക്ക് വിവരങ്ങൾ അയച്ചു, കൂടാതെ കോൺസുൽ ടെംപ്ലേറ്റ് ഉടൻ തന്നെ ഈ വിവരങ്ങൾ എടുത്ത് PgBouncer കോൺഫിഗറേഷൻ മാറ്റി വീണ്ടും ലോഡുചെയ്യാൻ കമാൻഡ് അയച്ചു.

ഉയർന്ന ഭാരത്തിൽ എങ്ങനെ അതിജീവിക്കാനും പ്രവർത്തനരഹിതമായ സമയം കുറയ്ക്കാനും എങ്ങനെ കഴിയും?

എല്ലാം തികച്ചും പ്രവർത്തിക്കുന്നു! എന്നാൽ പുതിയ ചോദ്യങ്ങളുണ്ട്: ഉയർന്ന ലോഡിൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കും? ഉൽപ്പാദനത്തിൽ എല്ലാം വേഗത്തിലും സുരക്ഷിതമായും എങ്ങനെ ഉരുട്ടാം?

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

രണ്ട് ജോലികളും അതിമോഹമാണെന്ന് തോന്നുന്നു, പക്ഷേ ഞങ്ങൾക്ക് PostgreSQL 9.6 ഉണ്ട്. നമുക്ക് ഉടൻ തന്നെ 11.2 ലേക്ക് അപ്‌ഗ്രേഡ് ചെയ്യാൻ കഴിയുമോ?

ഞങ്ങൾ ഇത് 2 ഘട്ടങ്ങളിൽ ചെയ്യാൻ തീരുമാനിക്കുന്നു: ആദ്യം 11.2 ലേക്ക് അപ്ഗ്രേഡ് ചെയ്യുക, തുടർന്ന് Patroni സമാരംഭിക്കുക.

PostgreSQL അപ്ഡേറ്റ്

PostgreSQL പതിപ്പ് വേഗത്തിൽ അപ്ഡേറ്റ് ചെയ്യുന്നതിന്, ഓപ്ഷൻ ഉപയോഗിക്കുക -k, അതിൽ ഹാർഡ് ലിങ്കുകൾ ഡിസ്കിൽ സൃഷ്ടിക്കപ്പെടുന്നു, നിങ്ങളുടെ ഡാറ്റ പകർത്തേണ്ട ആവശ്യമില്ല. 300-400 ജിബിയുടെ അടിസ്ഥാനത്തിൽ, അപ്‌ഡേറ്റ് 1 സെക്കൻഡ് എടുക്കും.

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

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

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

പത്രോണി വിക്ഷേപിക്കുക

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

ഞങ്ങൾ ഇതിനകം നിലവിലുള്ള PostgreSQL ക്ലസ്റ്ററിൽ Patroni ഇൻസ്റ്റാൾ ചെയ്ത് പ്രവർത്തിപ്പിക്കാൻ തുടങ്ങിയപ്പോൾ, ഞങ്ങൾ ഒരു പുതിയ പ്രശ്നത്തിൽ അകപ്പെട്ടു: രണ്ട് സെർവറുകളും ഒരു നേതാവായി ആരംഭിച്ചു. ക്ലസ്റ്ററിന്റെ ആദ്യകാല അവസ്ഥയെക്കുറിച്ച് പത്രോണിക്ക് ഒന്നും അറിയില്ല, രണ്ട് സെർവറുകളും ഒരേ പേരിൽ രണ്ട് വ്യത്യസ്ത ക്ലസ്റ്ററുകളായി ആരംഭിക്കാൻ ശ്രമിക്കുന്നു. ഈ പ്രശ്നം പരിഹരിക്കാൻ, സ്ലേവിലെ ഡാറ്റയുള്ള ഡയറക്ടറി നിങ്ങൾ ഇല്ലാതാക്കേണ്ടതുണ്ട്:

rm -rf /var/lib/postgresql/

ഇത് അടിമയിൽ മാത്രം ചെയ്യേണ്ടതുണ്ട്!

വൃത്തിയുള്ള ഒരു പകർപ്പ് ബന്ധിപ്പിക്കുമ്പോൾ, പത്രോണി ഒരു ബേസ്ബാക്കപ്പ് ലീഡർ ഉണ്ടാക്കുകയും അത് പകർപ്പിലേക്ക് പുനഃസ്ഥാപിക്കുകയും ചെയ്യുന്നു, തുടർന്ന് വാൾ ലോഗുകൾ അനുസരിച്ച് നിലവിലെ അവസ്ഥയെ പിടിക്കുന്നു.

ഞങ്ങൾ നേരിട്ട മറ്റൊരു ബുദ്ധിമുട്ട്, എല്ലാ PostgreSQL ക്ലസ്റ്ററുകളും സ്ഥിരസ്ഥിതിയായി പ്രധാനമായി നാമകരണം ചെയ്തിരിക്കുന്നു എന്നതാണ്. ഓരോ ക്ലസ്റ്ററും മറ്റൊന്നിനെക്കുറിച്ച് ഒന്നും അറിയാത്തപ്പോൾ, ഇത് സാധാരണമാണ്. എന്നാൽ നിങ്ങൾക്ക് പത്രോണി ഉപയോഗിക്കണമെങ്കിൽ, എല്ലാ ക്ലസ്റ്ററുകൾക്കും ഒരു തനതായ പേര് ഉണ്ടായിരിക്കണം. PostgreSQL കോൺഫിഗറേഷനിൽ ക്ലസ്റ്റർ നാമം മാറ്റുക എന്നതാണ് പരിഹാരം.

ലോഡ് ടെസ്റ്റ്

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

പത്രോണിയെ നിർമ്മാണത്തിലേക്ക് കൊണ്ടുവരുന്നു

തൽഫലമായി, ഞങ്ങൾ ഇനിപ്പറയുന്ന പ്ലാൻ കൊണ്ടുവന്നു:

• PgBouncer സെർവറുകളിലേക്ക് കോൺസൽ-ടെംപ്ലേറ്റ് വിന്യസിച്ച് സമാരംഭിക്കുക;
• PostgreSQL പതിപ്പ് 11.2 ലേക്കുള്ള അപ്ഡേറ്റുകൾ;
• ക്ലസ്റ്ററിന്റെ പേര് മാറ്റുക;
• പത്രോണി ക്ലസ്റ്റർ ആരംഭിക്കുന്നു.

അതേ സമയം, ഞങ്ങളുടെ സ്കീം ഏതാണ്ട് എപ്പോൾ വേണമെങ്കിലും ആദ്യ പോയിന്റ് ഉണ്ടാക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നു, ഞങ്ങൾക്ക് ഓരോ PgBouncer ജോലിയിൽ നിന്ന് നീക്കം ചെയ്യാനും അതിൽ കോൺസൽ ടെംപ്ലേറ്റ് വിന്യസിക്കാനും പ്രവർത്തിപ്പിക്കാനും കഴിയും. അങ്ങനെ ഞങ്ങൾ ചെയ്തു.

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

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


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


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

പത്രോണി ക്ലസ്റ്റർ പുനരാരംഭിക്കുക

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

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

പത്രോണി ക്ലസ്റ്ററിന് അതിന്റെ ക്ലസ്റ്ററിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ വീണ്ടെടുക്കാൻ കഴിയാതെ പുനരാരംഭിച്ചു.

ഒരു പരിഹാരം കണ്ടെത്താൻ, ഗിത്തബിലെ ഒരു പ്രശ്‌നം വഴി ഞങ്ങൾ പത്രോണി രചയിതാക്കളുമായി ബന്ധപ്പെട്ടു. അവർ ഞങ്ങളുടെ കോൺഫിഗറേഷൻ ഫയലുകളിൽ മെച്ചപ്പെടുത്തലുകൾ നിർദ്ദേശിച്ചു:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

ഒരു പരീക്ഷണ പരിതസ്ഥിതിയിൽ പ്രശ്നം ആവർത്തിക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു, ഈ ഓപ്ഷനുകൾ അവിടെ പരീക്ഷിച്ചു, പക്ഷേ നിർഭാഗ്യവശാൽ അവ പ്രവർത്തിച്ചില്ല.

പ്രശ്നം ഇപ്പോഴും പരിഹരിക്കപ്പെടാതെ തുടരുന്നു. ഇനിപ്പറയുന്ന പരിഹാരങ്ങൾ പരീക്ഷിക്കാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു:

• ഓരോ പത്രോണി ക്ലസ്റ്റർ സന്ദർഭത്തിലും കോൺസൽ-ഏജൻറ് ഉപയോഗിക്കുക;
• കോഡിലെ പ്രശ്നം പരിഹരിക്കുക.

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

ഭാഗ്യവശാൽ, ഞങ്ങൾ കൂടുതൽ പിശകുകൾ നേരിട്ടില്ല.

പത്രോണി ഉപയോഗിക്കുന്നതിന്റെ ഫലങ്ങൾ

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


മൂന്ന് മാസത്തിലേറെയായി പത്രോണി നിർമ്മാണത്തിൽ പ്രവർത്തിക്കുന്നു. ഈ സമയത്ത്, അവൻ ഇതിനകം ഞങ്ങളെ സഹായിക്കാൻ കഴിഞ്ഞു. അടുത്തിടെ, ക്ലസ്റ്ററുകളിലൊന്നിന്റെ നേതാവ് AWS-ൽ മരിച്ചു, ഓട്ടോമാറ്റിക് പരാജയം പ്രവർത്തിക്കുകയും ഉപയോക്താക്കൾ പ്രവർത്തിക്കുകയും ചെയ്തു. പത്രോണി അതിന്റെ പ്രധാന ദൗത്യം നിറവേറ്റി.

പത്രോണിയുടെ ഉപയോഗത്തിന്റെ ഒരു ചെറിയ സംഗ്രഹം:

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

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