🥇Կուբերնետեսի PostgreSQL օպերատորների համառոտ ակնարկ, մեր ընտրությունն ու փորձը

Հաճախորդները գնալով ստանում են հետևյալ հարցումները. «Մենք դա ցանկանում ենք RDS-ի նման, բայց ամենուր, ցանկացած ենթակառուցվածքում»: Kubernetes-ում նման կառավարվող լուծում իրականացնելու համար մենք նայեցինք PostgreSQL-ի (Stolon, Crunchy Data-ի և Zalando-ի օպերատորներ) ամենահայտնի օպերատորների ներկայիս վիճակին և կատարեցինք մեր ընտրությունը:

Այս հոդվածը մեր ձեռք բերած փորձն է թե՛ տեսական տեսանկյունից (լուծումների վերանայում), թե՛ գործնական կողմից (ինչ է ընտրվել և ինչ է ստացվել դրանից): Բայց նախ, եկեք որոշենք, թե որոնք են ընդհանուր պահանջները RDS-ի պոտենցիալ փոխարինման համար...

Ինչ է RDS-ը

Երբ մարդիկ խոսում են RDS-ի մասին, ըստ մեր փորձի, նրանք նկատի ունեն կառավարվող DBMS ծառայություն, որը.

հեշտ է կարգավորել;
ունի snapshot-ների հետ աշխատելու և դրանցից վերականգնվելու հնարավորություն (ցանկալի է աջակցությամբ ՊԻՏՐ);
թույլ է տալիս ստեղծել master-slave տոպոլոգիաներ;
ունի ընդարձակման հարուստ ցանկ;
ապահովում է աուդիտ և օգտագործողների/մուտքի կառավարում:

Ընդհանուր առմամբ, առաջադրանքի իրականացման մոտեցումները կարող են շատ տարբեր լինել, բայց պայմանական Ansible-ով ուղին մեզ մոտ չէ: (Արդյունքում նմանատիպ եզրակացության եկան 2GIS-ի գործընկերները նրա փորձը ստեղծել «գործիք՝ Postgres-ի վրա հիմնված failover կլաստերի արագ տեղակայման համար»:)

Օպերատորները ընդհանուր մոտեցում են Kubernetes էկոհամակարգում նմանատիպ խնդիրների լուծման համար: «Ֆլանտայի» տեխնիկական տնօրենն արդեն ավելի մանրամասն է խոսել դրանց մասին՝ կապված Kubernetes-ի ներսում գործարկված տվյալների բազաների հետ։ դիստոլՄեջ նրա զեկույցներից մեկը.

NBՊարզ օպերատորներ արագ ստեղծելու համար խորհուրդ ենք տալիս ուշադրություն դարձնել մեր բաց կոդով օգտակար ծրագրին shell-օպերատոր. Օգտագործելով այն՝ դուք կարող եք դա անել առանց Go-ի իմացության, բայց համակարգի ադմինիստրատորներին ավելի ծանոթ ձևերով՝ Bash-ում, Python-ում և այլն:

PostgreSQL-ի համար կան մի քանի հայտնի K8s օպերատորներ.

Ստոլոն;
Crunchy Data PostgreSQL օպերատոր;
Zalando Postgres օպերատոր.

Եկեք նրանց ավելի ուշադիր նայենք:

Օպերատորի ընտրություն

Ի լրումն վերը նշված կարևոր հատկանիշների, մենք՝ որպես Kubernetes ենթակառուցվածքի գործառնությունների ինժեներներ, օպերատորներից ակնկալում էինք նաև հետևյալը.

տեղակայում Git-ից և հետ Պատվերով ռեսուրսներ;
pod հակահարաբերական աջակցություն;
հանգույցի մերձեցման կամ հանգույցի ընտրիչի տեղադրում;
հանդուրժողականության տեղադրում;
թյունինգի հնարավորությունների առկայություն;
հասկանալի տեխնոլոգիաներ և նույնիսկ հրամաններ:

Առանց կետերից յուրաքանչյուրի մասին մանրամասնելու (հարցրեք մեկնաբանություններում, եթե դեռ հարցեր ունեք դրանց վերաբերյալ ամբողջ հոդվածը կարդալուց հետո), ես ընդհանուր առմամբ կնշեմ, որ այս պարամետրերը անհրաժեշտ են կլաստերային հանգույցների մասնագիտացումը ավելի ճշգրիտ նկարագրելու համար, որպեսզի պատվիրել դրանք հատուկ ծրագրերի համար: Այս կերպ մենք կարող ենք հասնել օպտիմալ հավասարակշռության կատարման և արժեքի առումով:

Հիմա եկեք անցնենք հենց PostgreSQL օպերատորներին:

1. Ստոլոն

Ստոլոն Իտալական Sorint.lab ընկերությունից արդեն նշված զեկույցը համարվում էր որպես մի տեսակ ստանդարտ օպերատորների շրջանում DBMS-ի համար: Սա բավականին հին նախագիծ է. դրա առաջին հրապարակային թողարկումը տեղի է ունեցել դեռևս 2015 թվականի նոյեմբերին(!), և GitHub-ի պահոցն ունի գրեթե 3000 աստղ և 40+ ներդրող:

Իրոք, Ստոլոնը մտածված ճարտարապետության հիանալի օրինակ է.

Այս օպերատորի սարքը մանրամասն կարելի է գտնել զեկույցում կամ նախագծային փաստաթղթեր. Ընդհանրապես, բավական է ասել, որ այն կարող է անել այն ամենը, ինչ նկարագրված է. failover, proxies թափանցիկ հաճախորդի մուտքի համար, backups... Ավելին, վստահվածները ապահովում են մուտք մեկ վերջնական կետի ծառայության միջոցով՝ ի տարբերություն ստորև քննարկված մյուս երկու լուծումների (յուրաքանչյուրն ունի երկու ծառայություն՝ մուտքի բազա):

Այնուամենայնիվ, Ստոլոն ոչ հատուկ ռեսուրսներ, այդ իսկ պատճառով այն չի կարող տեղակայվել այնպես, որ հեշտ և արագ լինի՝ «ինչպես տաք տորթեր»՝ ստեղծել DBMS օրինակներ Kubernetes-ում: Կառավարումն իրականացվում է կոմունալ ծառայության միջոցով stolonctl, տեղակայումը կատարվում է Helm աղյուսակի միջոցով, իսկ մաքսայինները սահմանվում և նշված են ConfigMap-ում:

Մի կողմից պարզվում է, որ օպերատորն իրականում օպերատոր չէ (ի վերջո, նա չի օգտագործում CRD): Բայց մյուս կողմից, դա ճկուն համակարգ է, որը թույլ է տալիս կարգավորել ռեսուրսները K8-ներում այնպես, ինչպես հարմար եք գտնում:

Ամփոփելու համար, անձամբ մեզ համար օպտիմալ չի թվում յուրաքանչյուր տվյալների բազայի համար առանձին գծապատկեր ստեղծելը: Հետեւաբար, մենք սկսեցինք այլընտրանքներ փնտրել։

2. Crunchy Data PostgreSQL օպերատոր

Օպերատոր Crunchy Data-իցԵրիտասարդ ամերիկյան ստարտափը տրամաբանական այլընտրանք էր թվում։ Դրա հանրային պատմությունը սկսվում է 2017 թվականի մարտին առաջին թողարկումից, այդ ժամանակից ի վեր GitHub-ի պահոցը ստացել է 1300-ից քիչ աստղ և 50+ ներդրող: Սեպտեմբերի վերջին թողարկումը փորձարկվել է Kubernetes 1.15-1.18, OpenShift 3.11+ և 4.4+, GKE և VMware Enterprise PKS 1.3+ հետ աշխատելու համար:

Crunchy Data PostgreSQL օպերատորի ճարտարապետությունը նույնպես համապատասխանում է նշված պահանջներին.

Կառավարումը տեղի է ունենում կոմունալ ծառայության միջոցով pgo, սակայն, այն իր հերթին առաջացնում է հատուկ ռեսուրսներ Kubernetes-ի համար։ Հետևաբար, օպերատորը գոհացրեց մեզ որպես պոտենցիալ օգտվողների.

կա վերահսկողություն CRD-ի միջոցով;
օգտագործողի հարմար կառավարում (նաև CRD-ի միջոցով);
ինտեգրում այլ բաղադրիչների հետ Crunchy Data Container Suite — PostgreSQL-ի և դրա հետ աշխատելու համար նախատեսված բեռնարկղերի պատկերների մասնագիտացված հավաքածու (ներառյալ pgBackRest, pgAudit, ընդլայնումներ ներդրումից և այլն):

