
పెరుగుతున్న కొద్దీ, క్లయింట్లు కింది అభ్యర్థనలను స్వీకరిస్తున్నారు: "మేము అమెజాన్ RDS లాగా కోరుకుంటున్నాము, కానీ చౌకైనది"; "మాకు ఇది RDS లాగా కావాలి, కానీ ప్రతిచోటా, ఏదైనా మౌలిక సదుపాయాలలో." కుబెర్నెటీస్లో అటువంటి నిర్వహించబడే పరిష్కారాన్ని అమలు చేయడానికి, మేము PostgreSQL (Stolon, Crunchy Data మరియు Zalando నుండి ఆపరేటర్లు) కోసం అత్యంత ప్రజాదరణ పొందిన ఆపరేటర్ల ప్రస్తుత స్థితిని పరిశీలించి, మా ఎంపిక చేసుకున్నాము.
ఈ వ్యాసం మేము సైద్ధాంతిక దృక్కోణం నుండి (పరిష్కారాల సమీక్ష) మరియు ఆచరణాత్మక వైపు నుండి (ఏది ఎంపిక చేయబడింది మరియు దాని నుండి వచ్చినది) రెండింటినీ పొందిన అనుభవం. అయితే ముందుగా, RDS కోసం సంభావ్య ప్రత్యామ్నాయం కోసం సాధారణ అవసరాలు ఏమిటో నిర్ధారిద్దాం...
RDS అంటే ఏమిటి
వ్యక్తులు RDS గురించి మాట్లాడినప్పుడు, మా అనుభవంలో, వారు నిర్వహించబడే DBMS సేవ అని అర్థం:
- కాన్ఫిగర్ చేయడం సులభం;
- స్నాప్షాట్లతో పని చేసే సామర్థ్యాన్ని కలిగి ఉంటుంది మరియు వాటి నుండి పునరుద్ధరించవచ్చు (ప్రాధాన్యంగా మద్దతుతో );
- మాస్టర్-స్లేవ్ టోపోలాజీలను రూపొందించడానికి మిమ్మల్ని అనుమతిస్తుంది;
- పొడిగింపుల యొక్క గొప్ప జాబితాను కలిగి ఉంది;
- ఆడిటింగ్ మరియు వినియోగదారు/యాక్సెస్ నిర్వహణను అందిస్తుంది.
సాధారణంగా చెప్పాలంటే, చేతిలో ఉన్న పనిని అమలు చేసే విధానాలు చాలా భిన్నంగా ఉంటాయి, కానీ షరతులతో కూడిన అన్సిబుల్తో మార్గం మనకు దగ్గరగా ఉండదు. (2GIS నుండి సహోద్యోగులు ఫలితంగా ఇదే నిర్ణయానికి వచ్చారు "పోస్ట్గ్రెస్-ఆధారిత ఫెయిల్ఓవర్ క్లస్టర్ను త్వరగా అమలు చేయడానికి ఒక సాధనాన్ని" సృష్టించండి.)
కుబెర్నెట్స్ పర్యావరణ వ్యవస్థలో ఇలాంటి సమస్యలను పరిష్కరించడానికి ఆపరేటర్లు ఒక సాధారణ విధానం. "Flanta" యొక్క సాంకేతిక డైరెక్టర్ ఇప్పటికే Kubernetes లోపల ప్రారంభించబడిన డేటాబేస్లకు సంబంధించి వాటి గురించి మరింత వివరంగా మాట్లాడారు. లో .
NB: సాధారణ ఆపరేటర్లను త్వరగా సృష్టించడానికి, మా ఓపెన్ సోర్స్ యుటిలిటీకి శ్రద్ధ చూపాలని మేము సిఫార్సు చేస్తున్నాము . దీన్ని ఉపయోగించి, మీరు గో గురించి తెలియకుండానే దీన్ని చేయవచ్చు, కానీ సిస్టమ్ అడ్మినిస్ట్రేటర్లకు బాగా తెలిసిన మార్గాల్లో: బాష్, పైథాన్ మొదలైన వాటిలో.
PostgreSQL కోసం అనేక ప్రసిద్ధ K8s ఆపరేటర్లు ఉన్నారు:
- స్టోలోన్;
- క్రంచీ డేటా PostgreSQL ఆపరేటర్;
- Zalando Postgres ఆపరేటర్.
వాటిని మరింత నిశితంగా పరిశీలిద్దాం.
ఆపరేటర్ ఎంపిక
ఇప్పటికే పైన పేర్కొన్న ముఖ్యమైన లక్షణాలతో పాటు, మేము - కుబెర్నెట్స్ ఇన్ఫ్రాస్ట్రక్చర్ ఆపరేషన్స్ ఇంజనీర్లుగా - ఆపరేటర్ల నుండి కింది వాటిని కూడా ఆశించాము:
- Git మరియు దానితో విస్తరణ ;
- పాడ్ వ్యతిరేక అనుబంధ మద్దతు;
- నోడ్ అఫినిటీ లేదా నోడ్ సెలెక్టర్ను ఇన్స్టాల్ చేయడం;
- సహనం యొక్క సంస్థాపన;
- ట్యూనింగ్ సామర్థ్యాల లభ్యత;
- అర్థమయ్యే సాంకేతికతలు మరియు ఆదేశాలు కూడా.
ప్రతి పాయింట్పై వివరాలలోకి వెళ్లకుండా (మొత్తం కథనాన్ని చదివిన తర్వాత వాటి గురించి మీకు ఇంకా ప్రశ్నలు ఉంటే వ్యాఖ్యలలో అడగండి), క్లస్టర్ నోడ్ల స్పెషలైజేషన్ను మరింత ఖచ్చితంగా వివరించడానికి ఈ పారామితులు అవసరమని నేను సాధారణంగా గమనిస్తాను. నిర్దిష్ట అనువర్తనాల కోసం వాటిని ఆర్డర్ చేయండి. ఈ విధంగా మేము పనితీరు మరియు ఖర్చు పరంగా సరైన సమతుల్యతను సాధించవచ్చు.
ఇప్పుడు PostgreSQL ఆపరేటర్లకు వెళ్దాం.
1. స్టోలోన్
ఇటాలియన్ కంపెనీ Sorint.lab నుండి DBMS కోసం ఆపరేటర్లలో ఒక రకమైన ప్రమాణంగా పరిగణించబడింది. ఇది చాలా పాత ప్రాజెక్ట్: దీని మొదటి పబ్లిక్ విడుదల నవంబర్ 2015(!)లో జరిగింది మరియు GitHub రిపోజిటరీలో దాదాపు 3000 నక్షత్రాలు మరియు 40+ కంట్రిబ్యూటర్లు ఉన్నారు.
నిజానికి, స్తోలన్ ఆలోచనాత్మకమైన నిర్మాణానికి అద్భుతమైన ఉదాహరణ:

