پرو هوسٽر > بلاگ > انتظاميه > ڪبرنيٽس لاءِ PostgreSQL بيانن جو هڪ مختصر جائزو، اسان جون چونڊون ۽ تجربو

ڪبرنيٽس لاءِ PostgreSQL بيانن جو هڪ مختصر جائزو، اسان جون چونڊون ۽ تجربو

ڪبرنيٽس لاءِ PostgreSQL بيانن جو هڪ مختصر جائزو، اسان جون چونڊون ۽ تجربو

وڌ ۾ وڌ، گراهڪ هيٺ ڏنل درخواستون حاصل ڪري رهيا آهن: "اسان چاهيون ٿا اهو Amazon RDS وانگر، پر سستا"؛ "اسان چاهيون ٿا اهو آر ڊي ايس وانگر، پر هر جڳهه، ڪنهن به انفراسٽرڪچر ۾." Kubernetes تي اهڙي منظم حل کي لاڳو ڪرڻ لاءِ، اسان PostgreSQL (Stolon، Crunchy Data ۽ Zalando کان آپريٽرز) جي مقبول ترين آپريٽرن جي موجوده حالت کي ڏٺو ۽ اسان جي چونڊ ڪئي.

هي آرٽيڪل اهو تجربو آهي جيڪو اسان حاصل ڪيو آهي ٻنهي نظرياتي نقطي نظر (حل جو جائزو) ۽ عملي پاسي کان (ڇا چونڊيو ويو ۽ ڇا آيو). پر پهرين، اچو ته اهو طئي ڪريون ته آر ڊي ايس جي امڪاني متبادل لاءِ ڪهڙيون عام ضرورتون آهن...

RDS ڇا آهي؟

جڏهن ماڻهو RDS بابت ڳالهائي رهيا آهن، اسان جي تجربي ۾، انهن جو مطلب هڪ منظم ڊي بي ايم ايس سروس آهي ته:

  1. ترتيب ڏيڻ آسان؛
  2. سنيپ شاٽ سان ڪم ڪرڻ جي صلاحيت رکي ٿو ۽ انهن مان ٻيهر حاصل ڪري سگھي ٿو (ترجيح سان سپورٽ سان پي ٽي آر);
  3. توهان کي ماسٽر-غلام ٽوپولوجيز ٺاهڻ جي اجازت ڏئي ٿي؛
  4. ايڪسٽينشن جي هڪ امير فهرست آهي؛
  5. آڊيٽنگ ۽ صارف / رسائي جو انتظام مهيا ڪري ٿو.

عام طور تي ڳالهائڻ، هٿ تي ڪم تي عمل ڪرڻ لاء طريقا تمام مختلف ٿي سگهن ٿا، پر مشروط جواب ڏيڻ وارو رستو اسان جي ويجهو ناهي. (2GIS جي ساٿين جي نتيجي ۾ ساڳئي نتيجي تي آيا هن جي ڪوشش ٺاهيو "جلدي ترتيب ڏيڻ لاءِ هڪ اوزار پوسٽ گريس تي ٻڌل ناڪامي ڪلستر.")

آپريٽرز Kubernetes ماحولياتي نظام ۾ ساڳي مسئلن کي حل ڪرڻ لاء هڪ عام طريقو آهي. "Flanta" جي ٽيڪنيڪل ڊائريڪٽر اڳ ۾ ئي ڪبرنيٽس اندر شروع ڪيل ڊيٽابيس جي سلسلي ۾ انهن بابت وڌيڪ تفصيل سان ڳالهايو آهي. ڊسٽول۾ هن جي رپورٽن مان هڪ.

NB: تڪڙو آسان آپريٽرز ٺاهڻ لاءِ، اسان سفارش ڪريون ٿا ته اسان جي اوپن سورس افاديت تي ڌيان ڏيو شيل آپريٽر. ان کي استعمال ڪندي، توهان اهو ڪري سگهو ٿا بغير ڄاڻ جي Go، پر طريقن سان وڌيڪ واقف سسٽم منتظمين کي: بش، پٿون، وغيره ۾.

PostgreSQL لاءِ ڪيترائي مشهور K8s آپريٽر آهن:

  • اسٽولون؛
  • Crunchy Data PostgreSQL آپريٽر؛
  • Zalando Postgres آپريٽر.

اچو ته انهن کي وڌيڪ ويجهي نظر رکون.

