ഒഡീസി റോഡ്മാപ്പ്: ഒരു കണക്ഷൻ പൂളറിൽ നിന്ന് നമുക്ക് മറ്റെന്താണ് വേണ്ടത്. ആന്ദ്രേ ബോറോഡിൻ (2019)

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

വീഡിയോ:

എല്ലാവർക്കും ഹായ്! എന്റെ പേര് ആൻഡ്രൂ.

Yandex-ൽ, ഞാൻ ഓപ്പൺ സോഴ്സ് ഡാറ്റാബേസുകൾ വികസിപ്പിക്കുന്നു. ഇന്ന് നമുക്ക് കണക്ഷൻ പൂളർ കണക്ഷനുകളെക്കുറിച്ചുള്ള ഒരു വിഷയമുണ്ട്.

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

വിഷയം വളരെ സങ്കീർണ്ണമാണ്, കാരണം പല ഡാറ്റാബേസുകളിലും കണക്ഷൻ പൂളർ അന്തർനിർമ്മിതമാണ്, നിങ്ങൾ അതിനെക്കുറിച്ച് അറിയേണ്ടതില്ല. തീർച്ചയായും, എല്ലായിടത്തും ചില ക്രമീകരണങ്ങൾ ഉണ്ട്, എന്നാൽ Postgres ൽ അത് ആ രീതിയിൽ പ്രവർത്തിക്കില്ല. സമാന്തരമായി (HighLoad++ 2019-ൽ) Postgres-ൽ അന്വേഷണങ്ങൾ സജ്ജീകരിക്കുന്നതിനെക്കുറിച്ച് Nikolai Samokhvalov-ന്റെ ഒരു റിപ്പോർട്ട് ഉണ്ട്. ഞാൻ മനസ്സിലാക്കിയതുപോലെ, ഇതിനകം തന്നെ അവരുടെ അന്വേഷണങ്ങൾ കൃത്യമായി കോൺഫിഗർ ചെയ്‌ത ആളുകൾ ഇവിടെയെത്തി, നെറ്റ്‌വർക്കും റിസോഴ്‌സ് വിനിയോഗവുമായി ബന്ധപ്പെട്ട കൂടുതൽ അപൂർവമായ സിസ്റ്റം പ്രശ്‌നങ്ങൾ നേരിടുന്ന ആളുകളാണ് ഇവർ. ചില സ്ഥലങ്ങളിൽ പ്രശ്‌നങ്ങൾ വ്യക്തമല്ല എന്ന അർത്ഥത്തിൽ ഇത് വളരെ ബുദ്ധിമുട്ടായിരിക്കും.

Yandex-ൽ Postgres ഉണ്ട്. നിരവധി Yandex സേവനങ്ങൾ Yandex.Cloud-ൽ താമസിക്കുന്നു. പോസ്റ്റ്‌ഗ്രേസിൽ സെക്കൻഡിൽ ഒരു ദശലക്ഷം അഭ്യർത്ഥനകളെങ്കിലും സൃഷ്ടിക്കുന്ന നിരവധി പെറ്റാബൈറ്റ് ഡാറ്റ ഞങ്ങളുടെ പക്കലുണ്ട്.

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

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

കണക്ഷൻ പൂളറിന്റെ പ്രധാന ലക്ഷ്യം എന്താണ്?

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

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

സാധ്യമായ 3 സമീപനങ്ങളുണ്ട്:

• അപേക്ഷയുടെ ഭാഗത്ത്.
• ഡാറ്റാബേസ് ഭാഗത്ത്.
• അതിനിടയിൽ, അതായത്, എല്ലാത്തരം കോമ്പിനേഷനുകളും.

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

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

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

നിങ്ങൾക്ക് കൂടുതൽ ലഭ്യത സോണുകളും നിരവധി ഡാറ്റാ സെന്ററുകളും ഉണ്ടെന്ന് നിങ്ങൾ മനസ്സിലാക്കുന്നു. ക്ലയന്റ് സൈഡ് പൂളിംഗ് സമീപനം വലിയ സംഖ്യകളിലേക്ക് നയിക്കുന്നു. വലിയവ ഏകദേശം 10 കണക്ഷനുകളാണ്. ഇത് സാധാരണയായി പ്രവർത്തിക്കാൻ കഴിയുന്ന അരികാണ്.

പ്രോക്സി പൂളറുകളെ കുറിച്ച് നമ്മൾ സംസാരിക്കുകയാണെങ്കിൽ, ഒരുപാട് കാര്യങ്ങൾ ചെയ്യാൻ കഴിയുന്ന രണ്ട് പൂളർമാർ ഉണ്ട്. അവർ കുളക്കാർ മാത്രമല്ല. അവ പൂളറുകളാണ് + കൂടുതൽ രസകരമായ പ്രവർത്തനക്ഷമത. ഈ പിഗ്പൂൾ и ക്രഞ്ചി-പ്രോക്സി.

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

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

ഞങ്ങളുടെ ജോലിഭാരത്തിലും ഇത് സത്യമാണ്. എന്നാൽ കുറച്ച് പ്രശ്നങ്ങൾ ഉണ്ട്.

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