ఈ ఆపరేటర్ యొక్క పరికరాన్ని నివేదికలో వివరంగా కనుగొనవచ్చు లేదా . సాధారణంగా, ఇది వివరించిన ప్రతిదాన్ని చేయగలదని చెబితే సరిపోతుంది: ఫెయిల్ఓవర్, పారదర్శక క్లయింట్ యాక్సెస్ కోసం ప్రాక్సీలు, బ్యాకప్లు... అంతేకాకుండా, ప్రాక్సీలు ఒక ఎండ్పాయింట్ సేవ ద్వారా యాక్సెస్ను అందిస్తాయి - క్రింద చర్చించిన ఇతర రెండు పరిష్కారాల మాదిరిగా కాకుండా (వాటికి ఒక్కొక్కటి రెండు సేవలు ఉన్నాయి ప్రాప్తి బేస్).
అయితే, స్టోలోన్ , కుబెర్నెటెస్లో DBMS ఉదంతాలను సృష్టించడానికి - "హాట్ కేక్ల వలె" - ఇది సులభంగా మరియు శీఘ్రంగా ఉండే విధంగా ఎందుకు అమలు చేయబడదు. నిర్వహణ యుటిలిటీ ద్వారా నిర్వహించబడుతుంది stolonctl, హెల్మ్ చార్ట్ ద్వారా విస్తరణ జరుగుతుంది మరియు అనుకూలమైనవి కాన్ఫిగ్మ్యాప్లో నిర్వచించబడతాయి మరియు పేర్కొనబడతాయి.
ఒక వైపు, ఆపరేటర్ నిజంగా ఆపరేటర్ కాదని తేలింది (అన్ని తరువాత, ఇది CRDని ఉపయోగించదు). కానీ మరోవైపు, ఇది మీకు సరిపోయే విధంగా K8 లలో వనరులను కాన్ఫిగర్ చేయడానికి మిమ్మల్ని అనుమతించే సౌకర్యవంతమైన వ్యవస్థ.
సంగ్రహంగా చెప్పాలంటే, మాకు వ్యక్తిగతంగా ప్రతి డేటాబేస్ కోసం ప్రత్యేక చార్ట్ను రూపొందించడం సరైనది కాదు. అందువల్ల, మేము ప్రత్యామ్నాయాల కోసం వెతకడం ప్రారంభించాము.
2. క్రంచీ డేటా PostgreSQL ఆపరేటర్
, ఒక యువ అమెరికన్ స్టార్టప్, తార్కిక ప్రత్యామ్నాయంగా అనిపించింది. దీని పబ్లిక్ హిస్టరీ మార్చి 2017లో మొదటి విడుదలతో ప్రారంభమవుతుంది, అప్పటి నుండి GitHub రిపోజిటరీ కేవలం 1300 స్టార్లను మరియు 50+ కంట్రిబ్యూటర్లను అందుకుంది. సెప్టెంబర్ నుండి తాజా విడుదల Kubernetes 1.15-1.18, OpenShift 3.11+ మరియు 4.4+, GKE మరియు VMware Enterprise PKS 1.3+తో పనిచేయడానికి పరీక్షించబడింది.
క్రంచీ డేటా PostgreSQL ఆపరేటర్ యొక్క నిర్మాణం కూడా పేర్కొన్న అవసరాలను తీరుస్తుంది:

నిర్వహణ యుటిలిటీ ద్వారా జరుగుతుంది pgoఅయితే, ఇది కుబెర్నెట్స్ కోసం అనుకూల వనరులను ఉత్పత్తి చేస్తుంది. అందువల్ల, సంభావ్య వినియోగదారులుగా ఆపరేటర్ మమ్మల్ని సంతోషపెట్టారు:
- CRD ద్వారా నియంత్రణ ఉంది;
- అనుకూలమైన వినియోగదారు నిర్వహణ (CRD ద్వారా కూడా);
- ఇతర భాగాలతో ఏకీకరణ - PostgreSQL కోసం కంటైనర్ ఇమేజ్ల యొక్క ప్రత్యేక సేకరణ మరియు దానితో పని చేయడం కోసం యుటిలిటీస్ (pgBackRest, pgAudit, కంట్రిబ్ నుండి పొడిగింపులు మొదలైనవి).
అయినప్పటికీ, క్రంచీ డేటా నుండి ఆపరేటర్ను ఉపయోగించడం ప్రారంభించే ప్రయత్నాలు అనేక సమస్యలను వెల్లడించాయి:
- సహించే అవకాశం లేదు - నోడ్సెలెక్టర్ మాత్రమే అందించబడింది.
- మేము స్టేట్ఫుల్ అప్లికేషన్ని అమలు చేసినప్పటికీ, సృష్టించిన పాడ్లు విస్తరణలో భాగంగా ఉన్నాయి. స్టేట్ఫుల్సెట్ల వలె కాకుండా, డిప్లాయ్మెంట్లు డిస్క్లను సృష్టించలేవు.
చివరి లోపం ఫన్నీ క్షణాలకు దారితీస్తుంది: పరీక్ష వాతావరణంలో మేము ఒక డిస్క్తో 3 ప్రతిరూపాలను అమలు చేయగలిగాము స్థానిక నిల్వ, 3 ప్రతిరూపాలు పని చేస్తున్నాయని ఆపరేటర్ నివేదించడానికి కారణం (అవి కానప్పటికీ).
ఈ ఆపరేటర్ యొక్క మరొక లక్షణం వివిధ సహాయక వ్యవస్థలతో దాని రెడీమేడ్ ఇంటిగ్రేషన్. ఉదాహరణకు, pgAdmin మరియు pgBounceలను ఇన్స్టాల్ చేయడం సులభం ముందుగా కాన్ఫిగర్ చేయబడిన గ్రాఫానా మరియు ప్రోమేతియస్ పరిగణించబడతాయి. ఇటీవలి ప్రాజెక్ట్తో మెరుగైన ఏకీకరణ ప్రత్యేకంగా గుర్తించబడింది , ఆపరేటర్ PgSQL మెట్రిక్ల యొక్క స్పష్టమైన విజువలైజేషన్ను బాక్స్ వెలుపల అందించినందుకు ధన్యవాదాలు.
అయినప్పటికీ, కుబెర్నెట్స్-ఉత్పత్తి చేసిన వనరుల యొక్క విచిత్రమైన ఎంపిక మాకు వేరే పరిష్కారాన్ని కనుగొనవలసిన అవసరానికి దారితీసింది.
3. Zalando Postgres ఆపరేటర్
మేము చాలా కాలంగా Zalando ఉత్పత్తులను తెలుసుకున్నాము: Zalenium ఉపయోగించి మాకు అనుభవం ఉంది మరియు, మేము ప్రయత్నించాము PostgreSQL కోసం వారి ప్రసిద్ధ HA పరిష్కారం. సృష్టించడానికి కంపెనీ విధానం గురించి దాని రచయితలలో ఒకరైన, Alexey Klyukin, ప్రసారంలో చెప్పారు , మరియు మేము దీన్ని ఇష్టపడ్డాము.
వ్యాసంలో చర్చించబడిన అతి పిన్న వయస్కుడైన పరిష్కారం ఇది: మొదటి విడుదల ఆగస్టు 2018లో జరిగింది. అయినప్పటికీ, తక్కువ సంఖ్యలో అధికారిక విడుదలలు ఉన్నప్పటికీ, ప్రాజెక్ట్ చాలా ముందుకు వచ్చింది, GitHubలో 1300+ స్టార్లు మరియు గరిష్ట సంఖ్యలో కంట్రిబ్యూటర్లతో (70+) క్రంచీ డేటా నుండి వచ్చిన పరిష్కారాన్ని ఇప్పటికే అధిగమించింది.
“అండర్ ది హుడ్” ఈ ఆపరేటర్ సమయం-పరీక్షించిన పరిష్కారాలను ఉపయోగిస్తుంది:
- పాత్రోని మరియు డ్రైవింగ్ కోసం,
- - బ్యాకప్ల కోసం,
- - కనెక్షన్ పూల్ వలె.
Zalando నుండి ఆపరేటర్ ఆర్కిటెక్చర్ ఈ విధంగా ప్రదర్శించబడింది:

ఆపరేటర్ పూర్తిగా కస్టమ్ వనరుల ద్వారా నిర్వహించబడుతుంది, కంటైనర్ల నుండి స్టేట్ఫుల్సెట్ను స్వయంచాలకంగా సృష్టిస్తుంది, ఆపై పాడ్కు వివిధ సైడ్కార్లను జోడించడం ద్వారా అనుకూలీకరించవచ్చు. క్రంచీ డేటా నుండి ఆపరేటర్తో పోల్చితే ఇదంతా ఒక ముఖ్యమైన ప్రయోజనం.
మేము పరిశీలనలో ఉన్న 3 ఎంపికలలో Zalando నుండి పరిష్కారాన్ని ఎంచుకున్నాము కాబట్టి, అప్లికేషన్ యొక్క అభ్యాసంతో పాటు దాని సామర్థ్యాల యొక్క తదుపరి వివరణ కూడా క్రింద ప్రదర్శించబడుతుంది.
Zalando నుండి పోస్ట్గ్రెస్ ఆపరేటర్తో ప్రాక్టీస్ చేయండి
ఆపరేటర్ విస్తరణ చాలా సులభం: 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 ఉదాహరణల క్లస్టర్ని అమలు చేస్తుంది , దీని నుండి మేము అప్లికేషన్ మెట్రిక్లను తీసుకుంటాము. మీరు చూడగలిగినట్లుగా, ప్రతిదీ చాలా సులభం, మరియు మీరు కోరుకుంటే, మీరు అక్షరాలా అపరిమిత సంఖ్యలో క్లస్టర్లను సృష్టించవచ్చు.
ఇది దృష్టి పెట్టారు విలువ వెబ్ అడ్మినిస్ట్రేషన్ ప్యానెల్ - . ఇది ఆపరేటర్తో వస్తుంది మరియు క్లస్టర్లను సృష్టించడానికి మరియు తొలగించడానికి మిమ్మల్ని అనుమతిస్తుంది, అలాగే ఆపరేటర్ చేసిన బ్యాకప్లతో పని చేస్తుంది.