آپريٽر جي چونڊ

مٿي ذڪر ڪيل اهم خصوصيتن کان علاوه، اسان - ڪبرنيٽس انفراسٽرڪچر آپريشن انجنيئرز - پڻ آپريٽرز کان هيٺين جي توقع ڪئي:

  • Git ۽ ان سان گڏ ڪسٽم وسيلن;
  • پوڊ مخالف لاڳاپن جي حمايت؛
  • انسٽال ڪرڻ نوڊ لاڳاپو يا نوڊ چونڊيندڙ؛
  • رواداري جي تنصيب؛
  • ترتيب ڏيڻ جي صلاحيتن جي دستيابي؛
  • سمجھڻ وارا ٽيڪنالاجيون ۽ حتي حڪم.

هر هڪ نقطي تي تفصيل ۾ وڃڻ کان سواءِ (تبصرن ۾ پڇو جيڪڏهن توهان وٽ مڪمل مضمون پڙهڻ کان پوءِ به انهن بابت سوال آهن)، مان عام طور تي نوٽ ڪندس ته اهي پيرا ميٽرز ڪلسٽر نوڊس جي اسپيشلائيزيشن کي وڌيڪ صحيح نموني بيان ڪرڻ لاءِ گهربل آهن. انهن کي مخصوص ايپليڪيشنن لاء ترتيب ڏيو. انهي طريقي سان اسان ڪارڪردگي ۽ قيمت جي لحاظ کان بهتر توازن حاصل ڪري سگهون ٿا.

هاڻي اچو ته اڳتي وڌون PostgreSQL آپريٽرز پاڻ ڏانهن.

1. اسٽولون

اسٽولون اطالوي ڪمپني Sorint.lab کان اڳ ۾ ئي ذڪر ڪيل رپورٽ DBMS لاء آپريٽرز جي وچ ۾ معيار جو هڪ قسم سمجهيو ويندو هو. اھو ھڪڙو پراڻو منصوبو آھي: ان جو پھريون عوامي رليز نومبر 2015 ۾ واپس ٿيو (!)، ۽ GitHub مخزن تقريباً 3000 ستارن ۽ 40 کان وڌيڪ مددگارن تي فخر ڪري ٿو.

درحقيقت، اسٽولون فڪري فن تعمير جو هڪ بهترين مثال آهي:

ڪبرنيٽس لاءِ PostgreSQL بيانن جو هڪ مختصر جائزو، اسان جون چونڊون ۽ تجربو
هن آپريٽر جي ڊوائس تفصيل ۾ ملي ڪري سگهجي ٿو رپورٽ ۾ يا پروجيڪٽ دستاويز. عام طور تي، اهو چوڻ ڪافي آهي ته اهو بيان ڪيل سڀ ڪجهه ڪري سگهي ٿو: ناڪامي، شفاف ڪلائنٽ جي رسائي لاءِ پراڪسز، بيڪ اپ... ان کان علاوه، پراڪسز هڪ آخري پوائنٽ سروس ذريعي رسائي فراهم ڪن ٿا - هيٺ ڏنل بحث ڪيل ٻين ٻن حلن جي برعڪس (انهن مان هر هڪ لاءِ ٻه خدمتون آهن. رسائي جو بنياد).

بهرحال، اسٽولون ڪابه ڪسٽم وسيلن، ڇو ته ان کي اهڙي طريقي سان ترتيب نه ٿو ڏئي سگهجي ته اهو آسان ۽ جلدي آهي - “جهڙوڪ گرم ڪيڪ” - ڪبرنيٽس ۾ ڊي بي ايم ايس مثال ٺاهڻ لاءِ. انتظام يوٽيلٽي ذريعي ڪيو ويندو آهي stolonctl, تعیناتي هيلم چارٽ ذريعي ڪئي وئي آهي، ۽ ڪسٽم وارا بيان ڪيا ويا آهن ۽ ConfigMap ۾ بيان ڪيل آهن.

هڪ پاسي، اهو ظاهر ٿئي ٿو ته آپريٽر واقعي هڪ آپريٽر نه آهي (آخرڪار، اهو CRD استعمال نٿو ڪري). پر ٻئي طرف، اهو هڪ لچڪدار سسٽم آهي جيڪو توهان کي K8s ۾ وسيلن کي ترتيب ڏيڻ جي اجازت ڏئي ٿو جيئن توهان مناسب ڏسو.

