🥇 Kubernetes کے لیے PostgreSQL آپریٹرز کا ایک مختصر جائزہ، ہماری پسند اور تجربہ

تیزی سے، کلائنٹس کو درج ذیل درخواستیں موصول ہو رہی ہیں: "ہم اسے Amazon RDS کی طرح چاہتے ہیں، لیکن سستا"؛ "ہم اسے RDS کی طرح چاہتے ہیں، لیکن ہر جگہ، کسی بھی بنیادی ڈھانچے میں۔" Kubernetes پر اس طرح کے ایک منظم حل کو نافذ کرنے کے لیے، ہم نے PostgreSQL (Stolon، Crunchy Data اور Zalando کے آپریٹرز) کے لیے مقبول ترین آپریٹرز کی موجودہ حالت کو دیکھا اور اپنا انتخاب کیا۔

یہ مضمون وہ تجربہ ہے جو ہم نے ایک نظریاتی نقطہ نظر (حل کا جائزہ) اور عملی پہلو سے حاصل کیا ہے (کیا منتخب کیا گیا اور اس سے کیا آیا)۔ لیکن پہلے، آئیے اس بات کا تعین کریں کہ RDS کے ممکنہ متبادل کے لیے عام تقاضے کیا ہیں...

RDS کیا ہے؟

جب لوگ RDS کے بارے میں بات کرتے ہیں، ہمارے تجربے میں، ان کا مطلب ایک منظم DBMS سروس ہے جو:

ترتیب دینے میں آسان؛
اسنیپ شاٹس کے ساتھ کام کرنے اور ان سے بازیافت کرنے کی صلاحیت رکھتا ہے (ترجیحی طور پر مدد کے ساتھ PITR);
آپ کو ماسٹر غلام ٹوپولاجیز بنانے کی اجازت دیتا ہے؛
ایکسٹینشنز کی ایک بھرپور فہرست ہے؛
آڈیٹنگ اور صارف/رسائی کا انتظام فراہم کرتا ہے۔

عام طور پر، ہاتھ میں کام کو لاگو کرنے کے نقطہ نظر بہت مختلف ہوسکتے ہیں، لیکن مشروط جواب کے ساتھ راستہ ہمارے قریب نہیں ہے. (2GIS کے ساتھی نتیجہ کے طور پر اسی طرح کے نتیجے پر پہنچے اس کی کوشش "پوسٹگریس پر مبنی فیل اوور کلسٹر کو تیزی سے تعینات کرنے کے لئے ایک ٹول بنائیں۔")

Kubernetes ماحولیاتی نظام میں اسی طرح کے مسائل کو حل کرنے کے لیے آپریٹرز ایک عام طریقہ ہے۔ "Flanta" کے تکنیکی ڈائریکٹر نے پہلے ہی Kubernetes کے اندر شروع کیے گئے ڈیٹا بیس کے سلسلے میں ان کے بارے میں مزید تفصیل سے بات کی ہے۔ ڈسٹولمیں اس کی رپورٹوں میں سے ایک.

NB: فوری طور پر آسان آپریٹرز بنانے کے لیے، ہم اپنی اوپن سورس افادیت پر توجہ دینے کی تجویز کرتے ہیں۔ شیل آپریٹر. اس کا استعمال کرتے ہوئے، آپ Go کے علم کے بغیر یہ کر سکتے ہیں، لیکن ان طریقوں سے جو سسٹم ایڈمنسٹریٹرز سے زیادہ واقف ہیں: Bash، Python، وغیرہ میں۔

PostgreSQL کے لیے کئی مشہور K8s آپریٹرز ہیں:

اسٹولن؛
کرچی ڈیٹا PostgreSQL آپریٹر؛
Zalando Postgres آپریٹر.

آئیے ان کو مزید قریب سے دیکھتے ہیں۔

آپریٹر کا انتخاب

اوپر بیان کی گئی اہم خصوصیات کے علاوہ، ہم - بطور Kubernetes انفراسٹرکچر آپریشن انجینئرز - آپریٹرز سے درج ذیل کی بھی توقع رکھتے ہیں:

Git سے اور اس کے ساتھ تعیناتی۔ حسب ضرورت وسائل;
پوڈ مخالف وابستگی کی حمایت؛
نوڈ وابستگی یا نوڈ سلیکٹر انسٹال کرنا؛
رواداری کی تنصیب؛
ٹیوننگ کی صلاحیتوں کی دستیابی؛
قابل فہم ٹیکنالوجیز اور حکم بھی۔

ہر ایک نکات کی تفصیلات میں جانے کے بغیر (اگر آپ کو پورا مضمون پڑھنے کے بعد بھی ان کے بارے میں سوالات ہیں تو تبصروں میں پوچھیں)، میں عام طور پر نوٹ کروں گا کہ کلسٹر نوڈس کی تخصص کو زیادہ درست طریقے سے بیان کرنے کے لیے ان پیرامیٹرز کی ضرورت ہے۔ انہیں مخصوص ایپلی کیشنز کے لیے آرڈر کریں۔ اس طرح ہم کارکردگی اور لاگت کے لحاظ سے بہترین توازن حاصل کر سکتے ہیں۔

اب خود PostgreSQL آپریٹرز کی طرف چلتے ہیں۔

1. سٹولن

سٹولن۔ میں اطالوی کمپنی Sorint.lab سے پہلے ہی بیان کیا گیا رپورٹ DBMS کے آپریٹرز کے درمیان ایک قسم کے معیار کے طور پر سمجھا جاتا تھا۔ یہ کافی پرانا پروجیکٹ ہے: اس کی پہلی عوامی ریلیز نومبر 2015 میں ہوئی تھی

درحقیقت، سٹولن سوچے سمجھے فن تعمیر کی ایک بہترین مثال ہے:

اس آپریٹر کی ڈیوائس کو رپورٹ میں تفصیل سے دیکھا جا سکتا ہے یا منصوبے کی دستاویزات. عام طور پر، یہ کہنا کافی ہے کہ یہ بیان کردہ سب کچھ کر سکتا ہے: فیل اوور، شفاف کلائنٹ تک رسائی کے لیے پراکسی، بیک اپ... مزید برآں، پراکسیز ایک اینڈ پوائنٹ سروس کے ذریعے رسائی فراہم کرتی ہیں - ذیل میں زیر بحث دیگر دو حلوں کے برعکس (ان میں سے ہر ایک کے لیے دو خدمات ہیں بنیاد تک رسائی حاصل کرنا)۔

تاہم، Stolon کوئی حسب ضرورت وسائل نہیں۔، جس کی وجہ سے اسے اس طرح سے تعینات نہیں کیا جا سکتا کہ یہ آسان اور تیز ہو - "جیسے ہاٹ کیک" - کوبرنیٹس میں ڈی بی ایم ایس مثالیں بنانا۔ انتظام افادیت کے ذریعے کیا جاتا ہے stolonctl, تعیناتی ہیلم چارٹ کے ذریعے کی جاتی ہے، اور حسب ضرورت کی تعریف اور ترتیب ConfigMap میں کی جاتی ہے۔

ایک طرف، یہ پتہ چلتا ہے کہ آپریٹر واقعی ایک آپریٹر نہیں ہے (سب کے بعد، یہ CRD استعمال نہیں کرتا ہے). لیکن دوسری طرف، یہ ایک لچکدار نظام ہے جو آپ کو K8s میں وسائل کو ترتیب دینے کی اجازت دیتا ہے جیسا کہ آپ مناسب دیکھتے ہیں۔

خلاصہ کرنے کے لیے، ذاتی طور پر ہمارے لیے ہر ڈیٹا بیس کے لیے الگ چارٹ بنانا مناسب نہیں لگتا تھا۔ لہذا، ہم نے متبادل تلاش کرنا شروع کر دیا.

2. کرنچی ڈیٹا پوسٹگری ایس کیو ایل آپریٹر

