Шарҳи мухтасари изҳороти PostgreSQL барои Kubernetes, интихобҳо ва таҷрибаи мо

Шарҳи мухтасари изҳороти PostgreSQL барои Kubernetes, интихобҳо ва таҷрибаи мо

Муштариён торафт бештар дархостҳои зерин мегиранд: "Мо онро мисли Amazon RDS мехоҳем, аммо арзонтар"; "Мо онро мисли RDS мехоҳем, аммо дар ҳама ҷо, дар ҳама гуна инфрасохтор." Барои татбиқи чунин як ҳалли идорашаванда дар Kubernetes, мо ба ҳолати кунунии маъмултарин операторони PostgreSQL (Stolon, операторони Crunchy Data ва Zalando) назар кардем ва интихоби худро кардем.

Ин мақола таҷрибаест, ки мо ҳам аз нуқтаи назари назариявӣ (баррасии ҳалли масъалаҳо) ва ҳам аз ҷиҳати амалӣ (чӣ интихоб шуд ва чӣ натиҷа дод) андӯхтаем. Аммо аввал, биёед муайян кунем, ки талаботҳои умумӣ барои иваз кардани эҳтимолии RDS чӣ гунаанд...

RDS чист

Вақте ки одамон дар бораи RDS сӯҳбат мекунанд, дар таҷрибаи мо, онҳо хидмати идорашавандаи DBMS-ро дар назар доранд, ки:

  1. осон ба танзим дароред;
  2. дорои қобилияти кор кардан бо аксҳо ва барқароршавӣ аз онҳо (беҳтараш бо дастгирии ПИТР);
  3. ба шумо имкон медиҳад, ки топологияҳои мастер-ғуломро эҷод кунед;
  4. дорои рӯйхати бойи васеъшавӣ;
  5. аудит ва идоракунии истифодабаранда/дастрасро таъмин менамояд.

Умуман, равишҳо барои иҷрои вазифаи дар пешистода метавонанд хеле гуногун бошанд, аммо роҳ бо шартии Ansible ба мо наздик нест. (Ҳамкорон аз 2GIS дар натиҷа ба чунин хулоса омаданд кӯшиши ӯ эҷод кунед "асбоб барои зуд ҷойгиркунии кластери хато дар асоси Postgres.")

Операторҳо як равиши маъмул барои ҳалли мушкилоти шабеҳ дар экосистемаи Kubernetes мебошанд. Директори техникии "Фланта" аллакай дар бораи онҳо дар бораи пойгоҳи додаҳо дар дохили Кубернетес ба таври муфассал сӯҳбат кардааст. дистолдар дохили яке аз гузоришҳои ӯ.

NB: Барои зуд сохтани операторҳои оддӣ, мо тавсия медиҳем, ки ба утилитаи кушодаасос диққат диҳем оператори снаряд. Бо истифода аз он, шумо метавонед ин корро бидуни дониши Go иҷро кунед, аммо бо тарзе, ки ба маъмурони система бештар шинос аст: дар Bash, Python ва ғайра.

Якчанд операторҳои маъмули K8s барои PostgreSQL мавҷуданд:

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

Биёед онҳоро бодиққат дида бароем.

Интихоби оператор

Илова ба хусусиятҳои муҳими дар боло зикршуда, мо - ҳамчун муҳандисони амалиёти инфрасохтори Kubernetes - инчунин аз операторҳо интизори он будем:

  • ҷойгиркунӣ аз Git ва бо Захираҳои фармоишӣ;
  • дастгирии зидди ҳамбастагӣ;
  • насби наздикии гиреҳ ё селектори гиреҳ;
  • насби таҳаммулпазирӣ;
  • мавҷудияти қобилиятҳои танзим;
  • технологияҳои фаҳмо ва ҳатто фармонҳо.