PostgreSQL క్లస్టర్ల జాబితా

బ్యాకప్ నిర్వహణ
మరొక ఆసక్తికరమైన ఫీచర్ మద్దతు . ఈ మెకానిజం స్వయంచాలకంగా సృష్టిస్తుంది PostgreSQLలో పాత్రలు, ఫలిత వినియోగదారు పేర్ల జాబితా ఆధారంగా. API తర్వాత మీరు పాత్రలు స్వయంచాలకంగా సృష్టించబడే వినియోగదారుల జాబితాను అందించడానికి మిమ్మల్ని అనుమతిస్తుంది.
సమస్యలు మరియు పరిష్కారాలు
అయినప్పటికీ, ఆపరేటర్ యొక్క ఉపయోగం త్వరలో అనేక ముఖ్యమైన లోపాలను వెల్లడించింది:
- నోడ్ సెలెక్టర్ మద్దతు లేకపోవడం;
- బ్యాకప్లను డిసేబుల్ చేయలేకపోవడం;
- డేటాబేస్ సృష్టి ఫంక్షన్ను ఉపయోగిస్తున్నప్పుడు, డిఫాల్ట్ అధికారాలు కనిపించవు;
- క్రమానుగతంగా, డాక్యుమెంటేషన్ లేదు లేదా గడువు ముగిసింది.
అదృష్టవశాత్తూ, వాటిలో చాలా వరకు పరిష్కరించవచ్చు. ముగింపు నుండి ప్రారంభిద్దాం - సమస్యలు డాక్యుమెంటేషన్.
చాలా మటుకు, బ్యాకప్ను ఎలా నమోదు చేయాలి మరియు బ్యాకప్ బకెట్ను ఆపరేటర్ UIకి ఎలా కనెక్ట్ చేయాలి అనేది ఎల్లప్పుడూ స్పష్టంగా తెలియదని మీరు ఎదుర్కొంటారు. డాక్యుమెంటేషన్ పాసింగ్లో దీని గురించి మాట్లాడుతుంది, కానీ నిజమైన వివరణ ఉంది :
- ఒక రహస్య చేయడానికి అవసరం;
- దానిని ఆపరేటర్కి పారామీటర్గా పంపండి
pod_environment_secret_nameCRDలో ఆపరేటర్ సెట్టింగ్లతో లేదా కాన్ఫిగ్మ్యాప్లో (మీరు ఆపరేటర్ను ఎలా ఇన్స్టాల్ చేయాలని నిర్ణయించుకుంటారు అనేదానిపై ఆధారపడి ఉంటుంది).
అయితే, ఇది మారినట్లుగా, ఇది ప్రస్తుతం అసాధ్యం. అందుకే సేకరించాం కొన్ని అదనపు మూడవ పక్ష పరిణామాలతో. దాని గురించి మరింత సమాచారం కోసం, క్రింద చూడండి.
మీరు బ్యాకప్ కోసం పారామితులను ఆపరేటర్కు పాస్ చేస్తే, అవి - wal_s3_bucket మరియు AWS S3లో యాక్సెస్ కీలు, ఆపై అది ప్రతిదీ బ్యాకప్ చేస్తుంది: ఉత్పత్తిలో స్థావరాలు మాత్రమే కాదు, స్టేజింగ్ కూడా. ఇది మాకు సరిపోలేదు.
ఆపరేటర్ను ఉపయోగిస్తున్నప్పుడు PgSQL కోసం ప్రాథమిక డాకర్ రేపర్ అయిన స్పిలో కోసం పారామితుల వివరణలో, ఇది తేలింది: మీరు పరామితిని పాస్ చేయవచ్చు WAL_S3_BUCKET ఖాళీ, తద్వారా బ్యాకప్లను నిలిపివేస్తుంది. అంతేకాక, గొప్ప ఆనందానికి, నేను కనుగొన్నాను , మేము వెంటనే మా ఫోర్క్లోకి అంగీకరించాము. ఇప్పుడు మీరు జోడించాలి enableWALArchiving: false PostgreSQL క్లస్టర్ వనరుకి.
అవును, 2 ఆపరేటర్లను అమలు చేయడం ద్వారా విభిన్నంగా చేయడానికి అవకాశం ఉంది: ఒకటి స్టేజింగ్ కోసం (బ్యాకప్లు లేకుండా), మరియు రెండవది ఉత్పత్తి కోసం. కానీ మేము ఒకదానితో సరిపెట్టుకోగలిగాము.
సరే, మేము S3 కోసం డేటాబేస్లకు యాక్సెస్ను ఎలా బదిలీ చేయాలో నేర్చుకున్నాము మరియు బ్యాకప్లు నిల్వలోకి రావడం ప్రారంభించాయి. ఆపరేటర్ UIలో బ్యాకప్ పేజీలు పని చేసేలా చేయడం ఎలా?