اختصار ڪرڻ لاءِ، اسان لاءِ ذاتي طور تي اهو مناسب نه ٿو لڳي ته هر ڊيٽابيس لاءِ الڳ چارٽ ٺاهي. تنهن ڪري، اسان متبادل ڳولڻ شروع ڪيو.

2. Crunchy Data PostgreSQL آپريٽر

Crunchy ڊيٽا مان آپريٽر، هڪ نوجوان آمريڪي شروعاتي، هڪ منطقي متبادل وانگر لڳي. ان جي عوامي تاريخ مارچ 2017 ۾ پهرين رليز سان شروع ٿئي ٿي، ان کان پوءِ GitHub مخزن کي صرف 1300 ستارن ۽ 50 کان وڌيڪ مددگارن کان گهٽ مليا آهن. سيپٽمبر کان تازو رليز ڪيو ويو ڪبرنيٽس 1.15-1.18، OpenShift 3.11+ ۽ 4.4+، GKE ۽ VMware Enterprise PKS 1.3+ سان ڪم ڪرڻ لاءِ.

Crunchy Data PostgreSQL آپريٽر جو فن تعمير پڻ بيان ڪيل گهرجن کي پورو ڪري ٿو:

ڪبرنيٽس لاءِ PostgreSQL بيانن جو هڪ مختصر جائزو، اسان جون چونڊون ۽ تجربو

انتظام افاديت ذريعي ٿئي ٿو pgoجڏهن ته، اهو بدلي ۾ Kubernetes لاءِ ڪسٽم وسيلا ٺاهي ٿو. تنهن ڪري، آپريٽر اسان کي امڪاني صارفين جي طور تي راضي ڪيو:

  • CRD ذريعي ڪنٽرول آهي؛
  • آسان صارف انتظام (پڻ CRD ذريعي)؛
  • ٻين اجزاء سان انضمام Crunchy ڊيٽا ڪنٽينر سوٽ - PostgreSQL لاءِ ڪنٽينر تصويرن جو خاص مجموعو ۽ ان سان ڪم ڪرڻ لاءِ يوٽيلٽيز (بشمول pgBackRest، pgAudit، extensions from contributions، وغيره).

بهرحال، ڪرنچي ڊيٽا مان آپريٽر استعمال ڪرڻ شروع ڪرڻ جي ڪوشش ڪيترن ئي مسئلن کي ظاهر ڪيو:

  • برداشت ڪرڻ جو ڪو به امڪان نه هو - صرف nodeSelector مهيا ڪيل آهي.
  • ٺاهيل پوڊ ڊيپلائيشن جو حصو هئا، ان حقيقت جي باوجود ته اسان هڪ رياستي ايپليڪيشن کي ترتيب ڏنو. StatefulSets جي برعڪس، ترتيبون ڊسڪ ٺاهي نٿا سگهن.

آخري خرابي مضحکہ خیز لمحن جي ڪري ٿي: امتحان واري ماحول تي اسان هڪ ڊسڪ سان 3 نقلون هلائڻ ۾ ڪامياب ٿي ويا مقامي ذخيرو، آپريٽر کي رپورٽ ڪرڻ جو سبب بڻيو ته 3 نقل ڪم ڪري رهيا هئا (جيتوڻيڪ اهي نه هئا).

هن آپريٽر جي هڪ ٻي خصوصيت مختلف معاون سسٽم سان گڏ ان جي تيار ڪيل انضمام آهي. مثال طور، pgAdmin ۽ pgBounce انسٽال ڪرڻ آسان آهي، ۽ ان ۾ دستاويز اڳ ۾ ترتيب ڏنل گرافانا ۽ پروميٿيس سمجهيا وڃن ٿا. تازو ۾ ڇڏڻ 4.5.0-beta1 منصوبي سان بهتر انضمام الڳ الڳ نوٽ ڪيو ويو آهي پي جي مانيٽر، جنهن جي مهرباني، آپريٽر پيش ڪري ٿو هڪ واضح بصري تصوير PgSQL ميٽرڪس جي دٻي کان ٻاهر.

بهرحال، Kubernetes جي پيدا ڪيل وسيلن جي عجيب چونڊ اسان کي مختلف حل ڳولڻ جي ضرورت ڏانهن راغب ڪيو.

3. Zalando Postgres آپريٽر