Бе тафсилоти ҳар як нукта (дар шарҳҳо пурсед, ки оё шумо пас аз хондани тамоми мақола дар бораи онҳо саволҳо доред), ман дар маҷмӯъ қайд мекунам, ки ин параметрҳо барои дақиқтар тавсиф кардани ихтисоси гиреҳҳои кластер лозиманд, то онҳоро барои барномаҳои мушаххас фармоиш диҳед. Бо ин роҳ мо метавонем мувозинати оптималиро дар робита ба кор ва арзиш ба даст орем.

Акнун биёед ба худи операторони PostgreSQL гузарем.

1. Столон

Столон аз ширкати итолиёвии Sorint.lab дар гузориши қаблан зикршуда ҳамчун як навъ стандарт дар байни операторони DBMS ба ҳисоб мерафт. Ин як лоиҳаи хеле кӯҳна аст: аввалин нашри оммавии он дар моҳи ноябри соли 2015 (!) сурат гирифт ва анбори GitHub дорои тақрибан 3000 ситора ва 40+ саҳмгузор аст.

Дар ҳақиқат, Столон як намунаи олии меъмории андешаманд аст:

Шарҳи мухтасари изҳороти PostgreSQL барои Kubernetes, интихобҳо ва таҷрибаи мо
Дастгоҳи ин операторро метавон муфассал дар гузориш ё ҳуҷҷатҳои лоиҳавӣ. Дар маҷмӯъ, гуфтан кифоя аст, ки он метавонад ҳама чизеро, ки тавсиф карда шудааст, иҷро кунад: нокомӣ, проксиҳо барои дастрасии шаффофи муштарӣ, нусхабардорӣ... Гузашта аз ин, проксиҳо дастрасиро тавассути як хидмати ниҳоӣ таъмин мекунанд - бар хилофи ду ҳалли дигари дар поён баррасӣшуда (ҳар кадоми онҳо ду хидмат барои дастрасӣ ба база).

Аммо, Столон захираҳои фармоишӣ нест, аз ин рӯ онро ба тавре ҷойгир кардан мумкин нест, ки осон ва зуд бошад - "ба мисли пирожни гарм" - эҷод кардани мисолҳои DBMS дар Kubernetes. Идоракунӣ тавассути хидматрасонӣ амалӣ карда мешавад stolonctl, ҷойгиркунӣ тавассути диаграммаи Helm анҷом дода мешавад ва шахсони фармоишӣ дар ConfigMap муайян ва муайян карда мешаванд.

Аз як тараф маълум мешавад, ки оператор аслан оператор нест (охир, CRD-ро истифода намебарад). Аммо аз тарафи дигар, он як системаи фасеҳ аст, ки ба шумо имкон медиҳад, ки захираҳоро дар K8s мувофиқи мувофиқ танзим кунед.

Хулоса, барои мо шахсан эҷод кардани диаграммаи алоҳида барои ҳар як базаи маълумот мувофиқ набуд. Аз ин рӯ, мо ба ҷустуҷӯи алтернативаҳо шурӯъ кардем.

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 Оператор инчунин ба талаботи зикршуда ҷавобгӯ аст:

Шарҳи мухтасари изҳороти PostgreSQL барои Kubernetes, интихобҳо ва таҷрибаи мо

Идоракунӣ тавассути хидматрасонӣ сурат мегирад pgo, аммо он дар навбати худ захираҳои фармоиширо барои Kubernetes тавлид мекунад. Аз ин рӯ, оператор моро ҳамчун корбарони эҳтимолӣ шод кард:

  • тавассути CRD назорат вуҷуд дорад;
  • идоракунии қулайи корбар (инчунин тавассути CRD);
  • ҳамгироӣ бо ҷузъҳои дигар Suite Container Data Crunchy — маҷмӯи махсуси тасвирҳои контейнерӣ барои PostgreSQL ва утилитҳо барои кор бо он (аз ҷумла pgBackRest, pgAudit, васеъшавӣ аз саҳм ва ғайра).