Այնուամենայնիվ, Crunchy Data-ից օպերատորն օգտագործելու փորձերը բացահայտեցին մի քանի խնդիրներ.

Հանդուրժումների հնարավորություն չկար՝ տրամադրվում է միայն nodeSelector-ը։
Ստեղծված pods-ը Deployment-ի մի մասն էր, չնայած այն հանգամանքին, որ մենք տեղակայեցինք պետական հավելված: Ի տարբերություն StatefulSets-ի, Deployments-ը չի կարող սկավառակներ ստեղծել:

Վերջին թերությունը հանգեցնում է զվարճալի պահերի. թեստային միջավայրում մեզ հաջողվեց մեկ սկավառակով գործարկել 3 կրկնօրինակ: տեղական պահեստավորում, ստիպելով օպերատորին հայտնել, որ 3 կրկնօրինակներ են աշխատում (չնայած դրանք չեն եղել):

Այս օպերատորի մեկ այլ առանձնահատկությունը նրա պատրաստի ինտեգրումն է տարբեր օժանդակ համակարգերի հետ: Օրինակ, հեշտ է տեղադրել pgAdmin և pgBounce, և in փաստաթղթավորում Դիտարկվում են նախապես կազմաձևված Գրաֆանան և Պրոմեթևսը: Վերջերս թողարկել 4.5.0-beta1 Ծրագրի հետ բարելավված ինտեգրումը առանձին նշվում է pgMonitor, որի շնորհիվ օպերատորն առաջարկում է PgSQL չափումների հստակ պատկերացում առանց տուփի:

Այնուամենայնիվ, Kubernetes-ի կողմից ստեղծված ռեսուրսների տարօրինակ ընտրությունը մեզ հանգեցրեց այլ լուծում գտնելու անհրաժեշտությանը:

3. Zalando Postgres օպերատոր

Zalando-ի արտադրանքին մենք վաղուց ենք ճանաչում. Zalenium-ի օգտագործման փորձ ունենք և, իհարկե, փորձել ենք Հովանավոր նրանց հայտնի HA լուծումն է PostgreSQL-ի համար: Ընկերության ստեղծման մոտեցման մասին Postgres օպերատոր եթերում ասել է դրա հեղինակներից մեկը՝ Ալեքսեյ Կլյուկինը Postgres-Երեքշաբթի #5, և մեզ դուր եկավ:

Սա հոդվածում քննարկված ամենաերիտասարդ լուծումն է՝ առաջին թողարկումը տեղի է ունեցել 2018 թվականի օգոստոսին։ Այնուամենայնիվ, չնայած պաշտոնական թողարկումների փոքր քանակին, նախագիծը երկար ճանապարհ է անցել՝ իր ժողովրդականությամբ արդեն գերազանցելով Crunchy Data-ի լուծումը՝ 1300+ աստղերով GitHub-ում և ներդրողների առավելագույն քանակով (70+):

«Կապակի տակ» այս օպերատորն օգտագործում է ժամանակի փորձարկված լուծումներ.

Պատրոնի և Սպիլո Վարելու համար,
ՈւՈԼ-Է - կրկնօրինակումների համար,
PgBouncer - որպես կապի լողավազան:

Ահա թե ինչպես է ներկայացվում Zalando-ից օպերատորի ճարտարապետությունը.

Օպերատորն ամբողջությամբ կառավարվում է Պատվերով ռեսուրսների միջոցով, ավտոմատ կերպով ստեղծում է StatefulSet բեռնարկղերից, որը կարող է այնուհետև հարմարեցվել՝ ավելացնելով տարբեր կողային սայլեր պատիճում: Այս ամենը զգալի առավելություն է Crunchy Data-ի օպերատորի համեմատ։

Քանի որ քննարկվող 3 տարբերակներից մենք ընտրել ենք լուծումը Zalando-ից, դրա հնարավորությունների հետագա նկարագրությունը կներկայացվի ստորև՝ անմիջապես կիրառման պրակտիկային զուգահեռ:

Պրակտիկա Zalando-ից Postgres օպերատորի հետ

Օպերատորի տեղակայումը շատ պարզ է. պարզապես ներբեռնեք ընթացիկ թողարկումը 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 կլաստերների ցանկ

