Kubernetes-д зориулсан PostgreSQL мэдэгдлийн товч тойм, бидний сонголт, туршлага

Үйлчлүүлэгчид дараах хүсэлтийг хүлээн авах нь нэмэгдэж байна: "Бид үүнийг Amazon RDS шиг хүсч байна, гэхдээ хямд байна"; "Бид үүнийг RDS шиг хүсч байна, гэхдээ хаа сайгүй, ямар ч дэд бүтцэд." Kubernetes дээр ийм менежменттэй шийдлийг хэрэгжүүлэхийн тулд бид PostgreSQL-ийн хамгийн алдартай операторуудын (Stolon, Crunchy Data болон Zalando-ийн операторууд) өнөөгийн байдлыг харж, сонголтоо хийсэн.

Энэ нийтлэл бол онолын үүднээс (шийдлийн тойм) болон практик талаас (юуг сонгосон, үүнээс юу гарсан) олж авсан туршлага юм. Гэхдээ эхлээд RDS-ийг орлуулах ерөнхий шаардлага юу болохыг тодорхойлъё...

RDS гэж юу вэ

Хүмүүс RDS-ийн талаар ярихдаа, бидний туршлагаас харахад тэд удирддаг DBMS үйлчилгээг хэлдэг:

1. тохируулахад хялбар;
2. агшин зуурын зурагтай ажиллах, тэдгээрээс сэргээх чадвартай (дэмжлэгтэй байвал илүү тохиромжтой PITR);
3. мастер-боол топологи үүсгэх боломжийг танд олгоно;
4. өргөтгөлүүдийн баялаг жагсаалттай;
5. аудит болон хэрэглэгчийн/хүрэлтийн удирдлагыг хангадаг.

Ерөнхийдөө, даалгавраа хэрэгжүүлэх арга барил нь маш өөр байж болох ч нөхцөлт Ansible-тэй зам нь бидэнд ойр биш юм. (Үүний үр дүнд 2GIS-ийн хамт олон ижил төстэй дүгнэлтэд хүрсэн түүний оролдлого "Postgres-д суурилсан бүтэлгүйтлийн кластерийг хурдан байрлуулах хэрэгсэл" үүсгэ.)

Операторууд нь Кубернетес экосистемийн ижил төстэй асуудлыг шийдвэрлэх нийтлэг арга юм. "Фланта"-ын техникийн захирал Кубернетес дотор эхлүүлсэн мэдээллийн сангийн талаар тэдний талаар илүү дэлгэрэнгүй ярьсан. distol, in түүний тайлангийн нэг.

NB: Энгийн операторуудыг хурдан үүсгэхийн тулд манай Нээлттэй эхийн хэрэгсэлд анхаарлаа хандуулахыг зөвлөж байна бүрхүүлийн оператор. Үүнийг ашигласнаар та Go-ийн талаар мэдлэггүйгээр үүнийг хийж болно, гэхдээ системийн администраторуудад илүү танил болсон аргууд: Bash, Python гэх мэт.

PostgreSQL-д зориулсан хэд хэдэн алдартай K8s операторууд байдаг:

• Столон;
• Crunchy Data PostgreSQL оператор;
• Zalando Postgres оператор.

Тэднийг илүү нарийвчлан авч үзье.

Операторын сонголт

Дээр дурдсан чухал шинж чанаруудаас гадна бид Кубернетес дэд бүтцийн үйл ажиллагааны инженерүүдийн хувьд операторуудаас дараахь зүйлийг хүлээж байсан.

• Git болон with-ээс байршуулах Захиалгат нөөц;
• pod anti-affinity дэмжлэг;
• зангилааны хамаарал эсвэл зангилаа сонгогчийг суулгах;
• хүлцлийг суурилуулах;
• тааруулах чадварын хүртээмж;
• ойлгомжтой технологи, тэр ч байтугай тушаалууд.

Санал тус бүрийн талаар дэлгэрэнгүй мэдээлэл өгөхгүйгээр (нийтлэлийг бүхэлд нь уншсаны дараа танд асуулт байгаа бол тайлбараас асуугаарай) эдгээр параметрүүд нь кластер зангилааны мэргэшлийг илүү нарийвчлалтай тодорхойлоход шаардлагатай гэдгийг би ерөнхийд нь тэмдэглэх болно. тодорхой хэрэглээнд зориулж тэдгээрийг захиалах. Ингэснээр бид гүйцэтгэл, зардлын хувьд оновчтой тэнцвэрт байдалд хүрч чадна.