Аммо, кӯшиши оғози истифодаи оператор аз Crunchy Data якчанд мушкилотро ошкор кард:

  • Имконияти таҳаммул вуҷуд надошт - танҳо nodeSelector таъмин карда шудааст.
  • Подшоҳҳои сохташуда қисми Ҷойгиркунӣ буданд, сарфи назар аз он ки мо як барномаи давлатиро ҷойгир кардем. Баръакси StatefulSets, Deployments дискҳоро эҷод карда наметавонад.

Камбудии охирин ба лаҳзаҳои хандовар оварда мерасонад: дар муҳити санҷиш мо тавонистем бо як диск 3 репликаро иҷро кунем анбори маҳаллӣ, боиси он мегардад, ки оператор хабар диҳад, ки 3 реплика кор мекунад (ҳарчанд онҳо набуданд).

Хусусияти дигари ин оператор интегратсияи омодаи он бо системаҳои гуногуни ёрирасон мебошад. Масалан, насб кардани pgAdmin ва pgBounce осон аст ва дар хуччатхо Grafana ва Prometheus, ки қаблан танзим карда шудаанд, баррасӣ карда мешаванд. Дар вактхои охир барориши 4.5.0-beta1 Интегратсияи беҳтаршуда бо лоиҳа алоҳида қайд карда мешавад pgMonitor, ба шарофати он, ки оператор визуализатсияи равшани ченакҳои PgSQL-ро аз қуттӣ пешниҳод мекунад.

Бо вуҷуди ин, интихоби аҷиби захираҳои аз ҷониби Кубернетес тавлидшуда моро ба зарурати ёфтани роҳи ҳалли дигар водор кард.

3. Оператори Заландо Постгрес

Мо маҳсулоти Zalando-ро кайҳо боз мешиносем: мо таҷрибаи истифодаи Zalenium дорем ва албатта кӯшиш кардем Патрони ҳалли маъмули HA барои PostgreSQL мебошад. Дар бораи муносибати ширкат ба эҷод Оператори Postgres яке аз муаллифони он Алексей Клюкин дар эфир гуфт Postgres - Сешанбе № 5, ва ба мо маъкул шуд.

Ин ҷавонтарин ҳалли дар мақола муҳокимашуда аст: нашри аввал дар моҳи августи соли 2018 сурат гирифт. Аммо, сарфи назар аз шумораи ками нашрҳои расмӣ, лоиҳа роҳи дурро тай карда, аллакай аз маъруфияти ҳалли Crunchy Data бо 1300+ ситораҳо дар GitHub ва шумораи ҳадди аксар саҳмгузорон (70+) пеш гузашт.

"Дар зери сарпӯш" ин оператор қарорҳои дар вақт санҷидашударо истифода мебарад:

  • Патрони ва Спило Барои ронандагӣ,
  • ВАЛ-Е - барои нусхабардорӣ,
  • PgBouncer - ҳамчун ҳавзи пайвастшавӣ.

Ин аст, ки меъмории оператор аз Заландо пешниҳод карда мешавад:

Шарҳи мухтасари изҳороти PostgreSQL барои Kubernetes, интихобҳо ва таҷрибаи мо

Оператор пурра тавассути Захираҳои фармоишӣ идора карда мешавад, ба таври худкор аз контейнерҳо як StatefulSet эҷод мекунад, ки пас аз он метавонад тавассути илова кардани аробаҳои гуногун ба подкаст танзим карда шавад. Ҳамаи ин дар муқоиса бо оператори Crunchy Data бартарии назаррас аст.

Азбаски мо ҳалли Zalando-ро дар байни 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-оператор-ui. Он бо оператор меояд ва ба шумо имкон медиҳад, ки кластерҳоро эҷод ва нест кунед, инчунин бо нусхаҳои эҳтиётӣ аз ҷониби оператор кор кунед.