Կրկնօրինակման կառավարում

Մեկ այլ հետաքրքիր առանձնահատկություն աջակցությունն է Teams API. Այս մեխանիզմը ավտոմատ կերպով ստեղծում է դերեր PostgreSQL-ում, հիմնվելով ստացված օգտանունների ցանկի վրա։ Այնուհետև API-ն թույլ է տալիս վերադարձնել այն օգտվողների ցուցակը, որոնց համար ավտոմատ կերպով ստեղծվում են դերեր:

Խնդիրներ և լուծումներ

Այնուամենայնիվ, օպերատորի օգտագործումը շուտով բացահայտեց մի քանի նշանակալի թերություններ.

nodeSelector-ի աջակցության բացակայություն;
կրկնօրինակումներն անջատելու անկարողություն;
տվյալների բազայի ստեղծման գործառույթն օգտագործելիս լռելյայն արտոնությունները չեն հայտնվում.
Երբեմն փաստաթղթերը բացակայում են կամ հնացած են:

Բարեբախտաբար, դրանցից շատերը հնարավոր է լուծել: Սկսենք վերջից՝ խնդիրներ փաստաթղթեր.

Ամենայն հավանականությամբ, դուք կհանդիպեք այն փաստի հետ, որ միշտ չէ, որ պարզ է, թե ինչպես գրանցել կրկնօրինակը և ինչպես միացնել պահեստային դույլը Օպերատորի UI-ին: Փաստաթղթում ասվում է այս մասին, բայց իրական նկարագրությունը կա PR:

պետք է գաղտնիք անել;
փոխանցեք այն օպերատորին որպես պարամետր pod_environment_secret_name օպերատորի կարգավորումներով CRD-ում կամ ConfigMap-ում (կախված նրանից, թե ինչպես եք որոշել տեղադրել օպերատորը):

Սակայն, ինչպես պարզվում է, դա ներկայումս անհնար է։ Դրա համար մենք հավաքեցինք օպերատորի ձեր տարբերակը երրորդ կողմի որոշ լրացուցիչ զարգացումներով: Դրա մասին լրացուցիչ տեղեկությունների համար տե՛ս ստորև:

Եթե դուք օպերատորին փոխանցեք պահուստավորման պարամետրերը, այն է՝ wal_s3_bucket և մուտքի ստեղներ AWS S3-ում, այնուհետև այն ամեն ինչ կրկնօրինակելու էոչ միայն հիմքերը արտադրության մեջ, այլ նաև բեմականացում: Սա մեզ չէր սազում:

Spilo-ի պարամետրերի նկարագրության մեջ, որը օպերատորի օգտագործման ժամանակ PgSQL-ի հիմնական Docker փաթաթումն է, պարզվեց. կարող եք պարամետր փոխանցել: WAL_S3_BUCKET դատարկ, դրանով իսկ անջատելով պահուստավորումը: Ավելին, ի մեծ ուրախություն, ես գտա պատրաստ PR, որը մենք անմիջապես ընդունեցինք մեր պատառաքաղի մեջ: Այժմ դուք պարզապես պետք է ավելացնել enableWALArchiving: false PostgreSQL կլաստերի ռեսուրսին:

Այո, հնարավորություն կար դա անել այլ կերպ՝ գործարկելով 2 օպերատոր՝ մեկը բեմականացման համար (առանց կրկնօրինակների), իսկ երկրորդը՝ արտադրության։ Բայց մենք կարողացանք բավարարվել մեկով:

Լավ, մենք սովորեցինք, թե ինչպես փոխանցել մուտքը տվյալների բազա S3-ի համար, և կրկնօրինակները սկսեցին հայտնվել պահեստում: Ինչպե՞ս ստիպել պահուստային էջերը աշխատել Operator UI-ում:

Դուք պետք է ավելացնեք 3 փոփոխական Օպերատորի UI-ում.

SPILO_S3_BACKUP_BUCKET
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Դրանից հետո հասանելի կդառնա կրկնօրինակների կառավարումը, ինչը մեր դեպքում կհեշտացնի բեմադրման հետ կապված աշխատանքը՝ թույլ տալով մեզ առանց հավելյալ սցենարների արտադրությունից հատվածներ հասցնել այնտեղ։