തീർച്ചയായും നിങ്ങൾക്ക് application_name_add_host ഉപയോഗിക്കാം. application_name-ലേക്ക് ഒരു IP വിലാസം ചേർക്കുന്നതിനുള്ള ബൗൺസർ വശത്തുള്ള ഒരു മാർഗമാണിത്. എന്നാൽ application_name ഒരു അധിക കണക്ഷൻ വഴി സജ്ജീകരിച്ചിരിക്കുന്നു.

ഈ ഗ്രാഫിൽ, മഞ്ഞ വര യഥാർത്ഥ അഭ്യർത്ഥനകളും നീല വര ഡാറ്റാബേസിലേക്ക് പറക്കുന്ന അഭ്യർത്ഥനകളുമാണ്. ഈ വ്യത്യാസം കൃത്യമായി ആപ്ലിക്കേഷൻ_നെയിമിന്റെ ഇൻസ്റ്റാളേഷനാണ്, ഇത് കണ്ടെത്തുന്നതിന് മാത്രം ആവശ്യമാണ്, എന്നാൽ ഇത് സൗജന്യമല്ല.

കൂടാതെ, ബൗൺസറിൽ നിങ്ങൾക്ക് ഒരു പൂൾ പരിമിതപ്പെടുത്താൻ കഴിയില്ല, അതായത് ഓരോ ഉപയോക്താവിനും ഓരോ നിർദ്ദിഷ്ട ഡാറ്റാബേസ് ഡാറ്റാബേസ് കണക്ഷനുകളുടെ എണ്ണം.

ഇത് എന്തിലേക്ക് നയിക്കുന്നു? നിങ്ങൾക്ക് C++ ൽ എഴുതിയ ഒരു ലോഡ് ചെയ്‌ത സേവനവും സമീപത്ത് എവിടെയോ ഒരു നോഡിൽ ഒരു ചെറിയ സേവനവും ഉണ്ട്, അത് ഡാറ്റാബേസിൽ ഭയങ്കരമായ ഒന്നും ചെയ്യില്ല, പക്ഷേ അതിന്റെ ഡ്രൈവർ ഭ്രാന്തനാകുന്നു. ഇത് 20 കണക്ഷനുകൾ തുറക്കുന്നു, മറ്റെല്ലാം കാത്തിരിക്കും. നിങ്ങളുടെ കോഡ് പോലും സാധാരണമാണ്.

തീർച്ചയായും, ഈ ക്രമീകരണം ചേർത്ത ബൗൺസറിനായി ഞങ്ങൾ ഒരു ചെറിയ പാച്ച് എഴുതി, അതായത് ക്ലയന്റുകളെ പൂളിലേക്ക് പരിമിതപ്പെടുത്തുന്നു.

Postgres വശത്ത് ഇത് ചെയ്യാൻ സാധിക്കും, അതായത്, കണക്ഷനുകളുടെ എണ്ണം കൊണ്ട് ഡാറ്റാബേസിലെ റോളുകൾ പരിമിതപ്പെടുത്തുക.

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

ഒരു നിശ്ചിത ഘട്ടത്തിൽ, നിങ്ങൾ ആപ്ലിക്കേഷൻ ഗ്രാഫുകൾ നോക്കുകയും ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നില്ലെന്ന് കാണുകയും ചെയ്യുന്നു.

മുകളിൽ നോക്കുക, ബൗൺസർ ഒറ്റ-ത്രെഡ് ആണെന്ന് കാണുക. ഇത് സേവന ജീവിതത്തിൽ ഒരു വഴിത്തിരിവാണ്. ഒന്നര വർഷത്തിനുള്ളിൽ നിങ്ങൾ ഡാറ്റാബേസ് സ്കെയിൽ ചെയ്യാൻ തയ്യാറെടുക്കുകയാണെന്ന് നിങ്ങൾ മനസ്സിലാക്കുന്നു, നിങ്ങൾ പൂളർ സ്കെയിൽ ചെയ്യേണ്ടതുണ്ട്.

ഞങ്ങൾക്ക് കൂടുതൽ PgBouncers ആവശ്യമുണ്ടെന്ന നിഗമനത്തിലെത്തി.

https://lwn.net/Articles/542629/

ബൗൺസർ കുറച്ച് പാച്ച് ചെയ്തിട്ടുണ്ട്.

ടിസിപി പോർട്ട് വീണ്ടും ഉപയോഗിക്കുന്നതിലൂടെ നിരവധി ബൗൺസറുകൾ ഉയർത്താൻ കഴിയുന്ന തരത്തിൽ അവർ അത് ഉണ്ടാക്കി. ഒപ്പം റൌണ്ട് റോബിൻ ഉപയോഗിച്ച് ഓപ്പറേറ്റിംഗ് സിസ്റ്റം അവയ്ക്കിടയിൽ ഇൻകമിംഗ് TCP കണക്ഷനുകൾ സ്വയമേവ കൈമാറുന്നു.

ഇത് ക്ലയന്റുകൾക്ക് സുതാര്യമാണ്, അതായത് നിങ്ങൾക്ക് ഒരു ബൗൺസർ ഉണ്ടെന്ന് തോന്നുന്നു, എന്നാൽ ബൗൺസറുകൾ പ്രവർത്തിപ്പിക്കുന്ന ഇടയിൽ നിങ്ങൾക്ക് നിഷ്‌ക്രിയ കണക്ഷനുകളുടെ വിഘടനം ഉണ്ട്.