Шарҳи мухтасари изҳороти PostgreSQL барои Kubernetes, интихобҳо ва таҷрибаи мо
Рӯйхати кластерҳои PostgreSQL

Шарҳи мухтасари изҳороти PostgreSQL барои Kubernetes, интихобҳо ва таҷрибаи мо
Идоракунии нусхабардорӣ

Хусусияти дигари ҷолиб ин дастгирӣ аст API Teams. Ин механизм ба таври худкор эҷод мекунад нақшҳо дар PostgreSQL, дар асоси рӯйхати натиҷавии номҳои корбарӣ. Пас API ба шумо имкон медиҳад, ки рӯйхати корбаронеро баргардонед, ки барои онҳо нақшҳо ба таври худкор сохта мешаванд.

Проблемаҳо ва роҳҳои ҳалли онҳо

Бо вуҷуди ин, истифодаи оператор ба зудӣ якчанд камбудиҳои назаррасро ошкор кард:

  1. набудани дастгирии nodeSelector;
  2. имконнопазирии хомӯш кардани нусхаҳои эҳтиётӣ;
  3. ҳангоми истифодаи функсияи эҷоди пойгоҳи додаҳо, имтиёзҳои пешфарз пайдо намешаванд;
  4. Баъзан ҳуҷҷатҳо намерасанд ё кӯҳна мешаванд.

Хушбахтона, бисёре аз онҳоро метавон ҳал кард. Биёед аз охири оғоз - мушкилот бо ҳуҷҷатгузорӣ.

Эҳтимол, шумо бо он вохӯред, ки на ҳама вақт маълум аст, ки чӣ гуна сабт кардани нусхаи эҳтиётӣ ва чӣ гуна пайваст кардани сатили эҳтиётӣ ба UI Operator UI. Ҳуҷҷатҳо дар ин бора сухан мегӯянд, аммо тавсифи воқеӣ дар он аст PR:

  1. сирр кардан лозим аст;
  2. онро ҳамчун параметр ба оператор интиқол диҳед pod_environment_secret_name дар CRD бо танзимоти оператор ё дар ConfigMap (вобаста ба он, ки чӣ тавр шумо операторро насб мекунед).

Аммо, чунон ки маълум мешавад, ин дар айни замон имконнопазир аст. Барои ҳамин ҷамъ кардем версияи оператори шумо бо баъзе пешрафтҳои иловагии тарафи сеюм. Барои маълумоти бештар дар бораи он, ба поён нигаред.

Агар шумо параметрҳоро барои нусхабардорӣ ба оператор интиқол диҳед, яъне - wal_s3_bucket ва калидҳои дастрасӣ дар AWS S3, пас аз он ҳама чизро захира мекунад: на танхо дар истехсолот, балки ба сахна гузошта шудааст. Ин ба мо мувофиқ набуд.

Дар тавсифи параметрҳо барои Spilo, ки бастаи асосии Docker барои PgSQL ҳангоми истифодаи оператор маълум шуд: шумо метавонед як параметрро гузаронед WAL_S3_BUCKET холӣ, ба ин васила нусхаҳои эҳтиётиро ғайрифаъол мекунад. Гузашта аз ин, ба хурсандии бузург, ман пайдо кардам PR тайёр, ки мо дархол ба форигболй кабул кардем. Ҳоло шумо танҳо бояд илова кунед enableWALArchiving: false ба манбаи кластери PostgreSQL.

Бале, имкон дошт, ки ин корро ба таври дигар тавассути кор кардани 2 оператор: яке барои саҳнасозӣ (бе нусхаҳои эҳтиётӣ) ва дуюмӣ барои истеҳсолот. Аммо мо тавонистем, ки бо як чиз кор кунем.

Хуб, мо фаҳмидем, ки чӣ гуна дастрасӣ ба пойгоҳи додаҳо барои S3 интиқол дода мешавад ва нусхаҳои эҳтиётӣ ба анбор дохил шуданро оғоз карданд. Чӣ тавр саҳифаҳои эҳтиётиро дар Operator UI кор кардан мумкин аст?