کرچی ڈیٹا سے آپریٹرایک نوجوان امریکی آغاز، ایک منطقی متبادل کی طرح لگتا تھا۔ اس کی عوامی تاریخ مارچ 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 کے ذریعے بھی)؛
دوسرے اجزاء کے ساتھ انضمام کرنچی ڈیٹا کنٹینر سویٹ — PostgreSQL کے لیے کنٹینر امیجز کا ایک خصوصی مجموعہ اور اس کے ساتھ کام کرنے کے لیے یوٹیلیٹیز (بشمول pgBackRest، pgAudit، شراکت سے ایکسٹینشنز وغیرہ)۔

تاہم، کرنچی ڈیٹا سے آپریٹر کا استعمال شروع کرنے کی کوششوں سے کئی مسائل سامنے آئے:

برداشت کا کوئی امکان نہیں تھا - صرف نوڈ سلیکٹر فراہم کیا گیا ہے۔
اس حقیقت کے باوجود کہ ہم نے ایک اسٹیٹفول ایپلی کیشن تعینات کی ہے، بنائے گئے پوڈز تعیناتی کا حصہ تھے۔ StatefulSets کے برعکس، تعیناتیاں ڈسکیں نہیں بنا سکتیں۔

آخری خرابی مضحکہ خیز لمحات کی طرف جاتا ہے: ٹیسٹ کے ماحول میں ہم ایک ڈسک کے ساتھ 3 نقلیں چلانے میں کامیاب ہوئے مقامی ذخیرہ، جس کی وجہ سے آپریٹر کو اطلاع دی گئی کہ 3 نقلیں کام کر رہی ہیں (حالانکہ وہ نہیں ہیں)۔

اس آپریٹر کی ایک اور خصوصیت مختلف سپورٹ سسٹمز کے ساتھ اس کا ریڈی میڈ انضمام ہے۔ مثال کے طور پر، pgAdmin اور pgBounce کو انسٹال کرنا آسان ہے۔ دستاویزات پہلے سے تشکیل شدہ گرافانا اور پرومیتھیس کو سمجھا جاتا ہے۔ حالیہ میں ریلیز 4.5.0-beta1 پروجیکٹ کے ساتھ بہتر انضمام کو الگ سے نوٹ کیا گیا ہے۔ پی جی مانیٹر، جس کی بدولت آپریٹر باکس سے باہر PgSQL میٹرکس کا واضح تصور پیش کرتا ہے۔

تاہم، Kubernetes کے تیار کردہ وسائل کے عجیب و غریب انتخاب نے ہمیں ایک مختلف حل تلاش کرنے کی ضرورت پیش کی۔

3. زلینڈو پوسٹگریس آپریٹر

ہم Zalando کی مصنوعات کو ایک طویل عرصے سے جانتے ہیں: ہمارے پاس Zalenium استعمال کرنے کا تجربہ ہے اور یقیناً ہم نے کوشش کی۔ پیٹرونی PostgreSQL کے لیے ان کا مقبول HA حل ہے۔ بنانے کے لئے کمپنی کے نقطہ نظر کے بارے میں پوسٹگریس آپریٹر اس کے ایک مصنف، الیکسی کلوکن نے آن ایئر کہا پوسٹگریس-منگل #5، اور ہم نے اسے پسند کیا۔

یہ مضمون میں زیر بحث سب سے کم عمر حل ہے: پہلی ریلیز اگست 2018 میں ہوئی تھی۔ تاہم، رسمی ریلیز کی کم تعداد کے باوجود، پراجیکٹ نے ایک طویل سفر طے کیا ہے، جو پہلے ہی مقبولیت میں GitHub پر 1300+ ستاروں اور تعاون کرنے والوں کی زیادہ سے زیادہ تعداد (70+) کے ساتھ Crunchy Data کے حل کو پیچھے چھوڑ چکا ہے۔

"ہڈ کے نیچے" یہ آپریٹر وقتی جانچ کے حل استعمال کرتا ہے:

پیٹرونی اور سپیلو ڈرائیونگ کے لیے،
وال-ای - بیک اپ کے لیے،
پی جی باؤنسر - کنکشن پول کے طور پر۔

Zalando سے آپریٹر فن تعمیر کو اس طرح پیش کیا گیا ہے:

آپریٹر کو کسٹم ریسورسز کے ذریعے مکمل طور پر منظم کیا جاتا ہے، خود بخود کنٹینرز سے ایک اسٹیٹفول سیٹ بناتا ہے، جسے پھر پوڈ میں مختلف سائڈ کارز شامل کر کے اپنی مرضی کے مطابق بنایا جا سکتا ہے۔ کرچی ڈیٹا سے آپریٹر کے مقابلے میں یہ سب ایک اہم فائدہ ہے۔

چونکہ ہم نے زیر غور 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 کلسٹرز کی فہرست

بیک اپ مینجمنٹ

ایک اور دلچسپ خصوصیت سپورٹ ہے۔ ٹیمز API. یہ میکانزم خود بخود تخلیق کرتا ہے۔ PostgreSQL میں کردار، صارف ناموں کی نتیجے کی فہرست کی بنیاد پر۔ پھر API آپ کو ان صارفین کی فہرست واپس کرنے کی اجازت دیتا ہے جن کے لیے رولز خود بخود بنائے جاتے ہیں۔

مسائل اور ان کا حل

تاہم، آپریٹر کے استعمال نے جلد ہی کئی اہم کوتاہیوں کا انکشاف کیا:

نوڈ سلیکٹر سپورٹ کی کمی؛
بیک اپ کو غیر فعال کرنے میں ناکامی؛
ڈیٹا بیس کی تخلیق کا فنکشن استعمال کرتے وقت، پہلے سے طے شدہ مراعات ظاہر نہیں ہوتے ہیں۔
بعض اوقات دستاویزات غائب ہوتی ہیں یا پرانی ہوتی ہیں۔

خوش قسمتی سے، ان میں سے بہت سے حل کیا جا سکتا ہے. چلو آخر سے شروع کرتے ہیں - کے ساتھ مسائل دستاویزات.

زیادہ تر امکان ہے کہ آپ کو اس حقیقت کا سامنا کرنا پڑے گا کہ یہ ہمیشہ واضح نہیں ہوتا ہے کہ بیک اپ کو کیسے رجسٹر کرنا ہے اور بیک اپ بالٹی کو آپریٹر UI سے کیسے جوڑنا ہے۔ دستاویزات اس کے بارے میں گزرتے ہوئے بولتی ہیں، لیکن اصل تفصیل اس میں ہے۔ PR:

ایک راز بنانے کی ضرورت ہے؛
اسے پیرامیٹر کے طور پر آپریٹر کو منتقل کریں۔ pod_environment_secret_name آپریٹر کی ترتیبات کے ساتھ CRD میں یا ConfigMap میں (اس بات پر منحصر ہے کہ آپ آپریٹر کو انسٹال کرنے کا فیصلہ کیسے کرتے ہیں)۔

تاہم، جیسا کہ یہ پتہ چلتا ہے، یہ فی الحال ناممکن ہے. اسی لیے ہم نے جمع کیا۔ آپریٹر کا آپ کا ورژن کچھ اضافی تیسری پارٹی کی پیشرفت کے ساتھ۔ اس کے بارے میں مزید معلومات کے لیے، نیچے ملاحظہ کریں۔

اگر آپ بیک اپ کے لیے پیرامیٹرز آپریٹر کو دیتے ہیں، یعنی - wal_s3_bucket اور AWS S3 میں چابیاں تک رسائی حاصل کریں، پھر اسے ہر چیز کا بیک اپ لے گا۔: نہ صرف پیداوار میں اڈے، بلکہ اسٹیجنگ بھی۔ یہ ہمیں سوٹ نہیں کرتا تھا۔