ഒരു നിശ്ചിത നിമിഷത്തിൽ ഈ 3 ബൗൺസർമാർ ഓരോരുത്തരും അവരുടെ കാമ്പ് 100% തിന്നുന്നത് നിങ്ങൾ ശ്രദ്ധിച്ചേക്കാം. നിങ്ങൾക്ക് കുറച്ച് ബൗൺസർമാർ ആവശ്യമാണ്. എന്തുകൊണ്ട്?

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

കൂടാതെ, ഇൻകമിംഗ് കണക്ഷനുകളുടെ ഒരു തരംഗം ഉണ്ടാകുമ്പോൾ നടപ്പിലാക്കുന്ന കുറച്ച് ക്രിപ്റ്റോഗ്രാഫിക് ഫംഗ്ഷനുകൾ നിങ്ങൾക്ക് മുകളിൽ കാണാൻ കഴിയും. ഞങ്ങളുടെ പ്രൈമറിക്ക് ലഭ്യത മേഖലകൾക്കിടയിൽ മാറാൻ കഴിയുന്നതിനാൽ, ഇൻകമിംഗ് കണക്ഷനുകളുടെ ഒരു തരംഗം തികച്ചും സാധാരണമായ ഒരു സാഹചര്യമാണ്. അതായത്, ചില കാരണങ്ങളാൽ പഴയ പ്രൈമറി ലഭ്യമല്ല, മുഴുവൻ ലോഡും മറ്റൊരു ഡാറ്റാ സെന്ററിലേക്ക് അയച്ചു. അവരെല്ലാം ഒരേ സമയം TLS-നോട് ഹലോ പറയാൻ വരും.

TLS-ന്റെ ഒരു വലിയ സംഖ്യ ഇനിമുതൽ ബൗൺസറോട് ഹലോ പറയില്ല, പക്ഷേ അവന്റെ തൊണ്ട ഞെരുക്കും. കാലഹരണപ്പെട്ടതിനാൽ, ഇൻകമിംഗ് കണക്ഷനുകളുടെ തരംഗം അൺഡാംഡ് ആയി മാറിയേക്കാം. എക്‌സ്‌പോണൻഷ്യൽ ബാക്ക്‌ഓഫ് ഇല്ലാതെ നിങ്ങൾ ബേസിലേക്ക് വീണ്ടും ശ്രമിക്കുകയാണെങ്കിൽ, അവ ഒരു യോജിച്ച തരംഗത്തിൽ വീണ്ടും വീണ്ടും വരില്ല.

16 കോറുകൾ 16% ലോഡ് ചെയ്യുന്ന 100 PgBouncers ന്റെ ഒരു ഉദാഹരണം ഇതാ.

ഞങ്ങൾ കാസ്കേഡ് PgBouncer-ൽ എത്തി. ബൗൺസർ ഉപയോഗിച്ച് ഞങ്ങളുടെ ലോഡിൽ നേടാനാകുന്ന ഏറ്റവും മികച്ച കോൺഫിഗറേഷനാണിത്. ഞങ്ങളുടെ ബാഹ്യ ബൗൺസറുകൾ TCP ഹാൻഡ്‌ഷേക്കിനായി ഉപയോഗിക്കുന്നു, കൂടാതെ ബാഹ്യ കണക്ഷനുകളെ വളരെയധികം വിഘടിപ്പിക്കാതിരിക്കാൻ ആന്തരിക ബൗൺസറുകൾ യഥാർത്ഥ പൂളിംഗിനായി ഉപയോഗിക്കുന്നു.

ഈ കോൺഫിഗറേഷനിൽ, സുഗമമായ പുനരാരംഭം സാധ്യമാണ്. നിങ്ങൾക്ക് ഈ 18 ബൗൺസറുകളും ഒന്നൊന്നായി പുനരാരംഭിക്കാം. എന്നാൽ അത്തരമൊരു കോൺഫിഗറേഷൻ നിലനിർത്തുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്. Sysadmins, DevOps, കൂടാതെ ഈ സെർവറിന് യഥാർത്ഥത്തിൽ ഉത്തരവാദികളായ ആളുകൾ ഈ ക്രമീകരണത്തിൽ വളരെ സന്തുഷ്ടരായിരിക്കില്ല.

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

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

അല്ലെങ്കിൽ ഒരു ഉദാഹരണം കൂടി. Postgres-ൽ, അനാവശ്യമായ പ്രാമാണീകരണം കൂടാതെ മറ്റൊരു കണക്ഷനിലേക്ക് രഹസ്യം അയച്ചുകൊണ്ട് പുരോഗതിയിലുള്ള ഒരു അഭ്യർത്ഥന നിങ്ങൾക്ക് റദ്ദാക്കാം. എന്നാൽ ചില ക്ലയന്റുകൾ ഒരു TCP റീസെറ്റ് അയയ്‌ക്കുന്നു, അതായത് അവർ നെറ്റ്‌വർക്ക് കണക്ഷൻ തകർക്കുന്നു. ബൗൺസർ എന്ത് ചെയ്യും? അവൻ ഒന്നും ചെയ്യില്ല. ഇത് അഭ്യർത്ഥന നടപ്പിലാക്കുന്നത് തുടരും. ചെറിയ അഭ്യർത്ഥനകളുള്ള ഒരു ഡാറ്റാബേസ് സൃഷ്‌ടിച്ച ധാരാളം കണക്ഷനുകൾ നിങ്ങൾക്ക് ലഭിച്ചിട്ടുണ്ടെങ്കിൽ, ബൗൺസറിൽ നിന്ന് കണക്ഷൻ വിച്ഛേദിക്കുന്നത് മതിയാകില്ല; ഡാറ്റാബേസിൽ പ്രവർത്തിക്കുന്ന അഭ്യർത്ഥനകളും നിങ്ങൾ പൂർത്തിയാക്കേണ്ടതുണ്ട്.