Одоо PostgreSQL операторууд руу шилжье.

1. Столон

Столон Италийн Sorint.lab компаниас аль хэдийн дурдсан тайлан нь DBMS-ийн операторуудын дунд нэг төрлийн стандарт гэж тооцогддог. Энэ бол нэлээд хуучирсан төсөл: анхны олон нийтэд 2015 оны 3000-р сард гарсан(!) бөгөөд GitHub репозитор нь бараг 40 одтой, XNUMX гаруй хувь нэмэр оруулагчтай.

Үнэн хэрэгтээ, Столон бол сэтгэлгээтэй архитектурын гайхалтай жишээ юм.

Энэ операторын төхөөрөмжийг тайлангаас дэлгэрэнгүй үзэх боломжтой төслийн баримт бичиг. Ерөнхийдөө, энэ нь тайлбарласан бүх зүйлийг хийж чадна гэж хэлэхэд хангалттай: бүтэлгүйтэл, үйлчлүүлэгчийн ил тод хандалтад зориулсан прокси, нөөцлөлт ... Түүгээр ч зогсохгүй прокси нь доор авч үзсэн бусад хоёр шийдлээс ялгаатай нь нэг төгсгөлийн үйлчилгээгээр дамжуулан хандалтыг хангадаг (тэд тус бүр нь хоёр үйлчилгээтэй байдаг. суурь руу нэвтрэх).

Гэсэн хэдий ч Столон захиалгат нөөц байхгүй, ийм учраас үүнийг Kubernetes-д DBMS instances үүсгэхэд хялбар бөгөөд хурдан "халуун бялуу шиг" байдлаар байрлуулах боломжгүй юм. Удирдлага нь хэрэглүүрээр дамждаг stolonctl, байршуулалт нь Helm диаграмаар хийгддэг бөгөөд захиалгатуудыг ConfigMap-д тодорхойлж, зааж өгдөг.

Нэг талаас, энэ нь оператор нь үнэхээр оператор биш болох нь харагдаж байна (эцсийн эцэст энэ нь CRD ашигладаггүй). Гэхдээ нөгөө талаас, энэ нь K8-ийн нөөцийг өөрийн үзэмжээр тохируулах боломжийг олгодог уян хатан систем юм.

Дүгнэж хэлэхэд, бидний хувьд мэдээллийн сан бүрийн хувьд тусдаа диаграмм үүсгэх нь оновчтой биш юм шиг санагдаж байна. Тиймээс бид өөр хувилбаруудыг хайж эхэлсэн.

2. Crunchy Data PostgreSQL Operator

Crunchy Data компанийн оператор, Америкийн залуу стартап нь логик хувилбар мэт санагдсан. Нийтийн түүх нь 2017 оны 1300-р сард гарсан анхны хувилбараас эхэлсэн бөгөөд тэр цагаас хойш GitHub репозитор 50 гаруй одтой, 1.15 гаруй хувь нэмэр оруулагчдыг хүлээн авсан байна. Есдүгээр сард гарсан хамгийн сүүлийн хувилбарыг Kubernetes 1.18-3.11, OpenShift 4.4+ ба 1.3+, GKE болон VMware Enterprise PKS XNUMX+ хувилбаруудтай ажиллахаар туршиж үзсэн.

Crunchy Data PostgreSQL Operator-ийн архитектур нь мөн заасан шаардлагыг хангаж байна.

Удирдлага нь хэрэгслээр дамждаг pgo, гэхдээ энэ нь эргээд Kubernetes-д зориулсан захиалгат нөөцийг бий болгодог. Тиймээс оператор биднийг боломжит хэрэглэгчдийн хувьд баярлуулсан.

• CRD-ээр дамжуулан хяналт байдаг;
• хэрэглэгчийн тохиромжтой удирдлага (мөн CRD-ээр);
• бусад бүрэлдэхүүн хэсгүүдтэй нэгтгэх Crunchy Data Container Suite — PostgreSQL-д зориулсан контейнер зургийн тусгай цуглуулга ба түүнтэй ажиллах хэрэгслүүд (үүнд pgBackRest, pgAudit, хувь нэмэр оруулах өргөтгөлүүд гэх мэт).