మీరు ఆపరేటర్ UIకి 3 వేరియబుల్స్ జోడించాలి:
-
SPILO_S3_BACKUP_BUCKET -
AWS_ACCESS_KEY_ID -
AWS_SECRET_ACCESS_KEY
దీని తరువాత, బ్యాకప్ల నిర్వహణ అందుబాటులోకి వస్తుంది, ఇది మా విషయంలో స్టేజింగ్తో పనిని సులభతరం చేస్తుంది, అదనపు స్క్రిప్ట్లు లేకుండా ఉత్పత్తి నుండి ముక్కలను పంపిణీ చేయడానికి మాకు వీలు కల్పిస్తుంది.
మరో ప్రయోజనం ఏమిటంటే, టీమ్స్ APIతో పని చేయడం మరియు ఆపరేటర్ సాధనాలను ఉపయోగించి డేటాబేస్లు మరియు పాత్రలను రూపొందించడానికి పుష్కలమైన అవకాశాలు. అయితే, సృష్టించబడింది పాత్రలకు డిఫాల్ట్గా హక్కులు లేవు. దీని ప్రకారం, రీడ్ రైట్స్ ఉన్న వినియోగదారు కొత్త పట్టికలను చదవలేరు.
అది ఎందుకు? కోడ్లో వాస్తవం ఉన్నప్పటికీ అవసరమైన GRANT, అవి ఎల్లప్పుడూ ఉపయోగించబడవు. 2 పద్ధతులు ఉన్నాయి: syncPreparedDatabases и syncDatabases. ది syncPreparedDatabases - విభాగంలో వాస్తవం ఉన్నప్పటికీ preparedDatabases ఒక షరతు ఉంది defaultRoles и defaultUsers పాత్రలను సృష్టించడానికి, డిఫాల్ట్ హక్కులు వర్తించవు. ఈ హక్కులు స్వయంచాలకంగా వర్తించబడేలా మేము ప్యాచ్ని సిద్ధం చేసే ప్రక్రియలో ఉన్నాము.
మరియు మాకు సంబంధించిన మెరుగుదలలలో చివరి పాయింట్ - , ఇది సృష్టించబడిన స్టేట్ఫుల్సెట్కు నోడ్ అనుబంధాన్ని జోడిస్తుంది. మా క్లయింట్లు తరచుగా స్పాట్ ఇన్స్టాన్స్లను ఉపయోగించడం ద్వారా ఖర్చులను తగ్గించుకోవడానికి ఇష్టపడతారు మరియు డేటాబేస్ సేవలను హోస్టింగ్ చేయడం విలువైనది కాదు. ఈ సమస్యను సహనం ద్వారా పరిష్కరించవచ్చు, కానీ నోడ్ అఫినిటీ ఉనికి మరింత విశ్వాసాన్ని ఇస్తుంది.
ఏమైంది?
పై సమస్యలను పరిష్కరించిన ఫలితాల ఆధారంగా, మేము Zalando నుండి పోస్ట్గ్రెస్ ఆపరేటర్ని ఫోర్క్ చేసాము , అటువంటి ఉపయోగకరమైన పాచెస్తో ఎక్కడ సేకరించబడుతుంది. మరియు ఎక్కువ సౌలభ్యం కోసం, మేము కూడా సేకరించాము .
ఫోర్క్లో ఆమోదించబడిన PRల జాబితా:
- ;
- ;
- ;
- .
కమ్యూనిటీ ఈ PRలకు మద్దతిస్తే చాలా బాగుంటుంది, తద్వారా వారు ఆపరేటర్ యొక్క తదుపరి వెర్షన్ (1.6)తో అప్స్ట్రీమ్ పొందుతారు.
అదనపు! ఉత్పత్తి వలస విజయ గాథ
మీరు Patroniని ఉపయోగిస్తే, లైవ్ ప్రొడక్షన్ని అతి తక్కువ సమయ వ్యవధితో ఆపరేటర్కి తరలించవచ్చు.
S3 నిల్వ ద్వారా స్టాండ్బై క్లస్టర్లను సృష్టించడానికి స్పిలో మిమ్మల్ని అనుమతిస్తుంది , PgSQL బైనరీ లాగ్ మొదట S3లో నిల్వ చేయబడి, ఆపై ప్రతిరూపం ద్వారా పంప్ చేయబడినప్పుడు. కానీ మీ వద్ద ఉంటే ఏమి చేయాలి కాదు పాత మౌలిక సదుపాయాలపై Wal-E ఉపయోగించారా? ఈ సమస్యకు పరిష్కారం ఇప్పటికే ఉంది హబ్ మీద.
PostgreSQL లాజికల్ రెప్లికేషన్ రెస్క్యూకి వస్తుంది. అయినప్పటికీ, ప్రచురణలు మరియు సభ్యత్వాలను ఎలా సృష్టించాలనే దాని గురించి మేము వివరంగా చెప్పము, ఎందుకంటే... మా ప్లాన్ అపజయం.
వాస్తవం ఏమిటంటే, డేటాబేస్ మిలియన్ల వరుసలతో అనేక లోడ్ చేయబడిన పట్టికలను కలిగి ఉంది, అంతేకాకుండా, నిరంతరం భర్తీ చేయబడుతుంది మరియు తొలగించబడుతుంది. с copy_data, కొత్త ప్రతిరూపం మాస్టర్ నుండి అన్ని విషయాలను కాపీ చేసినప్పుడు, అది కేవలం మాస్టర్తో కొనసాగదు. కంటెంట్ను కాపీ చేయడం ఒక వారం పాటు పనిచేసింది, కానీ మాస్టర్తో ఎప్పుడూ పట్టుకోలేదు. చివరికి, ఇది సమస్యను పరిష్కరించడానికి నాకు సహాయపడింది Avito నుండి సహచరులు: మీరు ఉపయోగించి డేటాను బదిలీ చేయవచ్చు pg_dump. నేను ఈ అల్గోరిథం యొక్క మా (కొద్దిగా సవరించిన) సంస్కరణను వివరిస్తాను.
మీరు ఒక నిర్దిష్ట రెప్లికేషన్ స్లాట్తో అనుబంధించబడిన డిసేబుల్ సబ్స్క్రిప్షన్ను తయారు చేసి, ఆపై లావాదేవీ నంబర్ను సరిచేయవచ్చు. ప్రొడక్షన్ వర్క్ కోసం ప్రతిరూపాలు అందుబాటులో ఉన్నాయి. ఇది చాలా ముఖ్యం ఎందుకంటే ప్రతిరూపం స్థిరమైన డంప్ని సృష్టించడానికి మరియు మాస్టర్ నుండి మార్పులను స్వీకరించడానికి సహాయం చేస్తుంది.
మైగ్రేషన్ ప్రక్రియను వివరించే తదుపరి ఆదేశాలు క్రింది హోస్ట్ సంజ్ఞామానాలను ఉపయోగిస్తాయి:
- మాస్టర్ - మూల సర్వర్;
- ప్రతిరూపం 1 - పాత ఉత్పత్తిపై స్ట్రీమింగ్ ప్రతిరూపం;
- ప్రతిరూపం 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. ప్రతిరూపణను నిలిపివేసిన తర్వాత, మీరు సీక్వెన్స్లను సరిచేయాలి. ఇది బాగా వివరించబడింది .
ఈ ప్లాన్కు ధన్యవాదాలు, స్విచ్ఓవర్ తక్కువ ఆలస్యంతో జరిగింది.
తీర్మానం
Kubernetes ఆపరేటర్లు K8s వనరుల సృష్టికి వాటిని తగ్గించడం ద్వారా వివిధ చర్యలను సులభతరం చేయడానికి మిమ్మల్ని అనుమతిస్తారు. అయినప్పటికీ, వారి సహాయంతో విశేషమైన ఆటోమేషన్ను సాధించడం ద్వారా, ఇది అనేక ఊహించని సూక్ష్మ నైపుణ్యాలను కూడా తీసుకురాగలదని గుర్తుంచుకోవడం విలువ, కాబట్టి మీ ఆపరేటర్లను తెలివిగా ఎంచుకోండి.
PostgreSQL కోసం మూడు అత్యంత జనాదరణ పొందిన కుబెర్నెట్స్ ఆపరేటర్లను పరిగణించిన తరువాత, మేము Zalando నుండి ప్రాజెక్ట్ను ఎంచుకున్నాము. మరియు మేము దానితో కొన్ని ఇబ్బందులను అధిగమించవలసి వచ్చింది, కానీ ఫలితం నిజంగా ఆహ్లాదకరంగా ఉంది, కాబట్టి మేము ఈ అనుభవాన్ని కొన్ని ఇతర PgSQL ఇన్స్టాలేషన్లకు విస్తరించాలని ప్లాన్ చేస్తున్నాము. ఇలాంటి పరిష్కారాలను ఉపయోగించి మీకు అనుభవం ఉంటే, వ్యాఖ్యలలో వివరాలను చూడటానికి మేము సంతోషిస్తాము!
PS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «".
మూలం: www.habr.com