ഇത് പാച്ച് ചെയ്‌തു, ഈ പ്രശ്‌നം ഇതുവരെ ബൗൺസറിന്റെ അപ്‌സ്ട്രീമിൽ ലയിപ്പിച്ചിട്ടില്ല.

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

ഞങ്ങൾ മൾട്ടിത്രെഡിംഗ് പ്രധാന ജോലിയായി സജ്ജമാക്കി. ഇൻകമിംഗ് TLS കണക്ഷനുകളുടെ തരംഗത്തെ നന്നായി കൈകാര്യം ചെയ്യാൻ നമുക്ക് കഴിയണം.

ഇത് ചെയ്യുന്നതിന്, ഒരു നെറ്റ്‌വർക്ക് കണക്ഷന്റെ മെഷീൻ അവസ്ഥകളെ സീക്വൻഷ്യൽ കോഡായി വിവരിക്കുന്നതിന് രൂപകൽപ്പന ചെയ്‌തിരിക്കുന്ന Machinarium എന്നൊരു പ്രത്യേക ലൈബ്രറി ഞങ്ങൾ വികസിപ്പിക്കേണ്ടതുണ്ട്. നിങ്ങൾ libpq സോഴ്‌സ് കോഡ് നോക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് ഒരു റിസൾട്ട് തിരികെ നൽകാനും, "എന്നെ പിന്നീട് വിളിക്കൂ. ഇപ്പോൾ എനിക്ക് ഇപ്പോൾ IO ഉണ്ട്, എന്നാൽ IO ഇല്ലാതാകുമ്പോൾ എനിക്ക് പ്രോസസറിൽ ഒരു ലോഡ് ഉണ്ടാകും. ഇത് ഒരു മൾട്ടി ലെവൽ സ്കീമാണ്. നെറ്റ്‌വർക്ക് ആശയവിനിമയം സാധാരണയായി ഒരു സ്റ്റേറ്റ് മെഷീൻ വിവരിക്കുന്നു. "എനിക്ക് മുമ്പ് N വലുപ്പമുള്ള ഒരു പാക്കറ്റ് ഹെഡർ ലഭിച്ചിരുന്നെങ്കിൽ, ഇപ്പോൾ ഞാൻ N ബൈറ്റുകൾക്കായി കാത്തിരിക്കുകയാണ്," "ഞാൻ ഒരു SYNC പാക്കറ്റ് അയച്ചെങ്കിൽ, ഇപ്പോൾ ഞാൻ ഫല മെറ്റാഡാറ്റയുള്ള ഒരു പാക്കറ്റിനായി കാത്തിരിക്കുകയാണ്" എന്നിങ്ങനെയുള്ള ധാരാളം നിയമങ്ങൾ. മട്ടിനെ ലൈൻ സ്കാനിലേക്ക് പരിവർത്തനം ചെയ്യുന്നതുപോലെ, വളരെ ബുദ്ധിമുട്ടുള്ളതും വിപരീതവുമായ ഒരു കോഡാണ് ഫലം. ഒരു സ്റ്റേറ്റ് മെഷീന് പകരം, പ്രോഗ്രാമർ സാധാരണ നിർബന്ധിത കോഡിന്റെ രൂപത്തിൽ ആശയവിനിമയത്തിന്റെ പ്രധാന പാത വിവരിക്കുന്ന തരത്തിലാണ് ഞങ്ങൾ ഇത് നിർമ്മിച്ചത്. ഈ നിർബന്ധിത കോഡിൽ, നെറ്റ്‌വർക്കിൽ നിന്നുള്ള ഡാറ്റയ്‌ക്കായി കാത്തിരിക്കുന്നതിലൂടെ എക്‌സിക്യൂഷൻ സീക്വൻസ് തടസ്സപ്പെടേണ്ട സ്ഥലങ്ങൾ നിങ്ങൾ തിരുകേണ്ടതുണ്ട്, എക്‌സിക്യൂഷൻ സന്ദർഭം മറ്റൊരു കോറൗട്ടിനിലേക്ക് (ഗ്രീൻ ത്രെഡ്) കൈമാറുക. ഈ സമീപനം ഞങ്ങൾ ഏറ്റവും പ്രതീക്ഷിക്കുന്ന പാത ഒരു വരിയിൽ എഴുതുന്നു, തുടർന്ന് അതിൽ ശാഖകൾ ചേർക്കുന്നു എന്നതിന് സമാനമാണ്.

