Kubernetes, ഞങ്ങളുടെ തിരഞ്ഞെടുപ്പുകൾ, അനുഭവങ്ങൾ എന്നിവയ്‌ക്കായുള്ള PostgreSQL പ്രസ്താവനകളുടെ ഒരു ഹ്രസ്വ അവലോകനം

ക്ലയന്റുകൾ കൂടുതലായി ഇനിപ്പറയുന്ന അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്നു: "ഞങ്ങൾക്ക് ഇത് Amazon RDS പോലെ വേണം, എന്നാൽ വിലകുറഞ്ഞതാണ്"; "ഞങ്ങൾക്ക് ഇത് ആർ‌ഡി‌എസ് പോലെ വേണം, എന്നാൽ എല്ലായിടത്തും, ഏത് ഇൻഫ്രാസ്ട്രക്ചറിലും." Kubernetes-ൽ ഇത്തരമൊരു നിയന്ത്രിത പരിഹാരം നടപ്പിലാക്കാൻ, PostgreSQL (Stolon, Crunchy Data, Zalando എന്നിവയിൽ നിന്നുള്ള ഓപ്പറേറ്റർമാർ) ഏറ്റവും ജനപ്രിയമായ ഓപ്പറേറ്റർമാരുടെ നിലവിലെ അവസ്ഥ ഞങ്ങൾ പരിശോധിച്ച് ഞങ്ങളുടെ തിരഞ്ഞെടുപ്പ് നടത്തി.

ഈ ലേഖനം ഒരു സൈദ്ധാന്തിക വീക്ഷണകോണിൽ നിന്നും (പരിഹാരങ്ങളുടെ അവലോകനം) പ്രായോഗിക വശങ്ങളിൽ നിന്നും (എന്താണ് തിരഞ്ഞെടുത്തത്, അതിൽ നിന്ന് വന്നത്) ഞങ്ങൾ നേടിയ അനുഭവമാണ്. എന്നാൽ ആദ്യം, RDS-ന് പകരം വയ്ക്കാൻ സാധ്യതയുള്ള പൊതുവായ ആവശ്യകതകൾ എന്തൊക്കെയാണെന്ന് നമുക്ക് നിർണ്ണയിക്കാം...

എന്താണ് RDS

ആളുകൾ RDS-നെ കുറിച്ച് സംസാരിക്കുമ്പോൾ, ഞങ്ങളുടെ അനുഭവത്തിൽ, അവർ അർത്ഥമാക്കുന്നത് ഒരു നിയന്ത്രിത DBMS സേവനമാണ്:

1. ക്രമീകരിക്കാൻ എളുപ്പമാണ്;
2. സ്നാപ്പ്ഷോട്ടുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കാനും അവയിൽ നിന്ന് വീണ്ടെടുക്കാനുമുള്ള കഴിവുണ്ട് (വെയിലത്ത് പിന്തുണയോടെ PITR);
3. മാസ്റ്റർ-സ്ലേവ് ടോപ്പോളജികൾ സൃഷ്ടിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു;
4. വിപുലീകരണങ്ങളുടെ സമ്പന്നമായ ഒരു ലിസ്റ്റ് ഉണ്ട്;
5. ഓഡിറ്റിംഗും ഉപയോക്തൃ/ആക്സസ് മാനേജ്മെന്റും നൽകുന്നു.