Гэсэн хэдий ч Crunchy Data-аас операторыг ашиглаж эхлэх оролдлого нь хэд хэдэн асуудлыг илрүүлсэн.

• Тэвчих боломж байхгүй байсан - зөвхөн nodeSelector-ийг өгсөн.
• Бид төлөвтэй аппликейшн байршуулсан ч үүсгэсэн подкууд нь Байршуулахын нэг хэсэг байсан. StatefulSets-ээс ялгаатай нь Deployment нь диск үүсгэх боломжгүй.

Сүүлийн сул тал нь инээдтэй мөчүүдэд хүргэдэг: туршилтын орчинд бид нэг дискээр 3 хуулбарыг ажиллуулж чадсан. орон нутгийн агуулах, оператор 3 хуулбар ажиллаж байна гэж мэдээлэхэд хүргэсэн (хэдийгээр тэдгээр нь ажиллаагүй байсан ч).

Энэ операторын өөр нэг онцлог нь янз бүрийн туслах системтэй бэлэн нэгтгэх явдал юм. Жишээ нь, pgAdmin болон pgBounce-г суулгахад хялбар байдаг баримт бичиг Урьдчилан тохируулсан Графана ба Прометейг авч үзнэ. Саяхан 4.5.0-бета1 хувилбар Төсөлтэй интеграцчлал сайжирсныг тус тусад нь тэмдэглэв pgMonitor, үүний ачаар оператор хайрцагнаас нь PgSQL хэмжигдэхүүнүүдийн тодорхой дүрслэлийг санал болгодог.

Гэсэн хэдий ч Kubernetes-ийн үүсгэсэн нөөцийн хачирхалтай сонголт нь биднийг өөр шийдэл хайх хэрэгцээнд хүргэсэн.

3. Zalando Postgres оператор

Бид Zalando-ийн бүтээгдэхүүнийг удаан хугацааны турш мэддэг: бид Zalenium-ийг ашигласан туршлагатай бөгөөд мэдээжийн хэрэг туршиж үзсэн Патрони нь PostgreSQL-д зориулсан тэдний алдартай HA шийдэл юм. Компанийн бий болгох арга барилын талаар Postgres оператор түүний зохиогчдын нэг Алексей Клюкин эфирт хэлэв Postgres-Мягмар гараг №5, мөн бидэнд таалагдсан.

Энэ бол нийтлэлд хэлэлцсэн хамгийн залуу шийдэл юм: анхны хувилбар нь 2018 оны 1300-р сард гарсан. Гэсэн хэдий ч цөөн тооны албан ёсны хувилбаруудыг үл харгалзан төсөл нь GitHub дээрх 70+ одтой, хамгийн их хувь нэмэр оруулагчдын тоо (XNUMX+) бүхий Crunchy Data-ийн шийдлийг алдар нэрээрээ аль хэдийн давж, урт замыг туулсан.

"Бүтэн дор" энэ оператор нь цаг хугацаагаар туршсан шийдлүүдийг ашигладаг.

• Патрони ба Spilo Жолооны хувьд,
• WAL-E - нөөцлөхөд,
• PgBouncer - холболтын усан сан болгон.

Заландогийн операторын архитектурыг ингэж үзүүлэв.

Оператор нь Custom Resources-ээр дамжуулан бүрэн удирддаг бөгөөд контейнеруудаас StatefulSet-ийг автоматаар үүсгэдэг бөгөөд дараа нь подонд янз бүрийн хажуугийн тэрэг нэмж тохируулах боломжтой. Энэ бүхэн нь Crunchy Data-ын оператортой харьцуулахад мэдэгдэхүйц давуу тал юм.

Бид хэлэлцэж буй 3 хувилбарын дотроос Заландогийн шийдлийг сонгосон тул түүний чадавхийн талаарх дэлгэрэнгүй тайлбарыг хэрэглээний практикийн хамт дор даруй танилцуулах болно.

Заландогийн Postgres оператортой дадлага хий

Операторыг байршуулах нь маш энгийн: GitHub-аас одоогийн хувилбарыг татаж аваад лавлахаас YAML файлуудыг хэрэглээрэй. илэрдэг. Эсвэл та бас ашиглаж болно operatorhub.