Մեկ այլ առավելություն էր Teams API-ի հետ աշխատանքը և օպերատորի գործիքների միջոցով տվյալների բազաներ և դերեր ստեղծելու լայն հնարավորություններ: Այնուամենայնիվ, ստեղծված դերերը լռելյայն իրավունք չունեին. Համապատասխանաբար, ընթերցման իրավունք ունեցող օգտվողը չէր կարող կարդալ նոր աղյուսակներ:

Ինչո՞ւ է այդպես։ Չնայած այն հանգամանքին, որ օրենսգրքում կա անհրաժեշտ GRANT, դրանք միշտ չէ, որ օգտագործվում են։ Կան 2 մեթոդ. syncPreparedDatabases и syncDatabases: Մեջ syncPreparedDatabases - չնայած այն հանգամանքին, որ բաժնում preparedDatabases կա կա պայման defaultRoles и defaultUsers դերեր ստեղծելու համար լռելյայն իրավունքները չեն կիրառվում: Մենք կարկատակի պատրաստման գործընթացում ենք, որպեսզի այդ իրավունքները ավտոմատ կերպով կիրառվեն:

Եվ վերջին կետը բարելավումների մեջ, որոնք վերաբերում են մեզ. patch, որն ավելացնում է Node Affinity ստեղծված StatefulSet-ին: Մեր հաճախորդները հաճախ նախընտրում են նվազեցնել ծախսերը՝ օգտագործելով սպոտային օրինակներ, և նրանք ակնհայտորեն չարժեն հյուրընկալել տվյալների բազայի ծառայությունները: Այս հարցը կարող է լուծվել հանդուրժողականության միջոցով, բայց հանգույցի Affinity-ի առկայությունը ավելի մեծ վստահություն է տալիս:

Ինչ է պատահել?

Ելնելով վերը նշված խնդիրների լուծման արդյունքներից՝ մենք ներքաշեցինք Postgres օպերատորին Զալանդոյից ձեր պահոցը, որտեղ հավաքվում է նման օգտակար կարկատաններով։ Իսկ ավելի մեծ հարմարության համար մենք նույնպես հավաքեցինք Դոկերի պատկեր.

Պատառաքաղում ընդունված PR-ների ցանկը.

Հիանալի կլինի, եթե համայնքը աջակցի այս PR-ներին, որպեսզի դրանք անցնեն օպերատորի հաջորդ տարբերակով (1.6):

Բոնուս Արտադրության միգրացիայի հաջող պատմություն

Եթե դուք օգտագործում եք Patroni-ն, կենդանի արտադրությունը կարող է տեղափոխվել օպերատոր՝ նվազագույն ժամանակով:

Spilo-ն թույլ է տալիս ստեղծել սպասման կլաստերներ 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. Replication-ը անջատելուց հետո անհրաժեշտ է ուղղել հաջորդականությունները: Սա լավ նկարագրված է wiki.postgresql.org-ի հոդվածում.

Այս պլանի շնորհիվ անցումը տեղի ունեցավ նվազագույն ուշացումներով։

Ամփոփում

Kubernetes օպերատորները թույլ են տալիս պարզեցնել տարբեր գործողություններ՝ դրանք կրճատելով մինչև K8s ռեսուրսների ստեղծման: Այնուամենայնիվ, նրանց օգնությամբ հասնելով ուշագրավ ավտոմատացման, հարկ է հիշել, որ այն կարող է բերել նաև մի շարք անսպասելի նրբերանգներ, ուստի խելամտորեն ընտրեք ձեր օպերատորներին:

Հաշվի առնելով PostgreSQL-ի երեք ամենահայտնի Kubernetes օպերատորները, մենք ընտրեցինք նախագիծը Zalando-ից: Եվ մենք ստիպված էինք հաղթահարել որոշակի դժվարություններ դրա հետ, բայց արդյունքն իսկապես հաճելի էր, ուստի մենք նախատեսում ենք ընդլայնել այս փորձը որոշ այլ PgSQL տեղադրումների վրա: Եթե ունեք նմանատիպ լուծումներ օգտագործելու փորձ, ուրախ կլինենք մանրամասները տեսնել մեկնաբանություններում:

PS

Կարդացեք նաև մեր բլոգում.

Source: www.habr.com

PostgreSQL հայտարարությունների համառոտ ակնարկ Kubernetes-ի, մեր ընտրությունների և փորձի համար