Шарҳи мухтасари изҳороти PostgreSQL барои Kubernetes, интихобҳо ва таҷрибаи мо

Шумо бояд 3 тағирёбандаро ба интерфейси UI оператор илова кунед:

  • SPILO_S3_BACKUP_BUCKET
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

Пас аз ин, идоракунии нусхаҳои эҳтиётӣ дастрас мешавад, ки дар ҳолати мо корро бо саҳнасозӣ содда мекунад ва ба мо имкон медиҳад, ки буридаҳоро аз истеҳсолот бе скриптҳои иловагӣ ба он ҷо расонем.

Бартарии дигар ин кор бо API Teams ва имкониятҳои васеъ барои эҷоди пойгоҳи додаҳо ва нақшҳо бо истифода аз абзорҳои оператор буд. Бо вуҷуди ин, офаридашуда нақшҳо ба таври пешфарз ҳуқуқ надоштанд. Мутаносибан, корбаре, ки ҳуқуқи хондан дорад, ҷадвалҳои навро хонда наметавонад.

Барои чӣ ин? Сарфи назар аз он ки дар кодекс аст зарурӣ GRANT, на хамеша истифода мебаранд. 2 усул вуҷуд дорад: syncPreparedDatabases и syncDatabases. Дар syncPreparedDatabases — сарфи назар аз он ки дар секция preparedDatabases аст шарт ҳаст defaultRoles и defaultUsers барои сохтани нақшҳо, ҳуқуқҳои пешфарз истифода намешаванд. Мо дар ҷараёни омода кардани ямоқ ҳастем, то ин ҳуқуқҳо ба таври худкор татбиқ карда шаванд.

Ва нуқтаи охирини беҳбудиҳо, ки ба мо дахл доранд - часпондан, ки Аффинии гиреҳро ба StatefulSet-и сохташуда илова мекунад. Мизоҷони мо аксар вақт бартарӣ медиҳанд, ки хароҷотро бо истифода аз инстансияҳои спотӣ кам кунанд ва онҳо бешубҳа барои мизбони хидматҳои пойгоҳи додаҳо арзиш надоранд. Ин масъаларо метавон тавассути таҳаммул ҳал кард, аммо мавҷудияти Node Affinity эътимоди бештар медиҳад.

Чӣ шуд?

Дар асоси натиҷаҳои ҳалли мушкилоти дар боло зикршуда, мо Оператори Postgres-ро аз Заландо ба кор бурдем анбори шумо, ки он бо чунин часпакхои фоиданок чамъ карда мешавад. Ва барои роҳати бештар, мо низ ҷамъоварӣ кардем Тасвири Docker.

Рӯйхати PR-ҳои ба форк қабулшуда:

Хеле хуб хоҳад буд, агар ҷомеа ин 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 содда кунед. Бо вуҷуди ин, бо ёрии онҳо автоматикунонии назаррас ба даст оварда, бояд дар хотир дошт, ки он метавонад як қатор нозукиҳои ғайричашмдоштро ба бор орад, аз ин рӯ операторони худро оқилона интихоб кунед.

Се оператори машҳуртарини Kubernetes барои PostgreSQL-ро баррасӣ карда, мо лоиҳаро аз Zalando интихоб кардем. Ва мо маҷбур шудем, ки бо он душвориҳои муайянро паси сар кунем, аммо натиҷа воқеан писанд омад, аз ин рӯ мо нақша дорем, ки ин таҷрибаро ба баъзе насбҳои дигари PgSQL васеъ кунем. Агар шумо таҷрибаи истифодаи ҳалли шабеҳ дошта бошед, мо аз дидани тафсилот дар шарҳҳо шод хоҳем шуд!

PS

Инчунин дар блоги мо хонед:

Манбаъ: will.com

Илова Эзоҳ