اسان Zalando پروڊڪٽس کي ڊگھي عرصي کان ڄاڻون ٿا: اسان کي زيلينيم استعمال ڪرڻ جو تجربو آهي ۽ يقيناً اسان ڪوشش ڪئي پتروني PostgreSQL لاءِ انهن جو مشهور HA حل آهي. ڪمپني ٺاهڻ جي طريقيڪار بابت پوسٽ گريج آپريٽر ان جي ليکڪن مان هڪ، Alexey Klyukin، هوا تي چيو Postgres-اڱارو #5، ۽ اسان ان کي پسند ڪيو.

هي مضمون ۾ بحث ڪيل سڀ کان ننڍڙو حل آهي: پهرين رليز آگسٽ 2018 ۾ ٿي گذريو. تنهن هوندي به، رسمي رليز جي ننڍڙي تعداد جي باوجود، پروجيڪٽ هڪ ڊگهو رستو وٺي چڪو آهي، اڳ ۾ ئي مقبوليت ۾ Crunchy Data جو حل GitHub تي 1300+ ستارن سان ۽ وڌ ۾ وڌ مدد ڪندڙن جو تعداد (70+).

"هوڊ هيٺ" هي آپريٽر استعمال ڪري ٿو وقت جي آزمائشي حل:

هي ڪيئن Zalando کان آپريٽر فن تعمير پيش ڪيو ويو آهي:

ڪبرنيٽس لاءِ PostgreSQL بيانن جو هڪ مختصر جائزو، اسان جون چونڊون ۽ تجربو

آپريٽر مڪمل طور تي ڪسٽم ريسورسز جي ذريعي منظم ڪيو ويو آهي، خودڪار طور تي ڪنٽينرز مان هڪ StatefulSet ٺاهي ٿو، جيڪو پوء پوڊ ۾ مختلف سائڊ ڪارز شامل ڪندي ترتيب ڏئي سگهجي ٿو. هي سڀ هڪ اهم فائدو آهي Crunchy ڊيٽا مان آپريٽر جي مقابلي ۾.

جيئن ته اسان غور هيٺ 3 اختيارن مان Zalando مان حل چونڊيو، ان جي صلاحيتن جو وڌيڪ تفصيل هيٺ پيش ڪيو ويندو، فوري طور تي ايپليڪيشن جي مشق سان گڏ.

زلينڊو کان پوسٽ گريس آپريٽر سان مشق ڪريو

آپريٽر جي مقرري تمام سادو آهي: صرف GitHub مان موجوده رليز ڊائون لوڊ ڪريو ۽ ڊاريڪٽري مان YAML فائلون لاڳو ڪريو پڌرو ٿيو. متبادل طور تي، توھان پڻ استعمال ڪري سگھو ٿا آپريٽر ھب.

انسٽاليشن کان پوء، توهان کي ترتيب ڏيڻ بابت پريشان ٿيڻ گهرجي لاگ ۽ بيڪ اپ لاء اسٽوريج. اهو ConfigMap ذريعي ڪيو ويندو آهي postgres-operator نالي جي جاء تي جتي توهان آپريٽر کي نصب ڪيو. هڪ دفعو مخزن کي ترتيب ڏيڻ کان پوء، توهان پنهنجي پهرين پوسٽ گري ايس ايس ايل ڪلستر کي ترتيب ڏئي سگهو ٿا.

مثال طور، اسان جي معياري ترتيب هن طرح نظر اچي ٿي:

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 بيانن جو هڪ مختصر جائزو، اسان جون چونڊون ۽ تجربو
PostgreSQL ڪلستر جي فهرست

ڪبرنيٽس لاءِ PostgreSQL بيانن جو هڪ مختصر جائزو، اسان جون چونڊون ۽ تجربو
بيڪ اپ انتظام

هڪ ٻي دلچسپ خصوصيت جي حمايت آهي ٽيمون API. هي ميکانيزم خودڪار طريقي سان ٺاهي ٿو PostgreSQL ۾ ڪردار, صارف نالن جي نتيجن جي فهرست جي بنياد تي. API وري توهان کي انهن صارفين جي هڪ فهرست واپس ڪرڻ جي اجازت ڏئي ٿي جن لاءِ ڪردار پاڻمرادو ٺاهيا ويا آهن.

مسئلا ۽ حل