سپیلو کے پیرامیٹرز کی تفصیل میں، جو آپریٹر کا استعمال کرتے وقت پی جی ایس کیو ایل کے لیے بنیادی ڈوکر ریپر ہے، یہ پتہ چلا: آپ ایک پیرامیٹر پاس کر سکتے ہیں WAL_S3_BUCKET خالی، اس طرح بیک اپ کو غیر فعال کرنا۔ اس کے علاوہ، بہت خوشی کے لئے، میں نے پایا تیار PRجسے ہم نے فوراً اپنے کانٹے میں قبول کر لیا۔ اب آپ کو صرف شامل کرنے کی ضرورت ہے۔ 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 کردار بنانے کے لیے، پہلے سے طے شدہ حقوق لاگو نہیں ہوتے ہیں۔ ہم ایک پیچ تیار کرنے کے عمل میں ہیں تاکہ یہ حقوق خود بخود لاگو ہوں۔

اور ان بہتریوں کا آخری نکتہ جو ہمارے لیے متعلقہ ہیں - پیچ، جو تخلیق کردہ StatefulSet میں Node Affinity کا اضافہ کرتا ہے۔ ہمارے کلائنٹس اکثر اسپاٹ انسٹینس کا استعمال کرکے لاگت کو کم کرنے کو ترجیح دیتے ہیں، اور وہ واضح طور پر ڈیٹا بیس سروسز کی میزبانی کے قابل نہیں ہیں۔ اس مسئلے کو رواداری کے ذریعے حل کیا جا سکتا ہے، لیکن نوڈ ایفینیٹی کی موجودگی زیادہ اعتماد دیتی ہے۔

کیا ہوا؟

مندرجہ بالا مسائل کو حل کرنے کے نتائج کی بنیاد پر، ہم نے زلینڈو سے پوسٹگریس آپریٹر کو آپ کا ذخیرہ، جہاں اسے اس طرح کے مفید پیچ کے ساتھ جمع کیا جاتا ہے۔ اور زیادہ سہولت کے لیے ہم نے بھی جمع کیا۔ ڈاکر کی تصویر.

فورک میں قبول شدہ PRs کی فہرست:

یہ بہت اچھا ہوگا اگر کمیونٹی ان PRs کو سپورٹ کرتی ہے تاکہ وہ آپریٹر کے اگلے ورژن (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. نقل کو غیر فعال کرنے کے بعد، آپ کو ترتیب کو درست کرنے کی ضرورت ہے۔ یہ اچھی طرح بیان کیا گیا ہے۔ wiki.postgresql.org پر مضمون میں.

اس منصوبے کی بدولت، سوئچ اوور کم سے کم تاخیر کے ساتھ ہوا۔

حاصل يہ ہوا

Kubernetes آپریٹرز آپ کو مختلف کارروائیوں کو K8s وسائل کی تخلیق تک کم کرکے آسان بنانے کی اجازت دیتے ہیں۔ تاہم، ان کی مدد سے قابل ذکر آٹومیشن حاصل کرنے کے بعد، یہ یاد رکھنے کے قابل ہے کہ یہ متعدد غیر متوقع باریکیاں بھی لا سکتا ہے، لہذا اپنے آپریٹرز کو سمجھداری سے منتخب کریں۔

PostgreSQL کے لیے تین سب سے مشہور Kubernetes آپریٹرز پر غور کرنے کے بعد، ہم نے Zalando سے پروجیکٹ کا انتخاب کیا۔ اور ہمیں اس کے ساتھ کچھ مشکلات پر قابو پانا پڑا، لیکن نتیجہ واقعی خوش کن تھا، لہذا ہم اس تجربے کو کچھ دیگر PgSQL تنصیبات تک بڑھانے کا ارادہ رکھتے ہیں۔ اگر آپ کو اسی طرح کے حل استعمال کرنے کا تجربہ ہے، تو ہمیں تبصروں میں تفصیلات دیکھ کر خوشی ہوگی!

PS

ہمارے بلاگ پر بھی پڑھیں:

ماخذ: www.habr.com

Kubernetes، ہمارے انتخاب اور تجربے کے لیے PostgreSQL بیانات کا ایک مختصر جائزہ