Суулгасны дараа та тохируулах талаар санаа зовох хэрэгтэй бүртгэл болон нөөцлөлтийг хадгалах сан. Үүнийг 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 нь үүрэг нь автоматаар үүсгэгдсэн хэрэглэгчдийн жагсаалтыг буцаах боломжийг танд олгоно.

Асуудлууд ба тэдгээрийн шийдэл

Гэсэн хэдий ч операторыг ашигласнаар удалгүй хэд хэдэн чухал дутагдал илэрсэн.

1. nodeSelector дэмжлэг байхгүй;
2. нөөцлөлтийг идэвхгүй болгох боломжгүй;
3. мэдээллийн сан үүсгэх функцийг ашиглах үед анхдагч эрхүүд гарч ирэхгүй;
4. Заримдаа баримт бичиг дутуу эсвэл хуучирсан байдаг.

Аз болоход тэдгээрийн олонх нь шийдэгдэх боломжтой. Асуудлыг төгсгөлөөс нь эхэлцгээе баримт бичиг.

Нөөцлөлтийг хэрхэн бүртгэх, нөөц хувиныг Operator UI-д хэрхэн холбох нь үргэлж тодорхойгүй байдагтай тулгарах магадлалтай. Баримт бичигт энэ тухай өгүүлсэн боловч бодит тайлбар нь энд байна PR:

1. нууц хийх шаардлагатай;
2. параметр болгон оператор руу дамжуулна pod_environment_secret_name операторын тохиргоотой CRD эсвэл ConfigMap (операторыг хэрхэн суулгахаар шийдсэнээс хамаарна).

Гэсэн хэдий ч энэ нь одоогоор боломжгүй зүйл юм. Тийм учраас бид цуглуулсан таны операторын хувилбар нэмэлт гуравдагч этгээдийн хөгжүүлэлтийн хамт. Энэ талаар дэлгэрэнгүй мэдээллийг доороос үзнэ үү.

Хэрэв та нөөцлөх параметрүүдийг оператор руу дамжуулбал, тухайлбал - wal_s3_bucket болон AWS S3 дахь хандалтын түлхүүрүүд, дараа нь энэ бүгдийг нөөцлөх болно: зөвхөн үйлдвэрлэлийн бааз биш, бас найруулга. Энэ нь бидэнд тохирохгүй байсан.

Операторыг ашиглах үед PgSQL-ийн үндсэн Docker-ийн боодол болох Spilo-ийн параметрүүдийн тайлбарт: та параметрийг дамжуулж болно. WAL_S3_BUCKET хоосон, ингэснээр нөөцлөлтийг идэвхгүй болгоно. Түүнээс гадна би маш их баярласан бэлэн PR, бид тэр даруй бидний сэрээ рүү хүлээн зөвшөөрсөн. Одоо та зүгээр л нэмэх хэрэгтэй enableWALArchiving: false PostgreSQL кластерийн нөөц рүү.

Тийм ээ, 2 операторыг ажиллуулснаар үүнийг өөрөөр хийх боломж байсан: нэг нь үе шатанд (нөөцлөлтгүй), хоёр дахь нь үйлдвэрлэлд зориулагдсан. Гэхдээ бид нэгийг нь хийж чадсан.

За, бид S3-ийн мэдээллийн сан руу нэвтрэх эрхийг хэрхэн шилжүүлэхийг сурч, нөөцлөлтүүд нь хадгалах сан руу орж эхлэв. Operator UI дээр нөөц хуудсуудыг хэрхэн ажиллуулах вэ?

Та Operator UI-д 3 хувьсагч нэмэх шаардлагатай:

• SPILO_S3_BACKUP_BUCKET
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

Үүний дараа нөөцлөлтийн менежмент боломжтой болох бөгөөд энэ нь манай тохиолдолд үе шаттай ажлыг хялбарчилж, нэмэлт скриптгүйгээр үйлдвэрлэлээс зүсмэлүүдийг хүргэх боломжийг бидэнд олгоно.

Өөр нэг давуу тал нь Teams API-тай ажиллах, операторын хэрэгслийг ашиглан мэдээллийн сан, үүрэг үүсгэх өргөн боломжууд байв. Гэсэн хэдий ч бий болгосон дүрүүд анхдагчаар ямар ч эрхгүй байсан. Үүний дагуу унших эрхтэй хэрэглэгч шинэ хүснэгтүүдийг уншиж чадахгүй байна.