പൊതുവായി പറഞ്ഞാൽ, കയ്യിലുള്ള ചുമതല നടപ്പിലാക്കുന്നതിനുള്ള സമീപനങ്ങൾ വളരെ വ്യത്യസ്തമായിരിക്കും, എന്നാൽ സോപാധികമായ അൻസിബിൾ ഉള്ള പാത നമുക്ക് അടുത്തല്ല. (2GIS-ൽ നിന്നുള്ള സഹപ്രവർത്തകർ സമാനമായ ഒരു നിഗമനത്തിലെത്തി അവന്റെ ശ്രമം "പോസ്റ്റ്ഗ്രെസ് അടിസ്ഥാനമാക്കിയുള്ള പരാജയ ക്ലസ്റ്റർ വേഗത്തിൽ വിന്യസിക്കുന്നതിനുള്ള ഒരു ഉപകരണം" സൃഷ്ടിക്കുക.

കുബർനെറ്റസ് ആവാസവ്യവസ്ഥയിലെ സമാന പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനുള്ള ഒരു സാധാരണ സമീപനമാണ് ഓപ്പറേറ്റർമാർ. കുബെർനെറ്റസിനുള്ളിൽ ലോഞ്ച് ചെയ്ത ഡാറ്റാബേസുകളുമായി ബന്ധപ്പെട്ട് "ഫ്ലാന്റ" യുടെ സാങ്കേതിക ഡയറക്ടർ ഇതിനകം കൂടുതൽ വിശദമായി സംസാരിച്ചു. ഡിസ്റ്റോൾഅകത്ത് അദ്ദേഹത്തിന്റെ റിപ്പോർട്ടുകളിലൊന്ന്.

NB: ലളിതമായ ഓപ്പറേറ്റർമാരെ വേഗത്തിൽ സൃഷ്ടിക്കുന്നതിന്, ഞങ്ങളുടെ ഓപ്പൺ സോഴ്സ് യൂട്ടിലിറ്റി ശ്രദ്ധിക്കാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു ഷെൽ ഓപ്പറേറ്റർ. ഇത് ഉപയോഗിച്ച്, Go-യെക്കുറിച്ചുള്ള അറിവില്ലാതെ നിങ്ങൾക്ക് ഇത് ചെയ്യാൻ കഴിയും, എന്നാൽ സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർമാർക്ക് കൂടുതൽ പരിചിതമായ വഴികളിൽ: ബാഷ്, പൈത്തൺ മുതലായവയിൽ.

PostgreSQL-നായി നിരവധി ജനപ്രിയ K8s ഓപ്പറേറ്റർമാർ ഉണ്ട്:

• സ്റ്റോളൺ;
• Crunchy Data PostgreSQL ഓപ്പറേറ്റർ;
• Zalando Postgres ഓപ്പറേറ്റർ.

നമുക്ക് അവരെ കൂടുതൽ സൂക്ഷ്മമായി നോക്കാം.

ഓപ്പറേറ്റർ തിരഞ്ഞെടുക്കൽ

മുകളിൽ സൂചിപ്പിച്ച പ്രധാന സവിശേഷതകൾക്ക് പുറമേ, ഞങ്ങൾ - കുബർനെറ്റസ് ഇൻഫ്രാസ്ട്രക്ചർ ഓപ്പറേഷൻസ് എഞ്ചിനീയർമാർ - ഓപ്പറേറ്റർമാരിൽ നിന്ന് ഇനിപ്പറയുന്നവയും പ്രതീക്ഷിക്കുന്നു:

• Git-ൽ നിന്നും വിന്യാസം ഇഷ്ടാനുസൃത വിഭവങ്ങൾ;
• പോഡ് ആന്റി-അഫിനിറ്റി പിന്തുണ;
• നോഡ് അഫിനിറ്റി അല്ലെങ്കിൽ നോഡ് സെലക്ടർ ഇൻസ്റ്റാൾ ചെയ്യുന്നു;
• ടോളറൻസുകളുടെ ഇൻസ്റ്റാളേഷൻ;
• ട്യൂണിംഗ് കഴിവുകളുടെ ലഭ്യത;
• മനസ്സിലാക്കാവുന്ന സാങ്കേതികവിദ്യകളും കമാൻഡുകൾ പോലും.

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

ഇനി നമുക്ക് PostgreSQL ഓപ്പറേറ്റർമാരിലേക്ക് തന്നെ പോകാം.

1. സ്റ്റോളൺ

സ്റ്റോളൺ ഇറ്റാലിയൻ കമ്പനിയായ Sorint.lab ൽ നിന്ന് ഇതിനകം സൂചിപ്പിച്ച റിപ്പോർട്ട് DBMS-നുള്ള ഓപ്പറേറ്റർമാർക്കിടയിൽ ഒരു തരം നിലവാരമായി കണക്കാക്കപ്പെട്ടിരുന്നു. ഇത് വളരെ പഴയ ഒരു പ്രോജക്റ്റാണ്: അതിന്റെ ആദ്യ പൊതു റിലീസ് 2015 നവംബറിൽ (!) നടന്നു, GitHub ശേഖരത്തിൽ ഏകദേശം 3000 നക്ഷത്രങ്ങളും 40+ സംഭാവകരും ഉണ്ട്.

തീർച്ചയായും, ചിന്തനീയമായ വാസ്തുവിദ്യയുടെ മികച്ച ഉദാഹരണമാണ് സ്റ്റോളൺ:

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

എന്നിരുന്നാലും, സ്റ്റോളൺ ഇഷ്‌ടാനുസൃത ഉറവിടങ്ങളൊന്നുമില്ല, അതുകൊണ്ടാണ് കുബെർനെറ്റസിൽ DBMS സംഭവങ്ങൾ സൃഷ്ടിക്കാൻ - "ചൂടുള്ള കേക്കുകൾ പോലെ" - എളുപ്പത്തിലും വേഗത്തിലും വിന്യസിക്കാൻ കഴിയാത്തത്. യൂട്ടിലിറ്റി വഴിയാണ് മാനേജ്മെന്റ് നടത്തുന്നത് stolonctl, വിന്യാസം ചെയ്യുന്നത് ഹെൽം ചാർട്ടിലൂടെയാണ്, കൂടാതെ ഇഷ്ടാനുസൃതമായവ കോൺഫിഗ്മാപ്പിൽ നിർവചിക്കുകയും വ്യക്തമാക്കുകയും ചെയ്യുന്നു.

ഒരു വശത്ത്, ഓപ്പറേറ്റർ യഥാർത്ഥത്തിൽ ഒരു ഓപ്പറേറ്ററല്ലെന്ന് മാറുന്നു (എല്ലാത്തിനുമുപരി, ഇത് CRD ഉപയോഗിക്കുന്നില്ല). എന്നാൽ മറുവശത്ത്, നിങ്ങൾക്ക് അനുയോജ്യമെന്ന് തോന്നുന്ന രീതിയിൽ K8- കളിൽ ഉറവിടങ്ങൾ ക്രമീകരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു ഫ്ലെക്സിബിൾ സിസ്റ്റമാണിത്.

ചുരുക്കത്തിൽ, വ്യക്തിപരമായി ഞങ്ങൾക്ക് ഓരോ ഡാറ്റാബേസിനും ഒരു പ്രത്യേക ചാർട്ട് സൃഷ്ടിക്കുന്നത് അനുയോജ്യമല്ലെന്ന് തോന്നുന്നു. അതിനാൽ, ഞങ്ങൾ ഇതരമാർഗങ്ങൾ തേടാൻ തുടങ്ങി.

2. Crunchy Data PostgreSQL ഓപ്പറേറ്റർ

Crunchy ഡാറ്റയിൽ നിന്നുള്ള ഓപ്പറേറ്റർ, ഒരു യുവ അമേരിക്കൻ സ്റ്റാർട്ടപ്പ്, ഒരു ലോജിക്കൽ ബദൽ പോലെ തോന്നി. 2017 മാർച്ചിലെ ആദ്യ റിലീസിലാണ് ഇതിന്റെ പൊതു ചരിത്രം ആരംഭിക്കുന്നത്, അതിനുശേഷം GitHub ശേഖരത്തിന് 1300 നക്ഷത്രങ്ങളും 50+ സംഭാവകരും മാത്രമേ ലഭിച്ചിട്ടുള്ളൂ. സെപ്തംബറിലെ ഏറ്റവും പുതിയ പതിപ്പ്, കുബർനെറ്റസ് 1.15-1.18, ഓപ്പൺഷിഫ്റ്റ് 3.11+, 4.4+, GKE, VMware Enterprise PKS 1.3+ എന്നിവയ്‌ക്കൊപ്പം പ്രവർത്തിക്കാൻ പരീക്ഷിച്ചു.

Crunchy Data PostgreSQL ഓപ്പറേറ്ററിന്റെ ആർക്കിടെക്ചറും പ്രസ്താവിച്ച ആവശ്യകതകൾ നിറവേറ്റുന്നു:

മാനേജ്മെന്റ് യൂട്ടിലിറ്റി വഴിയാണ് സംഭവിക്കുന്നത് pgo, എന്നിരുന്നാലും, ഇത് കുബർനെറ്റുകൾക്കായി ഇഷ്‌ടാനുസൃത ഉറവിടങ്ങൾ സൃഷ്ടിക്കുന്നു. അതിനാൽ, സാധ്യതയുള്ള ഉപയോക്താക്കളെന്ന നിലയിൽ ഓപ്പറേറ്റർ ഞങ്ങളെ സന്തോഷിപ്പിച്ചു:

• CRD വഴി നിയന്ത്രണമുണ്ട്;
• സൗകര്യപ്രദമായ ഉപയോക്തൃ മാനേജ്മെന്റ് (സിആർഡി വഴിയും);
• മറ്റ് ഘടകങ്ങളുമായി സംയോജനം ക്രഞ്ചി ഡാറ്റ കണ്ടെയ്നർ സ്യൂട്ട് - PostgreSQL-നുള്ള കണ്ടെയ്‌നർ ചിത്രങ്ങളുടെ ഒരു പ്രത്യേക ശേഖരവും അതിനൊപ്പം പ്രവർത്തിക്കുന്നതിനുള്ള യൂട്ടിലിറ്റികളും (pgBackRest, pgAudit, contrib-ൽ നിന്നുള്ള വിപുലീകരണങ്ങൾ മുതലായവ ഉൾപ്പെടെ).

എന്നിരുന്നാലും, ക്രഞ്ചി ഡാറ്റയിൽ നിന്ന് ഓപ്പറേറ്റർ ഉപയോഗിക്കാൻ തുടങ്ങാനുള്ള ശ്രമങ്ങൾ നിരവധി പ്രശ്നങ്ങൾ വെളിപ്പെടുത്തി:

• സഹിഷ്ണുതയ്ക്ക് സാധ്യതയില്ല - നോഡ് സെലക്ടർ മാത്രമേ നൽകിയിട്ടുള്ളൂ.
• ഞങ്ങൾ ഒരു സ്‌റ്റേറ്റ്‌ഫുൾ ആപ്ലിക്കേഷൻ വിന്യസിച്ചിട്ടുണ്ടെങ്കിലും, സൃഷ്‌ടിച്ച പോഡുകൾ വിന്യാസത്തിന്റെ ഭാഗമായിരുന്നു. സ്റ്റേറ്റ്ഫുൾസെറ്റുകളിൽ നിന്ന് വ്യത്യസ്തമായി, ഡിപ്ലോയ്മെന്റുകൾക്ക് ഡിസ്കുകൾ സൃഷ്ടിക്കാൻ കഴിയില്ല.

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

വിവിധ ഓക്സിലറി സിസ്റ്റങ്ങളുമായുള്ള റെഡിമെയ്ഡ് സംയോജനമാണ് ഈ ഓപ്പറേറ്ററുടെ മറ്റൊരു സവിശേഷത. ഉദാഹരണത്തിന്, pgAdmin, pgBounce എന്നിവ ഇൻസ്റ്റാൾ ചെയ്യുന്നത് എളുപ്പമാണ് പ്രമാണീകരണം മുൻകൂട്ടി ക്രമീകരിച്ച ഗ്രാഫാനയും പ്രൊമിത്യൂസും പരിഗണിക്കപ്പെടുന്നു. സമീപകാലത്ത് റിലീസ് 4.5.0-beta1 പ്രോജക്റ്റുമായുള്ള മെച്ചപ്പെട്ട സംയോജനം പ്രത്യേകം ശ്രദ്ധിക്കുന്നു pgMonitor, ഓപ്പറേറ്റർ PgSQL മെട്രിക്സിന്റെ വ്യക്തമായ ദൃശ്യവൽക്കരണം ബോക്സിന് പുറത്ത് വാഗ്ദാനം ചെയ്തതിന് നന്ദി.

എന്നിരുന്നാലും, കുബർനെറ്റസ് സൃഷ്ടിച്ച വിഭവങ്ങളുടെ വിചിത്രമായ തിരഞ്ഞെടുപ്പ് മറ്റൊരു പരിഹാരം കണ്ടെത്തേണ്ടതിന്റെ ആവശ്യകതയിലേക്ക് ഞങ്ങളെ നയിച്ചു.

3. Zalando Postgres ഓപ്പറേറ്റർ

ഞങ്ങൾക്ക് വളരെക്കാലമായി Zalando ഉൽപ്പന്നങ്ങൾ അറിയാം: ഞങ്ങൾക്ക് Zalenium ഉപയോഗിച്ച അനുഭവമുണ്ട്, തീർച്ചയായും ഞങ്ങൾ ശ്രമിച്ചു പത്രോണി PostgreSQL-നുള്ള അവരുടെ ജനപ്രിയ HA പരിഹാരമാണ്. സൃഷ്ടിക്കുന്നതിനുള്ള കമ്പനിയുടെ സമീപനത്തെക്കുറിച്ച് പോസ്റ്റ്ഗ്രെസ് ഓപ്പറേറ്റർ അതിന്റെ രചയിതാക്കളിലൊരാളായ അലക്സി ക്ല്യൂക്കിൻ പറഞ്ഞു പോസ്റ്റ്ഗ്രെസ്-ചൊവ്വ #5, ഞങ്ങൾക്കത് ഇഷ്ടപ്പെട്ടു.

ലേഖനത്തിൽ ചർച്ച ചെയ്ത ഏറ്റവും പ്രായം കുറഞ്ഞ പരിഹാരമാണിത്: ആദ്യ റിലീസ് 2018 ഓഗസ്റ്റിൽ നടന്നു. എന്നിരുന്നാലും, ഔപചാരികമായ റിലീസുകളുടെ എണ്ണം കുറവാണെങ്കിലും, പ്രോജക്റ്റ് ഒരുപാട് മുന്നോട്ട് പോയി, GitHub-ൽ 1300+ നക്ഷത്രങ്ങളും പരമാവധി സംഭാവന ചെയ്യുന്നവരും (70+) ഉള്ള Crunchy Data-ൽ നിന്നുള്ള പരിഹാരത്തെ ഇതിനകം മറികടന്നു.

"അണ്ടർ ദി ഹുഡ്" ഈ ഓപ്പറേറ്റർ സമയം പരിശോധിച്ച പരിഹാരങ്ങൾ ഉപയോഗിക്കുന്നു:

• പത്രോണിയും സ്പിലോ ഡ്രൈവിംഗിന്,
• വാൽ-ഇ - ബാക്കപ്പുകൾക്കായി,
• പിജിബൗൺസർ - ഒരു കണക്ഷൻ പൂളായി.

സലാൻഡോയിൽ നിന്നുള്ള ഓപ്പറേറ്റർ ആർക്കിടെക്ചർ അവതരിപ്പിക്കുന്നത് ഇങ്ങനെയാണ്:

ഇഷ്‌ടാനുസൃത ഉറവിടങ്ങളിലൂടെ ഓപ്പറേറ്റർ പൂർണ്ണമായി നിയന്ത്രിക്കപ്പെടുന്നു, കണ്ടെയ്‌നറുകളിൽ നിന്ന് ഒരു സ്റ്റേറ്റ്‌ഫുൾസെറ്റ് സ്വയമേവ സൃഷ്‌ടിക്കുന്നു, അത് പോഡിലേക്ക് വിവിധ സൈഡ്‌കാറുകൾ ചേർത്ത് ഇഷ്ടാനുസൃതമാക്കാനാകും. ക്രഞ്ചി ഡാറ്റയിൽ നിന്നുള്ള ഓപ്പറേറ്ററുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഇതെല്ലാം ഒരു പ്രധാന നേട്ടമാണ്.

പരിഗണനയിലുള്ള 3 ഓപ്‌ഷനുകളിൽ നിന്ന് ഞങ്ങൾ സലാൻഡോയിൽ നിന്ന് പരിഹാരം തിരഞ്ഞെടുത്തതിനാൽ, ആപ്ലിക്കേഷന്റെ പരിശീലനത്തോടൊപ്പം അതിന്റെ കഴിവുകളെക്കുറിച്ചുള്ള കൂടുതൽ വിവരണം ചുവടെ അവതരിപ്പിക്കും.

സലാൻഡോയിൽ നിന്നുള്ള പോസ്റ്റ്‌ഗ്രെസ് ഓപ്പറേറ്ററുമായി പരിശീലിക്കുക

ഓപ്പറേറ്റർ വിന്യാസം വളരെ ലളിതമാണ്: GitHub-ൽ നിന്ന് നിലവിലെ റിലീസ് ഡൗൺലോഡ് ചെയ്ത് ഡയറക്ടറിയിൽ നിന്ന് YAML ഫയലുകൾ പ്രയോഗിക്കുക. പ്രകടമാകുന്നു. പകരമായി, നിങ്ങൾക്ക് ഉപയോഗിക്കാനും കഴിയും ഓപ്പറേറ്റർഹബ്.

ഇൻസ്റ്റാളേഷന് ശേഷം, സജ്ജീകരിക്കുന്നതിനെക്കുറിച്ച് നിങ്ങൾ വിഷമിക്കേണ്ടതുണ്ട് ലോഗുകൾക്കും ബാക്കപ്പുകൾക്കുമുള്ള സംഭരണം. ConfigMap വഴിയാണ് ഇത് ചെയ്യുന്നത് postgres-operator നിങ്ങൾ ഓപ്പറേറ്റർ ഇൻസ്റ്റാൾ ചെയ്ത നെയിംസ്പേസിൽ. റിപ്പോസിറ്ററികൾ ക്രമീകരിച്ചുകഴിഞ്ഞാൽ, നിങ്ങൾക്ക് നിങ്ങളുടെ ആദ്യത്തെ PostgreSQL ക്ലസ്റ്റർ വിന്യസിക്കാം.

ഉദാഹരണത്തിന്, ഞങ്ങളുടെ സ്റ്റാൻഡേർഡ് വിന്യാസം ഇതുപോലെ കാണപ്പെടുന്നു:

apiVersion: acid.zalan.do/v1
kind: postgresql
metadata:
 name: staging-db
spec:
 numberOfInstances: 3
 patroni:
   synchronous_mode: true
 postgresql:
   version: "12"
 resources:
   limits:
     cpu: 100m
     memory: 1Gi
   requests:
     cpu: 100m
     memory: 1Gi
 sidecars:
 - env:
   - name: DATA_SOURCE_URI
     value: 127.0.0.1:5432
   - name: DATA_SOURCE_PASS
     valueFrom:
       secretKeyRef:
         key: password
         name: postgres.staging-db.credentials
   - name: DATA_SOURCE_USER
     value: postgres
   image: wrouesnel/postgres_exporter
   name: prometheus-exporter
   resources:
     limits:
       cpu: 500m
       memory: 100Mi
     requests:
       cpu: 100m
       memory: 100Mi
 teamId: staging
 volume:
   size: 2Gi

ഈ മാനിഫെസ്റ്റ് രൂപത്തിൽ സൈഡ്കാർ ഉള്ള 3 സംഭവങ്ങളുടെ ഒരു ക്ലസ്റ്റർ വിന്യസിക്കുന്നു postgres_exporter, അതിൽ നിന്ന് ഞങ്ങൾ ആപ്ലിക്കേഷൻ മെട്രിക്സ് എടുക്കുന്നു. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, എല്ലാം വളരെ ലളിതമാണ്, നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് അക്ഷരാർത്ഥത്തിൽ പരിധിയില്ലാത്ത ക്ലസ്റ്ററുകൾ സൃഷ്ടിക്കാൻ കഴിയും.

ഇത് ശ്രദ്ധിക്കുന്നത് മൂല്യവത്താണ് വെബ് അഡ്മിനിസ്ട്രേഷൻ പാനൽ - postgres-operator-ui. ഇത് ഓപ്പറേറ്ററിനൊപ്പം വരുന്നു കൂടാതെ ക്ലസ്റ്ററുകൾ സൃഷ്ടിക്കാനും ഇല്ലാതാക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു, അതുപോലെ തന്നെ ഓപ്പറേറ്റർ നിർമ്മിച്ച ബാക്കപ്പുകൾ ഉപയോഗിച്ച് പ്രവർത്തിക്കാനും ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

PostgreSQL ക്ലസ്റ്ററുകളുടെ പട്ടിക

ബാക്കപ്പ് മാനേജ്മെന്റ്

മറ്റൊരു രസകരമായ സവിശേഷത പിന്തുണയാണ് ടീമുകളുടെ API. ഈ സംവിധാനം യാന്ത്രികമായി സൃഷ്ടിക്കുന്നു PostgreSQL-ലെ റോളുകൾ, ഫലമായുണ്ടാകുന്ന ഉപയോക്തൃനാമങ്ങളുടെ ലിസ്റ്റ് അടിസ്ഥാനമാക്കി. റോളുകൾ സ്വയമേവ സൃഷ്‌ടിച്ച ഉപയോക്താക്കളുടെ ഒരു ലിസ്റ്റ് തിരികെ നൽകാൻ API നിങ്ങളെ അനുവദിക്കുന്നു.

പ്രശ്നങ്ങളും പരിഹാരങ്ങളും

എന്നിരുന്നാലും, ഓപ്പറേറ്ററുടെ ഉപയോഗം ഉടൻ തന്നെ നിരവധി സുപ്രധാന പോരായ്മകൾ വെളിപ്പെടുത്തി:

1. നോഡ് സെലക്ടർ പിന്തുണയുടെ അഭാവം;
2. ബാക്കപ്പുകൾ പ്രവർത്തനരഹിതമാക്കാനുള്ള കഴിവില്ലായ്മ;
3. ഡാറ്റാബേസ് സൃഷ്ടിക്കൽ ഫംഗ്ഷൻ ഉപയോഗിക്കുമ്പോൾ, ഡിഫോൾട്ട് പ്രത്യേകാവകാശങ്ങൾ ദൃശ്യമാകില്ല;
4. ചിലപ്പോൾ ഡോക്യുമെന്റേഷൻ കാണുന്നില്ല അല്ലെങ്കിൽ കാലഹരണപ്പെട്ടതാണ്.

ഭാഗ്യവശാൽ, അവയിൽ പലതും പരിഹരിക്കാൻ കഴിയും. നമുക്ക് അവസാനം മുതൽ ആരംഭിക്കാം - പ്രശ്നങ്ങൾ പ്രമാണീകരണം.

മിക്കവാറും, ഒരു ബാക്കപ്പ് എങ്ങനെ രജിസ്റ്റർ ചെയ്യാമെന്നും ഓപ്പറേറ്റർ യുഐയിലേക്ക് ബാക്കപ്പ് ബക്കറ്റ് എങ്ങനെ ബന്ധിപ്പിക്കാമെന്നും എല്ലായ്പ്പോഴും വ്യക്തമല്ല എന്ന വസ്തുത നിങ്ങൾ അഭിമുഖീകരിക്കും. ഡോക്യുമെന്റേഷൻ ഇതിനെക്കുറിച്ച് സംസാരിക്കുന്നു, പക്ഷേ യഥാർത്ഥ വിവരണം ഇതിലുണ്ട് PR:

1. ഒരു രഹസ്യം ഉണ്ടാക്കണം;
2. ഇത് ഒരു പാരാമീറ്ററായി ഓപ്പറേറ്റർക്ക് കൈമാറുക pod_environment_secret_name CRD-ൽ ഓപ്പറേറ്റർ ക്രമീകരണങ്ങൾ അല്ലെങ്കിൽ കോൺഫിഗ്മാപ്പിൽ (ഓപ്പറേറ്റർ എങ്ങനെ ഇൻസ്റ്റാൾ ചെയ്യാൻ നിങ്ങൾ തീരുമാനിക്കുന്നു എന്നതിനെ ആശ്രയിച്ച്).

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

ബാക്കപ്പിനുള്ള പാരാമീറ്ററുകൾ നിങ്ങൾ ഓപ്പറേറ്റർക്ക് കൈമാറുകയാണെങ്കിൽ, അതായത് - wal_s3_bucket കൂടാതെ AWS S3-ലെ ആക്സസ് കീകൾ, പിന്നെ അത് എല്ലാം ബാക്കപ്പ് ചെയ്യും: ഉൽപ്പാദനത്തിലെ അടിസ്ഥാനങ്ങൾ മാത്രമല്ല, സ്റ്റേജിംഗും. ഇത് ഞങ്ങൾക്ക് യോജിച്ചില്ല.

ഓപ്പറേറ്റർ ഉപയോഗിക്കുമ്പോൾ PgSQL-നുള്ള അടിസ്ഥാന ഡോക്കർ റാപ്പറായ സ്‌പൈലോയ്‌ക്കുള്ള പാരാമീറ്ററുകളുടെ വിവരണത്തിൽ, ഇത് മാറി: നിങ്ങൾക്ക് ഒരു പാരാമീറ്റർ കൈമാറാൻ കഴിയും WAL_S3_BUCKET ശൂന്യമാണ്, അതുവഴി ബാക്കപ്പുകൾ പ്രവർത്തനരഹിതമാക്കുന്നു. മാത്രമല്ല, വലിയ സന്തോഷത്തിന്, ഞാൻ കണ്ടെത്തി തയ്യാറായ PR, അത് ഞങ്ങൾ ഉടനടി ഞങ്ങളുടെ നാൽക്കവലയിലേക്ക് സ്വീകരിച്ചു. ഇപ്പോൾ നിങ്ങൾ ചേർക്കേണ്ടതുണ്ട് enableWALArchiving: false ഒരു PostgreSQL ക്ലസ്റ്റർ റിസോഴ്സിലേക്ക്.

അതെ, 2 ഓപ്പറേറ്റർമാരെ പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ ഇത് വ്യത്യസ്തമായി ചെയ്യാനുള്ള അവസരമുണ്ടായിരുന്നു: ഒന്ന് സ്റ്റേജിംഗിനായി (ബാക്കപ്പുകൾ ഇല്ലാതെ), രണ്ടാമത്തേത് ഉത്പാദനത്തിന്. എന്നാൽ ഈ വഴിയിൽ ഞങ്ങൾക്ക് ഒന്ന് ചെയ്യാൻ കഴിഞ്ഞു.

ശരി, S3-നുള്ള ഡാറ്റാബേസുകളിലേക്കുള്ള ആക്സസ് എങ്ങനെ കൈമാറാമെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി, ബാക്കപ്പുകൾ സ്റ്റോറേജിൽ പ്രവേശിക്കാൻ തുടങ്ങി. ഓപ്പറേറ്റർ യുഐയിൽ ബാക്കപ്പ് പേജുകൾ എങ്ങനെ പ്രവർത്തിക്കാം?

ഓപ്പറേറ്റർ യുഐയിലേക്ക് നിങ്ങൾ 3 വേരിയബിളുകൾ ചേർക്കേണ്ടതുണ്ട്:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

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

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

എന്തുകൊണ്ടാണത്? കോഡിലെ വസ്തുത ഉണ്ടായിരുന്നിട്ടും ആകുന്നു ആവശ്യമാണ് GRANT, അവ എപ്പോഴും ഉപയോഗിക്കാറില്ല. 2 രീതികളുണ്ട്: syncPreparedDatabases и syncDatabases. ദി syncPreparedDatabases - വിഭാഗത്തിൽ ഉണ്ടായിരുന്നിട്ടും preparedDatabases ആകുന്നു ഒരു വ്യവസ്ഥയുണ്ട് defaultRoles и defaultUsers റോളുകൾ സൃഷ്ടിക്കുന്നതിന്, സ്ഥിരസ്ഥിതി അവകാശങ്ങൾ ബാധകമല്ല. ഈ അവകാശങ്ങൾ സ്വയമേവ ബാധകമാകുന്ന തരത്തിൽ ഞങ്ങൾ ഒരു പാച്ച് തയ്യാറാക്കുന്ന പ്രക്രിയയിലാണ്.

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

എന്താണ് സംഭവിച്ചത്?

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

ഫോർക്കിലേക്ക് സ്വീകരിച്ച PR-കളുടെ ലിസ്റ്റ്:

• ഡോക്കറിലെ ഓപ്പറേറ്റർക്ക് സുരക്ഷിതമായ ഭാരം കുറഞ്ഞ ചിത്രം നിർമ്മിക്കുന്നു;
• ബാക്കപ്പുകൾ പ്രവർത്തനരഹിതമാക്കുന്നു;
• k8s-ന്റെ നിലവിലെ പതിപ്പുകൾക്കായി റിസോഴ്സ് പതിപ്പുകൾ അപ്ഡേറ്റ് ചെയ്യുന്നു;
• നോഡ് അഫിനിറ്റി നടപ്പിലാക്കൽ.

കമ്മ്യൂണിറ്റി ഈ PR-കളെ പിന്തുണയ്ക്കുന്നുവെങ്കിൽ അത് വളരെ മികച്ചതായിരിക്കും, അതിലൂടെ അവർ ഓപ്പറേറ്ററുടെ അടുത്ത പതിപ്പ് (1.6) ഉപയോഗിച്ച് അപ്‌സ്ട്രീം ചെയ്യപ്പെടും.

ബോണസ്! പ്രൊഡക്ഷൻ മൈഗ്രേഷൻ വിജയഗാഥ

നിങ്ങൾ പത്രോണി ഉപയോഗിക്കുകയാണെങ്കിൽ, തത്സമയ ഉൽപ്പാദനം ചുരുങ്ങിയ സമയത്തിനുള്ളിൽ ഓപ്പറേറ്ററിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യാവുന്നതാണ്.

S3 സ്റ്റോറേജ് വഴി സ്റ്റാൻഡ്‌ബൈ ക്ലസ്റ്ററുകൾ സൃഷ്ടിക്കാൻ Spilo നിങ്ങളെ അനുവദിക്കുന്നു വാൾ-ഇ, PgSQL ബൈനറി ലോഗ് ആദ്യം S3-ൽ സംഭരിക്കുകയും പിന്നീട് പകർപ്പ് പമ്പ് ചെയ്യുകയും ചെയ്യുമ്പോൾ. എന്നാൽ ഉണ്ടെങ്കിൽ എന്തുചെയ്യും അല്ല പഴയ ഇൻഫ്രാസ്ട്രക്ചറിൽ Wal-E ഉപയോഗിച്ചത്? ഈ പ്രശ്നത്തിനുള്ള പരിഹാരം ഇതിനകം തന്നെ അത് നിർദ്ദേശിക്കപ്പെട്ടു ഹബ്ബിൽ.

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

ദശലക്ഷക്കണക്കിന് വരികളുള്ള നിരവധി ലോഡുചെയ്ത പട്ടികകൾ ഡാറ്റാബേസിൽ ഉണ്ടായിരുന്നു എന്നതാണ് വസ്തുത, മാത്രമല്ല, അവ നിരന്തരം നിറയ്ക്കുകയും ഇല്ലാതാക്കുകയും ചെയ്തു. ലളിതമായ സബ്സ്ക്രിപ്ഷൻ с copy_data, പുതിയ പകർപ്പ് മാസ്റ്ററിൽ നിന്ന് എല്ലാ ഉള്ളടക്കങ്ങളും പകർത്തുമ്പോൾ, അതിന് മാസ്റ്ററുമായി പൊരുത്തപ്പെടാൻ കഴിയില്ല. ഉള്ളടക്കം പകർത്തുന്നത് ഒരാഴ്‌ചയോളം പ്രവർത്തിച്ചു, പക്ഷേ ഒരിക്കലും മാസ്റ്ററെ കണ്ടില്ല. അവസാനം, പ്രശ്നം പരിഹരിക്കാൻ എന്നെ സഹായിച്ചു ഒരു ലേഖനം Avito-ൽ നിന്നുള്ള സഹപ്രവർത്തകർ: നിങ്ങൾക്ക് ഇത് ഉപയോഗിച്ച് ഡാറ്റ കൈമാറാൻ കഴിയും pg_dump. ഈ അൽഗോരിതത്തിന്റെ ഞങ്ങളുടെ (ചെറുതായി പരിഷ്കരിച്ച) പതിപ്പ് ഞാൻ വിവരിക്കും.

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

മൈഗ്രേഷൻ പ്രക്രിയ വിവരിക്കുന്ന തുടർന്നുള്ള കമാൻഡുകൾ ഇനിപ്പറയുന്ന ഹോസ്റ്റ് നൊട്ടേഷനുകൾ ഉപയോഗിക്കും:

1. യജമാനന് - ഉറവിട സെർവർ;
2. പകർപ്പ് 1 - പഴയ ഉൽപ്പാദനത്തിൽ സ്ട്രീമിംഗ് പകർപ്പ്;
3. പകർപ്പ് 2 - പുതിയ ലോജിക്കൽ പകർപ്പ്.

മൈഗ്രേഷൻ പ്ലാൻ

1. സ്കീമയിലെ എല്ലാ ടേബിളുകൾക്കുമായി മാസ്റ്ററിൽ ഒരു സബ്സ്ക്രിപ്ഷൻ സൃഷ്ടിക്കുക public അടിസ്ഥാനം dbname:

psql -h master -d dbname -c "CREATE PUBLICATION dbname FOR ALL TABLES;"

2. മാസ്റ്ററിൽ ഒരു റെപ്ലിക്കേഷൻ സ്ലോട്ട് സൃഷ്ടിക്കുക:

psql -h master -c "select pg_create_logical_replication_slot('repl', 'pgoutput');"

3. പഴയ പകർപ്പിലെ പകർപ്പ് നിർത്തുക:

psql -h replica1 -c "select pg_wal_replay_pause();"

4. മാസ്റ്ററിൽ നിന്ന് ഇടപാട് നമ്പർ നേടുക:

psql -h master -c "select replay_lsn from pg_stat_replication where client_addr = 'replica1';"

5. പഴയ പകർപ്പിൽ നിന്ന് ഡംപ് നീക്കം ചെയ്യുക. ഞങ്ങൾ ഇത് നിരവധി ത്രെഡുകളിൽ ചെയ്യും, ഇത് പ്രക്രിയ വേഗത്തിലാക്കാൻ സഹായിക്കും:

pg_dump -h replica1 --no-publications --no-subscriptions -O -C -F d -j 8 -f dump/ dbname

6. പുതിയ സെർവറിലേക്ക് ഡംപ് അപ്‌ലോഡ് ചെയ്യുക:

pg_restore -h replica2 -F d -j 8 -d dbname dump/

7. ഡംപ് ഡൗൺലോഡ് ചെയ്‌ത ശേഷം, സ്ട്രീമിംഗ് റെപ്ലിക്കയിൽ നിങ്ങൾക്ക് പകർപ്പെടുക്കൽ ആരംഭിക്കാം:

psql -h replica1 -c "select pg_wal_replay_resume();"

7. നമുക്ക് ഒരു പുതിയ ലോജിക്കൽ റെപ്ലിക്കയിൽ ഒരു സബ്സ്ക്രിപ്ഷൻ ഉണ്ടാക്കാം:

psql -h replica2 -c "create subscription oldprod connection 'host=replica1 port=5432 user=postgres password=secret dbname=dbname' publication dbname with (enabled = false, create_slot = false, copy_data = false, slot_name='repl');"

8. നമുക്ക് നേടാം oid സബ്സ്ക്രിപ്ഷനുകൾ:

psql -h replica2 -d dbname -c "select oid, * from pg_subscription;"

9. അത് ലഭിച്ചുവെന്ന് പറയാം oid=1000. സബ്‌സ്‌ക്രിപ്‌ഷനിലേക്ക് ഇടപാട് നമ്പർ പ്രയോഗിക്കാം:

psql -h replica2 -d dbname -c "select pg_replication_origin_advance('pg_1000', 'AA/AAAAAAAA');"

10. നമുക്ക് അനുകരണം ആരംഭിക്കാം:

psql -h replica2 -d dbname -c "alter subscription oldprod enable;"

11. സബ്‌സ്‌ക്രിപ്‌ഷൻ നില പരിശോധിക്കുക, പകർപ്പ് പ്രവർത്തിക്കണം:

psql -h replica2 -d dbname -c "select * from pg_replication_origin_status;"
psql -h master -d dbname -c "select slot_name, restart_lsn, confirmed_flush_lsn from pg_replication_slots;"

12. പകർപ്പെടുക്കൽ ആരംഭിച്ച് ഡാറ്റാബേസുകൾ സമന്വയിപ്പിച്ച ശേഷം, നിങ്ങൾക്ക് മാറാം.

13. പകർപ്പെടുക്കൽ പ്രവർത്തനരഹിതമാക്കിയ ശേഷം, നിങ്ങൾ ക്രമങ്ങൾ ശരിയാക്കേണ്ടതുണ്ട്. ഇത് നന്നായി വിവരിച്ചിരിക്കുന്നു wiki.postgresql.org എന്ന ലേഖനത്തിൽ.

ഈ പദ്ധതിക്ക് നന്ദി, സ്വിച്ച്ഓവർ കുറഞ്ഞ കാലതാമസത്തോടെയാണ് നടന്നത്.

തീരുമാനം

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

PostgreSQL-നുള്ള ഏറ്റവും ജനപ്രിയമായ മൂന്ന് കുബർനെറ്റസ് ഓപ്പറേറ്റർമാരെ പരിഗണിച്ച്, ഞങ്ങൾ സലാൻഡോയിൽ നിന്ന് പ്രോജക്റ്റ് തിരഞ്ഞെടുത്തു. ഞങ്ങൾക്ക് ചില ബുദ്ധിമുട്ടുകൾ തരണം ചെയ്യേണ്ടിവന്നു, പക്ഷേ ഫലം ശരിക്കും സന്തോഷകരമായിരുന്നു, അതിനാൽ ഈ അനുഭവം മറ്റ് ചില PgSQL ഇൻസ്റ്റാളേഷനുകളിലേക്ക് വികസിപ്പിക്കാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു. സമാന പരിഹാരങ്ങൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് അനുഭവം ഉണ്ടെങ്കിൽ, അഭിപ്രായങ്ങളിൽ വിശദാംശങ്ങൾ കാണുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട്!

പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «ഡാറ്റാബേസുകളും കുബർനെറ്റുകളും (അവലോകനവും വീഡിയോ റിപ്പോർട്ടും)";
• «Postgres ചൊവ്വാഴ്ച #5: PostgreSQL, Kubernetes എന്നിവ. സിഐ/സിഡി. ടെസ്റ്റ് ഓട്ടോമേഷൻ";
• «K8s-ലെ Redis ഓപ്പറേറ്ററുമായുള്ള ഒരു സ്റ്റോറിയും ഈ ഡാറ്റാബേസിൽ നിന്നുള്ള ഡാറ്റ വിശകലനം ചെയ്യുന്നതിനുള്ള യൂട്ടിലിറ്റികളുടെ ഒരു ചെറിയ അവലോകനവും".

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