തൽഫലമായി, ഒരു TCP സ്വീകരിക്കുകയും റൌണ്ട്-റോബിൻ നിരവധി തൊഴിലാളികൾക്ക് TPC കണക്ഷൻ കൈമാറുകയും ചെയ്യുന്ന ഒരു ത്രെഡ് ഞങ്ങളുടെ പക്കലുണ്ട്.

ഈ സാഹചര്യത്തിൽ, ഓരോ ക്ലയന്റ് കണക്ഷനും എപ്പോഴും ഒരു പ്രോസസറിൽ പ്രവർത്തിക്കുന്നു. ഇത് കാഷെ സൗഹൃദമാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

കൂടാതെ, സിസ്റ്റം TCP സ്റ്റാക്ക് ഒഴിവാക്കുന്നതിനായി ഞങ്ങൾ ചെറിയ പാക്കറ്റുകളുടെ ശേഖരണം ഒരു വലിയ പാക്കറ്റിലേക്ക് ചെറുതായി മെച്ചപ്പെടുത്തിയിട്ടുണ്ട്.

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

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

Yandex.Cloud-ന്റെ താൽപ്പര്യങ്ങൾക്കനുസൃതമായി ഞങ്ങൾ പ്രവർത്തിക്കുന്നു. നിങ്ങൾ മാനേജ് ചെയ്ത PostgreSQL ഉപയോഗിക്കുകയും ഒരു കണക്ഷൻ പൂളർ ഇൻസ്റ്റാൾ ചെയ്യുകയും ചെയ്തിട്ടുണ്ടെങ്കിൽ, നിങ്ങൾക്ക് ലോജിക്കൽ റെപ്ലിക്കേഷൻ പുറത്തേക്ക് സൃഷ്ടിക്കാൻ കഴിയും, അതായത്, നിങ്ങൾക്ക് വേണമെങ്കിൽ, ലോജിക്കൽ റെപ്ലിക്കേഷൻ ഉപയോഗിച്ച് ഞങ്ങളെ വിടുക. ബൗൺസർ ലോജിക്കൽ റെപ്ലിക്കേഷൻ ഫ്ലോ പുറത്തേക്ക് അയയ്ക്കില്ല.

ലോജിക്കൽ റെപ്ലിക്കേഷൻ സജ്ജീകരിക്കുന്നതിനുള്ള ഒരു ഉദാഹരണമാണിത്.

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

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

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

നിങ്ങൾക്ക് PgBouncer-മായി 100% അനുയോജ്യത ആവശ്യമുണ്ടെങ്കിൽ ഈ ഫീച്ചർ പ്രവർത്തനരഹിതമാക്കും. ബൗൺസറിനെപ്പോലെ നമുക്ക് പെരുമാറാം, സുരക്ഷിതമായ വശത്തായിരിക്കാൻ.

വികസനം

ഒഡീസി സോഴ്സ് കോഡിനെക്കുറിച്ച് കുറച്ച് വാക്കുകൾ.

https://github.com/yandex/odyssey/pull/66

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

https://github.com/yandex/odyssey/pull/73 - ഇതിനകം മരവിപ്പിച്ചു

കൂടാതെ, PgBouncer-ലെ പുതിയ സവിശേഷതകളിൽ ഒന്ന് SCRAM പ്രാമാണീകരണത്തിനുള്ള പിന്തുണയാണ്, Yandex.Cloud-ൽ പ്രവർത്തിക്കാത്ത ഒരു വ്യക്തി ഞങ്ങളിലേക്ക് കൊണ്ടുവന്നതാണ്. രണ്ടും സങ്കീർണ്ണമായ പ്രവർത്തനവും പ്രധാനപ്പെട്ടതുമാണ്.

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

രണ്ട് പ്രധാന ലൈബ്രറികളെ ആശ്രയിക്കുന്ന ഒഡീസി ഉറവിട അടിത്തറ നിങ്ങൾക്ക് ഉണ്ട്. കിവി ലൈബ്രറി പോസ്റ്റ്‌ഗ്രെസ് സന്ദേശ പ്രോട്ടോക്കോൾ നടപ്പിലാക്കുന്നതാണ്. അതായത്, ഫ്രണ്ട്-എൻഡുകൾക്കും ബാക്ക്-എൻഡുകൾക്കും കൈമാറാൻ കഴിയുന്ന സ്റ്റാൻഡേർഡ് സന്ദേശങ്ങളാണ് Postgres-ന്റെ നേറ്റീവ് പ്രോട്ടോ 3. കിവി ലൈബ്രറിയിൽ അവ നടപ്പിലാക്കുന്നു.

മെഷിനേറിയം ലൈബ്രറി ഒരു ത്രെഡ് നടപ്പിലാക്കൽ ലൈബ്രറിയാണ്. ഈ മെഷിനേറിയത്തിന്റെ ഒരു ചെറിയ ഭാഗം അസംബ്ലി ഭാഷയിൽ എഴുതിയിരിക്കുന്നു. എന്നാൽ പരിഭ്രാന്തരാകരുത്, 15 വരികൾ മാത്രമേയുള്ളൂ.