Яагаад тэр вэ? Хэдийгээр кодонд байгаа ч гэсэн байна шаардлагатай GRANT, тэдгээрийг үргэлж ашигладаггүй. 2 арга байдаг: syncPreparedDatabases и syncDatabases. The syncPreparedDatabases - хэсэгт байгаа хэдий ч preparedDatabases байна нөхцөл бий defaultRoles и defaultUsers үүрэг үүсгэхийн тулд өгөгдмөл эрхийг ашиглахгүй. Бид эдгээр эрхийг автоматаар ашиглах нөхөөсийг бэлдэж байна.

Мөн бидэнтэй холбоотой сайжруулалтын сүүлийн цэг - нөхөөс, энэ нь үүсгэсэн StatefulSet-д Node Affinity-ийг нэмдэг. Манай үйлчлүүлэгчид ихэвчлэн спот тохиолдлуудыг ашиглан зардлыг бууруулахыг илүүд үздэг бөгөөд мэдээллийн сангийн үйлчилгээг байршуулах нь үнэ цэнэтэй зүйл биш юм. Энэ асуудлыг хүлцэх замаар шийдэж болох боловч Node Affinity байгаа нь илүү их итгэлийг өгдөг.

Юу болсон бэ?

Дээрх асуудлуудыг шийдсэний үр дүнд үндэслэн бид Postgres Operator-ийг Заландогаас салаав таны хадгалах газар, ийм ашигтай нөхөөсүүдээр цуглуулдаг газар. Мөн илүү тохиромжтой байхын тулд бид бас цуглуулсан Докерын зураг.

Хүлээн зөвшөөрөгдсөн PR-ийн жагсаалт:

• Docker дахь операторын аюулгүй хөнгөн дүрсийг бүтээх;
• нөөцлөлтийг идэвхгүй болгох;
• k8s-ийн одоогийн хувилбаруудын нөөцийн хувилбаруудыг шинэчлэх;
• Node Affinity-ийн хэрэгжилт.

Нийгэмлэг эдгээр PR-г дэмжиж, операторын дараагийн хувилбар (1.6) дээр гарах бол үнэхээр сайхан байх болно.

Бонус! Үйлдвэрлэлийн шилжилтийн амжилтын түүх

Хэрэв та Patroni ашигладаг бол хамгийн бага зогсолттойгоор шууд үйлдвэрлэлийг оператор руу шилжүүлж болно.

Spilo нь S3 хадгалалтаар дамжуулан зогсолтын кластер үүсгэх боломжийг олгодог Уол-Э, 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 дээрх нийтлэлд.

Энэхүү төлөвлөгөөний ачаар шилжүүлэг хамгийн бага сааталтайгаар хийгдсэн.

дүгнэлт

Kubernetes операторууд нь K8s нөөцийг бий болгох хүртэл янз бүрийн үйлдлүүдийг багасгах замаар хялбаршуулах боломжийг танд олгоно. Гэсэн хэдий ч тэдний тусламжтайгаар гайхалтай автоматжуулалтыг олж авснаар энэ нь олон тооны гэнэтийн нюансуудыг авчирч чадна гэдгийг санах нь зүйтэй бөгөөд ингэснээр операторуудаа ухаалгаар сонгох хэрэгтэй.

PostgreSQL-ийн хамгийн алдартай гурван Kubernetes операторыг авч үзээд бид Заландогийн төслийг сонгосон. Үүний тулд бид тодорхой бэрхшээлийг даван туулах шаардлагатай байсан ч үр дүн нь үнэхээр тааламжтай байсан тул бид энэ туршлагыг бусад PgSQL суулгацуудад өргөжүүлэхээр төлөвлөж байна. Хэрэв та ижил төстэй шийдлүүдийг ашиглаж байсан туршлагатай бол бид тайлбар дээр дэлгэрэнгүй мэдээллийг үзэхэд таатай байх болно!

PS

Мөн манай блог дээрээс уншина уу:

• «Өгөгдлийн сан ба Кубернетес (хяналт, видео тайлан)";
• «Postgres Мягмар №5: PostgreSQL болон Kubernetes. CI/CD. Туршилтын автоматжуулалт";
• «K8s дээрх Redis оператортой хийсэн нэг түүх, энэ мэдээллийн сангаас өгөгдөлд дүн шинжилгээ хийх хэрэгслүүдийн талаархи бяцхан тойм.".

Эх сурвалж: www.habr.com