تنهن هوندي به، آپريٽر جي استعمال جلد ئي ڪيترن ئي اهم نقص نازل ڪيو:

  1. nodeSelector سپورٽ جي کوٽ؛
  2. بيڪ اپ کي غير فعال ڪرڻ جي ناڪامي؛
  3. جڏهن ڊيٽابيس ٺاهڻ واري فنڪشن کي استعمال ڪندي، ڊفالٽ استحقاق ظاهر نه ٿيندا آهن؛
  4. ڪڏهن ڪڏهن دستاويز غائب آهي يا پراڻي آهي.

خوشقسمتيء سان، انھن مان گھڻا حل ڪري سگهجي ٿو. اچو ته آخر کان شروع ڪريون - مسئلا دستاويز.

گهڻو ڪري، توهان حقيقت سان منهن ڪنداسين ته اهو هميشه واضح ناهي ته بيڪ اپ ڪيئن رجسٽر ڪجي ۽ بيڪ اپ بالٽ کي آپريٽر UI سان ڪيئن ڳنڍجي. دستاويزن ۾ ان جي باري ۾ ڳالهائيندو آهي، پر اصل وضاحت ۾ آهي PR:

  1. هڪ راز ٺاهڻ جي ضرورت آهي؛
  2. ان کي آپريٽر کي پيراميٽر طور موڪليو pod_environment_secret_name CRD ۾ آپريٽر سيٽنگن سان يا ConfigMap ۾ (ان تي منحصر ڪري ٿو ته توهان آپريٽر کي ڪيئن نصب ڪرڻ جو فيصلو ڪيو).

بهرحال، جيئن اهو نڪتو، اهو في الحال ناممڪن آهي. ان ڪري اسان گڏ ڪيو توهان جي آپريٽر جو نسخو ڪجھ اضافي ٽئين پارٽي جي ترقي سان. ان جي باري ۾ وڌيڪ معلومات لاء، هيٺ ڏسو.

جيڪڏهن توهان آپريٽر ڏانهن بيڪ اپ لاءِ پيٽرول پاس ڪريو ٿا، يعني - wal_s3_bucket ۽ AWS S3 ۾ چابيون رسائي، پوءِ هر شي جو بيڪ اپ ڪندو: نه رڳو پيداوار ۾ بنياد، پر اسٽيجنگ پڻ. اها ڳالهه اسان کي نه وڻي.

اسپيلو لاءِ پيرا ميٽرن جي وضاحت ۾، جيڪو PgSQL لاءِ بنيادي ڊاکر ريپر آهي جڏهن آپريٽر استعمال ڪيو، اهو نڪتو: توهان هڪ پيٽرول پاس ڪري سگهو ٿا WAL_S3_BUCKET خالي، انهي ڪري بيڪ اپ کي غير فعال ڪرڻ. ان کان علاوه، وڏي خوشي لاء، مون کي مليو تيار پي آرجنهن کي اسان فوري طور تي قبول ڪيو. هاڻي توهان کي صرف شامل ڪرڻ جي ضرورت آهي enableWALArchiving: false هڪ PostgreSQL ڪلستر وسيلن ڏانهن.

ها، 2 آپريٽرز کي هلائڻ سان ان کي مختلف طريقي سان ڪرڻ جو موقعو مليو: هڪ اسٽيجنگ (بغير بيڪ اپ)، ۽ ٻيو پيداوار لاءِ. پر اسان هڪ سان گڏ ڪرڻ جي قابل هئا.

ٺيڪ، اسان سکيو ته S3 لاءِ ڊيٽابيس تائين رسائي ڪيئن منتقل ڪجي ۽ بيڪ اپ اسٽوريج ۾ اچڻ شروع ٿي ويا. آپريٽر UI ۾ بيڪ اپ صفحن کي ڪيئن ڪم ڪجي؟

ڪبرنيٽس لاءِ PostgreSQL بيانن جو هڪ مختصر جائزو، اسان جون چونڊون ۽ تجربو

توهان کي 3 متغير شامل ڪرڻ جي ضرورت پوندي آپريٽر UI ۾:

  • SPILO_S3_BACKUP_BUCKET
  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY

ان کان پوء، بيڪ اپ جو انتظام دستياب ٿي ويندو، جيڪو اسان جي صورت ۾ ڪم کي آسان بڻائي ڇڏيندو اسٽيجنگ سان، اسان کي اجازت ڏيندو ته پيداوار کان سلائسون پهچائڻ جي بغير اضافي اسڪرپٽ کان سواء.