ഒഡീസി വാസ്തുവിദ്യ. ഒരു പ്രധാന യന്ത്രമുണ്ട്, അതിൽ കൊറൂട്ടിനുകൾ പ്രവർത്തിക്കുന്നു. ഈ മെഷീൻ ഇൻകമിംഗ് ടിസിപി കണക്ഷനുകൾ സ്വീകരിക്കുന്നതും തൊഴിലാളികൾക്കിടയിൽ വിതരണം ചെയ്യുന്നതും നടപ്പിലാക്കുന്നു.

നിരവധി ക്ലയന്റുകൾക്കുള്ള ഒരു ഹാൻഡ്‌ലറിന് ഒരു തൊഴിലാളിക്കുള്ളിൽ പ്രവർത്തിക്കാൻ കഴിയും. പൂളിൽ ഇനി ആവശ്യമില്ലാത്ത കണക്ഷനുകൾ ഇല്ലാതാക്കാൻ പ്രധാന ത്രെഡ് കൺസോളും ക്രോൺ ടാസ്‌ക്കുകളുടെ പ്രോസസ്സിംഗും പ്രവർത്തിപ്പിക്കുന്നു.

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

കൂടാതെ, സ്വന്തമായി ടെസ്റ്റിംഗ് ഉള്ള നിരവധി ഡ്രൈവർമാർ ഉണ്ട്. ഒഡീസി പരീക്ഷിക്കാൻ ഞങ്ങൾ അവരുടെ ടെസ്റ്റുകൾ ഉപയോഗിക്കുന്നു.

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

റേക്ക്

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

കണക്ഷൻ പൂളറിന് ഇൻകമിംഗ് TLS കണക്ഷനുകളും ഔട്ട്‌ഗോയിംഗ് TLS കണക്ഷനുകളും ഉണ്ടെന്ന് ഞങ്ങൾ കണ്ടെത്തി. കണക്ഷനുകൾക്ക് ക്ലയന്റ് സർട്ടിഫിക്കറ്റുകളും സെർവർ സർട്ടിഫിക്കറ്റുകളും ആവശ്യമാണ്.

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

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

ഒരു ലളിതമായ കാരണത്താൽ ഞങ്ങൾ ഇത് നടപ്പിലാക്കിയില്ല. ഞങ്ങൾക്ക് ധാരാളം ത്രെഡുകൾ ഉണ്ട്. എന്തുകൊണ്ടാണ് ഞങ്ങൾക്ക് ഇത് വേണ്ടത്?

ഇത് ആത്യന്തികമായി പ്രശ്നങ്ങൾ സൃഷ്ടിക്കും, നിങ്ങൾക്ക് PAM പ്രാമാണീകരണവും നോൺ-പിഎം പ്രാമാണീകരണവും ഉണ്ടെങ്കിൽ, PAM ആധികാരികതയുടെ ഒരു വലിയ തരംഗത്തിന് PAM ഇതര പ്രാമാണീകരണത്തെ ഗണ്യമായി കാലതാമസം വരുത്താം. ഞങ്ങൾ പരിഹരിക്കാത്ത കാര്യങ്ങളിൽ ഒന്നാണിത്. എന്നാൽ നിങ്ങൾക്ക് ഇത് പരിഹരിക്കണമെങ്കിൽ, നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയും.

എല്ലാ ഇൻകമിംഗ് കണക്ഷനുകളും സ്വീകരിക്കുന്ന ഒരു ത്രെഡ് ഞങ്ങളുടെ പക്കലുണ്ടെന്നതാണ് മറ്റൊരു റേക്ക്. തുടർന്ന് അവരെ വർക്കർ പൂളിലേക്ക് മാറ്റുന്നു, അവിടെ TLS ഹാൻ‌ഡ്‌ഷേക്ക് നടക്കും.

ചുവടെയുള്ള വരി, നിങ്ങൾക്ക് 20 നെറ്റ്‌വർക്ക് കണക്ഷനുകളുടെ യോജിച്ച തരംഗമുണ്ടെങ്കിൽ, അവയെല്ലാം അംഗീകരിക്കപ്പെടും. ക്ലയന്റ് വശത്ത് libpq സമയപരിധി റിപ്പോർട്ട് ചെയ്യാൻ തുടങ്ങും. സ്ഥിരസ്ഥിതിയായി ഇത് 000 സെക്കൻഡ് ആണെന്ന് തോന്നുന്നു.

അവയ്‌ക്കെല്ലാം ഒരേ സമയം ഡാറ്റാബേസിൽ പ്രവേശിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, അവർക്ക് ഡാറ്റാബേസിൽ പ്രവേശിക്കാൻ കഴിയില്ല, കാരണം ഇവയെല്ലാം നോൺ-എക്‌സ്‌പോണൻഷ്യൽ വീണ്ടും ശ്രമിക്കുന്നതിലൂടെ പരിരക്ഷിക്കാനാകും.

ഞങ്ങൾ അംഗീകരിക്കുന്ന TCP കണക്ഷനുകളുടെ എണ്ണം ഞങ്ങൾ ത്രോട്ടിൽ ചെയ്തു എന്ന വസ്തുതയോടെയാണ് ഞങ്ങൾ PgBouncer-ൽ നിന്ന് സ്‌കീം പകർത്തിയത് എന്ന നിഗമനത്തിലെത്തി.

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

റോഡ്മാപ്പിലേക്ക്

ഭാവിയിൽ ഒഡീസിയിൽ എന്താണ് കാണാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നത്? സ്വയം വികസിപ്പിക്കാൻ ഞങ്ങൾ തയ്യാറാണ്, സമൂഹത്തിൽ നിന്ന് എന്താണ് പ്രതീക്ഷിക്കുന്നത്?

2019 ഓഗസ്റ്റ് വരെ.

ഓഗസ്റ്റിൽ ഒഡീസി റോഡ്മാപ്പ് ഇങ്ങനെയായിരുന്നു:

• ഞങ്ങൾക്ക് SCRAM, PAM പ്രാമാണീകരണം ആവശ്യമാണ്.
• വായനാ അഭ്യർത്ഥനകൾ സ്റ്റാൻഡ്‌ബൈയിലേക്ക് കൈമാറാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു.
• എനിക്ക് ഒരു ഓൺലൈൻ പുനരാരംഭം വേണം.
• കൂടാതെ സെർവറിൽ താൽക്കാലികമായി നിർത്താനുള്ള കഴിവും.

ഈ റോഡ്‌മാപ്പിന്റെ പകുതിയും പൂർത്തിയായി, ഞങ്ങളല്ല. കൂടാതെ ഇത് നല്ലതാണ്. അതിനാൽ അവശേഷിക്കുന്നത് ചർച്ച ചെയ്ത് കൂടുതൽ ചേർക്കാം.

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

തത്വത്തിൽ, Postgres-ൽ, 10 മുതൽ ആരംഭിക്കുന്നു, കണക്റ്റുചെയ്യുമ്പോൾ സെഷൻ_അറ്റർസ് വ്യക്തമാക്കുന്നത് സാധ്യമാണ്. കണക്ഷനിലെ എല്ലാ ഡാറ്റാബേസ് ഹോസ്റ്റുകളും നിങ്ങൾക്ക് പട്ടികപ്പെടുത്താനും നിങ്ങൾ ഡാറ്റാബേസിലേക്ക് പോകുന്നത് എന്തുകൊണ്ടാണെന്ന് പറയാനും കഴിയും: എഴുതുക അല്ലെങ്കിൽ വായിക്കുക മാത്രം. കൂടാതെ, സെഷൻ_അറ്റർസിന്റെ ആവശ്യകതകൾ നിറവേറ്റുന്ന, ഡ്രൈവർ തന്നെ താൻ ഏറ്റവും ഇഷ്ടപ്പെടുന്ന ലിസ്റ്റിലെ ആദ്യ ഹോസ്റ്റിനെ തിരഞ്ഞെടുക്കും.

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

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

ഇത് ഓപ്പൺ സോഴ്‌സ് ആയതിനാൽ നടപ്പിലാക്കുന്നതിന് ഒരു സമയപരിധി നൽകുന്നത് ബുദ്ധിമുട്ടാണ്. പക്ഷേ, PgBouncer-ൽ നിന്നുള്ള എന്റെ സഹപ്രവർത്തകരെപ്പോലെ 2,5 വർഷമല്ലെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. ഒഡീസിയിൽ ഞാൻ കാണാൻ ആഗ്രഹിക്കുന്ന സവിശേഷത ഇതാണ്.

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

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

എന്നാൽ ഇവിടെ സംഭാഷണത്തിൽ ഒരു പൊരുത്തക്കേട് ഉയർന്നുവരുന്നു, കാരണം ക്ലയന്റ് ഏത് തരത്തിലുള്ള തയ്യാറാക്കിയ പ്രസ്താവനകളാണ് സൃഷ്ടിച്ചതെന്ന് നിങ്ങൾ മനസിലാക്കണമെന്നും ഈ സെർവർ കണക്ഷൻ സൃഷ്ടിച്ച എല്ലാ ക്ലയന്റുകൾക്കിടയിലും സെർവർ കണക്ഷൻ പങ്കിടണമെന്നും ഒരാൾ പറയുന്നു, അതായത്, അത്തരമൊരു തയ്യാറാക്കിയ പ്രസ്താവന സൃഷ്ടിച്ചത് ആരാണ്.

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

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

ഉറവിടങ്ങൾ പാഴാക്കുകയും നിരീക്ഷണം കൂടുതൽ സ്വീകാര്യമാക്കുകയും ചെയ്യുന്ന മന്ദഗതിയിലുള്ള അന്വേഷണങ്ങൾ ഉണ്ടെന്ന് സൂചിപ്പിക്കുന്ന ശതമാനങ്ങൾക്കുള്ള പിന്തുണ ഞങ്ങൾ നടപ്പിലാക്കേണ്ടതുണ്ട്.

എനിക്ക് വേർഷൻ 1.0 വേണം എന്നതാണ് ഏറ്റവും പ്രധാനപ്പെട്ട കാര്യം (പതിപ്പ് 1.1 ഇതിനകം പുറത്തിറങ്ങി). ഒഡീസി ഇപ്പോൾ 1.0rc പതിപ്പിലാണ്, അതായത് റിലീസ് കാൻഡിഡേറ്റിലാണ് എന്നതാണ് വസ്തുത. മെമ്മറി ലീക്ക് ഒഴികെ, ഞാൻ ലിസ്റ്റുചെയ്‌ത എല്ലാ പ്രശ്‌നങ്ങളും അതേ പതിപ്പ് ഉപയോഗിച്ച് പരിഹരിച്ചു.