هڪ ٻيو فائدو ٽيمن API سان ڪم ڪيو ۽ آپريٽر اوزار استعمال ڪندي ڊيٽابيس ۽ ڪردار ٺاهڻ لاءِ ڪافي موقعا. بهرحال، ٺاهيل ڪردارن کي ڊفالٽ طور ڪو به حق نه هو. انهي جي مطابق، هڪ صارف پڙهڻ جي حقن سان نئين جدولن کي نه پڙهي سگهيو.

ائين ڇو آهي؟ ان حقيقت جي باوجود ته ڪوڊ ۾ آهي ضروري آهي GRANT، اهي هميشه استعمال نه ڪيا ويا آهن. اتي 2 طريقا آهن: syncPreparedDatabases и syncDatabases. جي syncPreparedDatabases - ان حقيقت جي باوجود ته سيڪشن ۾ preparedDatabases آهي اتي هڪ شرط آهي defaultRoles и defaultUsers ڪردار ٺاهڻ لاء، ڊفالٽ حق لاڳو نه ڪيا ويا آهن. اسان هڪ پيچ تيار ڪرڻ جي عمل ۾ آهيون ته جيئن اهي حق خود بخود لاڳو ٿين.

۽ بهتري ۾ آخري نقطو جيڪي اسان سان لاڳاپيل آهن - پيچ، جيڪو ٺاهيل StatefulSet ۾ نوڊ لاڳاپو شامل ڪري ٿو. اسان جا گراهڪ اڪثر اسپاٽ مثالن کي استعمال ڪندي قيمتن کي گهٽائڻ کي ترجيح ڏيندا آهن، ۽ اهي واضح طور تي قابل نه هوندا آهن ميزباني ڪيل ڊيٽابيس سروسز. اهو مسئلو برداشت ذريعي حل ٿي سگهي ٿو، پر نوڊ لاڳاپي جي موجودگي وڌيڪ اعتماد ڏئي ٿي.

ڇا ٿيو؟

مٿين مسئلن کي حل ڪرڻ جي نتيجن جي بنياد تي، اسان پوسٽ گريس آپريٽر کي زلانڊو کان توهان جو ذخيرو، جتي اهو گڏ ڪيو ويو آهي اهڙي مفيد پيچ سان. ۽ وڌيڪ سهولت لاء، اسان پڻ گڏ ڪيو ڊاکر تصوير.

ڪانٽو ۾ قبول ٿيل پي آر جي فهرست:

اهو تمام سٺو ٿيندو جيڪڏهن ڪميونٽي انهن پي آرز کي سپورٽ ڪري ته جيئن اهي آپريٽر جي ايندڙ ورزن سان اپ اسٽريم حاصل ڪن (1.6).

بونس! پيداوار لڏپلاڻ ڪامياب ڪهاڻي

جيڪڏهن توهان Patroni استعمال ڪريو ٿا، لائيو پروڊڪشن آپريٽر ڏانهن منتقل ٿي سگهي ٿو گهٽ ۾ گهٽ وقت سان.

اسپيلو توهان کي 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 وسيلن جي تخليق. تنهن هوندي، انهن جي مدد سان قابل ذڪر آٽوميشن حاصل ڪرڻ، اهو ياد رکڻ جي قابل آهي ته اهو پڻ ڪيترن ئي غير متوقع nuances آڻي سگهي ٿو، تنهنڪري توهان جي آپريٽرز کي سمجھاڻي سان چونڊيو.

PostgreSQL لاءِ ٽن مشهور ڪبرنيٽس آپريٽرز تي غور ڪرڻ بعد، اسان Zalando مان پروجيڪٽ چونڊيو. ۽ اسان کي ان سان گڏ ڪجهه مشڪلاتن تي قابو پائڻو پيو، پر نتيجو واقعي خوشگوار هو، تنهنڪري اسان هن تجربي کي ڪجهه ٻين PgSQL تنصيبات تائين وڌائڻ جو منصوبو ٺاهيو. جيڪڏهن توهان وٽ ساڳيو حل استعمال ڪرڻ جو تجربو آهي، اسان تبصرن ۾ تفصيل ڏسي خوش ٿيندا!

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

جو ذريعو: www.habr.com

تبصرو شامل ڪريو