പതിപ്പ് 1.0 ഞങ്ങൾക്ക് എന്താണ് അർത്ഥമാക്കുന്നത്? ഞങ്ങൾ ഒഡീസിയെ ഞങ്ങളുടെ താവളങ്ങളിലേക്ക് മാറ്റുകയാണ്. ഇത് ഇതിനകം തന്നെ ഞങ്ങളുടെ ഡാറ്റാബേസുകളിൽ പ്രവർത്തിക്കുന്നുണ്ട്, എന്നാൽ ഇത് സെക്കൻഡിൽ 1 അഭ്യർത്ഥനകളുടെ പോയിന്റിൽ എത്തുമ്പോൾ, ഇത് റിലീസ് പതിപ്പാണെന്നും ഇത് 000 എന്ന് വിളിക്കാവുന്ന ഒരു പതിപ്പാണെന്നും പറയാം.

കമ്മ്യൂണിറ്റിയിലെ നിരവധി ആളുകൾ പതിപ്പ് 1.0-ൽ താൽക്കാലികമായി നിർത്തുന്നതും SCRAM ഉം ഉൾപ്പെടുത്തണമെന്ന് ആവശ്യപ്പെട്ടിട്ടുണ്ട്. എന്നാൽ ഇത് അർത്ഥമാക്കുന്നത് ഞങ്ങൾ അടുത്ത പതിപ്പ് പ്രൊഡക്ഷനിലേക്ക് പുറത്തിറക്കേണ്ടതുണ്ട്, കാരണം SCRAM അല്ലെങ്കിൽ താൽക്കാലികമായി നിർത്തൽ എന്നിവ ഇതുവരെ നശിച്ചിട്ടില്ല. പക്ഷേ, മിക്കവാറും, ഈ പ്രശ്നം വളരെ വേഗത്തിൽ പരിഹരിക്കപ്പെടും.

നിങ്ങളുടെ പിൻവലിക്കൽ അഭ്യർത്ഥനയ്ക്കായി ഞാൻ കാത്തിരിക്കുകയാണ്. ബൗൺസറുമായി ബന്ധപ്പെട്ട് നിങ്ങൾക്ക് എന്തൊക്കെ പ്രശ്‌നങ്ങളാണുള്ളതെന്നും കേൾക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. നമുക്ക് അവ ചർച്ച ചെയ്യാം. നിങ്ങൾക്ക് ആവശ്യമുള്ള ചില പ്രവർത്തനങ്ങൾ ഞങ്ങൾ നടപ്പിലാക്കിയേക്കാം.

ഇത് എന്റെ ഭാഗത്തിന്റെ അവസാനമാണ്, നിങ്ങൾ പറയുന്നത് കേൾക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. നന്ദി!

ചോദ്യങ്ങൾ

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

ഒഡീസിയോ ബൗൺസറോ?

ഒഡീസിയിൽ. ബൗൺസറിൽ അത് എറിയപ്പെടുന്നു.

ഞങ്ങൾ ഒരു സെറ്റ് ചെയ്യും.

എന്റെ യഥാർത്ഥ കണക്ഷൻ മറ്റ് കണക്ഷനുകളിൽ ഹോപ് ചെയ്യുകയാണെങ്കിൽ, അത് കൈമാറ്റം ചെയ്യപ്പെടുമോ?

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

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

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

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

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

അതെ ഇത് സത്യമാണ്. pcache-ൽ നിങ്ങൾക്ക് ആവശ്യമുള്ള ഡാറ്റ ബ്ലോക്കുകൾ ഉണ്ടാകില്ല, യഥാർത്ഥ കാഷെയിൽ നിങ്ങൾക്ക് ആവശ്യമുള്ള പട്ടികകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ ഉണ്ടാകില്ല, പ്ലാനുകളിൽ പാഴ്‌സ് ചെയ്‌ത അന്വേഷണങ്ങൾ ഉണ്ടാകില്ല, ഒന്നും തന്നെ ഉണ്ടാകില്ല.

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

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

അതെ, ഭാരം വർദ്ധിപ്പിക്കുക.

ഇതൊരു നല്ല ആശയമാണ്. എന്നാൽ ആദ്യം നമ്മൾ ഈ ഷട്ട്ഡൗൺ നടപ്പിലാക്കേണ്ടതുണ്ട്. ആദ്യം നമ്മൾ ഓഫാക്കേണ്ടതുണ്ട്, തുടർന്ന് എങ്ങനെ ഓണാക്കാമെന്ന് ഞങ്ങൾ ചിന്തിക്കും. സുഗമമായി പ്രവർത്തനക്ഷമമാക്കുന്നതിനുള്ള മികച്ച സവിശേഷതയാണിത്.

Nginx-ന് ഈ ഓപ്ഷൻ ഉണ്ട് slowly start സെർവറിനായുള്ള ഒരു ക്ലസ്റ്ററിൽ. അവൻ ക്രമേണ ലോഡ് വർദ്ധിപ്പിക്കുന്നു.

അതെ, മികച്ച ആശയം, ഞങ്ങൾ അതിലേക്ക് എത്തുമ്പോൾ ഞങ്ങൾ അത് ശ്രമിക്കാം.

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