"مفت" پوسٹگری ایس کیو ایل کو سخت انٹرپرائز ماحول میں کیسے فٹ کیا جائے۔

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

PostgreSQL نے پہلے ہی اپنی قابلیت کو ثابت کر دیا ہے - DBMS بہت اچھا کام کرتا ہے، اسے فیشن ایبل ڈیجیٹل کاروبار جیسے Alibaba اور TripAdvisor استعمال کرتے ہیں، اور لائسنسنگ فیس کی کمی اسے MS SQL یا Oracle DB جیسے مونسٹرز کا ایک پرکشش متبادل بناتی ہے۔ لیکن جیسے ہی ہم انٹرپرائز کے منظر نامے میں PostgreSQL کے بارے میں سوچنا شروع کرتے ہیں، ہم فوری طور پر سخت تقاضوں کا سامنا کرتے ہیں: "کنفیگریشن فالٹ ٹولرنس کے بارے میں کیا خیال ہے؟ تباہی کے خلاف مزاحمت؟ جامع نگرانی کہاں ہے؟ خودکار بیک اپ کے بارے میں کیا خیال ہے؟ ٹیپ لائبریریوں کو براہ راست اور ثانوی اسٹوریج پر استعمال کرنے کے بارے میں کیا خیال ہے؟


ایک طرف، PostgreSQL میں بلٹ ان بیک اپ ٹولز نہیں ہیں، جیسے "بالغ" DBMSs جیسے RMAN in Oracle DB یا SAP ڈیٹا بیس بیک اپ۔ دوسری طرف، کارپوریٹ بیک اپ سسٹمز (Veeam، Veritas، Commvault) کے فراہم کنندگان اگرچہ PostgreSQL کو سپورٹ کرتے ہیں، درحقیقت وہ صرف ایک مخصوص (عام طور پر اسٹینڈ اسٹون) کنفیگریشن اور مختلف پابندیوں کے سیٹ کے ساتھ کام کرتے ہیں۔

PostgreSQL کے لیے خاص طور پر تیار کیے گئے بیک اپ سسٹم، جیسے Barman, Wal-g, pg_probackup، PostgreSQL DBMS کی چھوٹی تنصیبات میں یا جہاں IT لینڈ اسکیپ کے دیگر عناصر کے بھاری بیک اپ کی ضرورت نہیں ہوتی ہے، انتہائی مقبول ہیں۔ مثال کے طور پر، PostgreSQL کے علاوہ، انفراسٹرکچر میں فزیکل اور ورچوئل سرورز، OpenShift، Oracle، MariaDB، Cassandra وغیرہ شامل ہو سکتے ہیں۔ یہ سب ایک عام ٹول کے ساتھ بیک اپ کرنے کا مشورہ دیا جاتا ہے۔ PostgreSQL کے لیے خصوصی طور پر علیحدہ حل انسٹال کرنا ایک برا خیال ہے: ڈیٹا کو کہیں ڈسک پر کاپی کیا جائے گا، اور پھر اسے ٹیپ پر ہٹانے کی ضرورت ہے۔ یہ دوہرا بیک اپ بیک اپ کا وقت بڑھاتا ہے، اور اس کے علاوہ، زیادہ تنقیدی طور پر، بحالی کا وقت۔

انٹرپرائز حل میں، تنصیب کا بیک اپ ایک مخصوص کلسٹر میں نوڈس کی ایک مخصوص تعداد کے ساتھ ہوتا ہے۔ ایک ہی وقت میں، مثال کے طور پر، Commvault صرف دو نوڈ کلسٹر کے ساتھ کام کر سکتا ہے، جس میں پرائمری اور سیکنڈری کو سختی سے مخصوص نوڈس کو تفویض کیا جاتا ہے۔ اور یہ صرف پرائمری سے بیک اپ لینا سمجھ میں آتا ہے، کیونکہ سیکنڈری سے بیک اپ کی اپنی حدود ہیں۔ DBMS کی خصوصیات کی وجہ سے، سیکنڈری پر ڈمپ نہیں بنتا ہے، اور اس وجہ سے صرف فائل بیک اپ کا امکان باقی رہتا ہے۔

ڈاؤن ٹائم کے خطرے کو کم کرنے کے لیے، غلطی برداشت کرنے والا نظام بناتے وقت، ایک "لائیو" کلسٹر کنفیگریشن بنائی جاتی ہے، اور پرائمری آہستہ آہستہ مختلف سرورز کے درمیان منتقل ہو سکتی ہے۔ مثال کے طور پر، Patroni سافٹ ویئر خود پرائمری کو تصادفی طور پر منتخب کردہ کلسٹر نوڈ پر لانچ کرتا ہے۔ آئی بی ایس کے پاس باکس سے باہر اسے ٹریک کرنے کا کوئی طریقہ نہیں ہے، اور اگر ترتیب بدل جاتی ہے، تو عمل ٹوٹ جاتا ہے۔ یعنی، بیرونی کنٹرول کا تعارف ISR کو مؤثر طریقے سے کام کرنے سے روکتا ہے، کیونکہ کنٹرول سرور صرف یہ نہیں سمجھتا ہے کہ کہاں سے اور کس ڈیٹا کو کاپی کرنے کی ضرورت ہے۔

ایک اور مسئلہ پوسٹگریس میں بیک اپ کا نفاذ ہے۔ یہ ڈمپ کے ذریعے ممکن ہے، اور یہ چھوٹے ڈیٹا بیس پر کام کرتا ہے۔ لیکن بڑے ڈیٹا بیس میں، ڈمپ میں کافی وقت لگتا ہے، بہت سارے وسائل کی ضرورت ہوتی ہے اور ڈیٹا بیس کی مثال کی ناکامی کا باعث بن سکتا ہے۔

فائل بیک اپ صورتحال کو درست کرتا ہے، لیکن بڑے ڈیٹا بیس پر یہ سست ہے کیونکہ یہ سنگل تھریڈڈ موڈ میں کام کرتا ہے۔ اس کے علاوہ، دکانداروں پر کئی اضافی پابندیاں ہیں۔ یا تو آپ ایک ہی وقت میں فائل اور ڈمپ بیک اپ استعمال نہیں کر سکتے، یا ڈپلیکیشن کی سہولت نہیں ہے۔ بہت سے مسائل ہیں، اور اکثر پوسٹگریس کے بجائے مہنگا لیکن ثابت شدہ ڈی بی ایم ایس کا انتخاب کرنا آسان ہوتا ہے۔

پیچھے ہٹنے کے لیے کہیں نہیں ہے! ماسکو ڈویلپرز پیچھے ہیں!

تاہم، حال ہی میں ہماری ٹیم کو ایک مشکل چیلنج کا سامنا کرنا پڑا: AIS OSAGO 2.0 بنانے کے پروجیکٹ میں، جہاں ہم نے IT انفراسٹرکچر بنایا، ڈویلپرز نے نئے سسٹم کے لیے PostgreSQL کا انتخاب کیا۔

بڑے سافٹ ویئر ڈویلپرز کے لیے "ٹرینڈی" اوپن سورس حل استعمال کرنا بہت آسان ہے۔ فیس بک کے پاس اس ڈی بی ایم ایس کے آپریشن کو سپورٹ کرنے کے لیے کافی ماہرین ہیں۔ اور RSA کے معاملے میں، "دوسرے دن" کے تمام کام ہمارے کندھوں پر آ گئے۔ ہمیں غلطی کی رواداری کو یقینی بنانے، ایک کلسٹر کو جمع کرنے اور یقیناً بیک اپ ترتیب دینے کی ضرورت تھی۔ عمل کی منطق مندرجہ ذیل تھی:

• SRK کو کلسٹر کے پرائمری نوڈ سے بیک اپ بنانا سکھائیں۔ ایسا کرنے کے لیے، SRK کو اسے تلاش کرنا ہوگا - جس کا مطلب ہے کہ ایک یا دوسرے PostgreSQL کلسٹر مینجمنٹ حل کے ساتھ انضمام کی ضرورت ہے۔ آر ایس اے کے معاملے میں اس کے لیے پیٹرونی سافٹ ویئر کا استعمال کیا گیا۔
• ڈیٹا کے حجم اور ریکوری کی ضروریات کی بنیاد پر بیک اپ کی قسم کا فیصلہ کریں۔ مثال کے طور پر، جب آپ کو صفحات کو دانے دار طریقے سے بحال کرنے کی ضرورت ہو، تو ڈمپ کا استعمال کریں، اور اگر ڈیٹا بیس بڑے ہیں اور دانے دار بحالی کی ضرورت نہیں ہے، تو فائل کی سطح پر کام کریں۔
• ملٹی تھریڈڈ موڈ میں بیک اپ کاپی بنانے کے لیے بلاک بیک اپ کے امکان کو حل کے ساتھ منسلک کریں۔

ایک ہی وقت میں، ہم نے ابتدائی طور پر اضافی اجزاء کے زبردست استعمال کے بغیر ایک مؤثر اور سادہ نظام بنانے کا ارادہ کیا۔ کم بیساکھی، عملے پر کم کام کا بوجھ اور IBS کی ناکامی کا خطرہ کم۔ ہم نے فوری طور پر ان طریقوں کو خارج کر دیا جس میں Veeam اور RMAN کا استعمال کیا گیا تھا، کیونکہ دو حلوں کا ایک سیٹ پہلے سے ہی سسٹم کی ناقابل اعتبار ہونے کی نشاندہی کرتا ہے۔

انٹرپرائز کے لئے ایک چھوٹا سا جادو

لہذا، ہمیں بیک اپ ڈیٹا سینٹر میں اسی انفراسٹرکچر کی عکس بندی کے ساتھ، 10 نوڈس کے 3 کلسٹرز کے لیے قابل اعتماد بیک اپ کی ضمانت دینے کی ضرورت ہے۔ پوسٹگری ایس کیو ایل کے لحاظ سے ڈیٹا سینٹرز ایکٹیو پیسیو اصول پر کام کرتے ہیں۔ ڈیٹا بیس کا کل سائز 50 TB تھا۔ کوئی بھی کارپوریٹ سطح کا کنٹرول سسٹم آسانی سے اس سے نمٹ سکتا ہے۔ لیکن انتباہ یہ ہے کہ ابتدائی طور پر پوسٹگریس کے پاس بیک اپ سسٹم کے ساتھ مکمل اور گہری مطابقت کا کوئی اشارہ نہیں ہے۔ لہذا، ہمیں ایک ایسا حل تلاش کرنا تھا جو ابتدائی طور پر PostgreSQL کے ساتھ مل کر زیادہ سے زیادہ فعالیت رکھتا ہو، اور سسٹم کو بہتر کرے۔

ہم نے 3 اندرونی "ہیکتھونز" منعقد کیے - ہم نے پچاس سے زیادہ پیش رفتوں کو دیکھا، ان کا تجربہ کیا، اپنے مفروضوں کے سلسلے میں تبدیلیاں کیں، اور ان کا دوبارہ تجربہ کیا۔ دستیاب اختیارات کا جائزہ لینے کے بعد، ہم نے Commvault کا انتخاب کیا۔ باکس کے باہر، یہ پروڈکٹ آسان ترین PostgreSQL کلسٹر انسٹالیشن کے ساتھ کام کر سکتی ہے، اور اس کے کھلے فن تعمیر نے کامیاب ترقی اور انضمام کے لیے امیدیں پیدا کیں (جو جائز تھیں)۔ Commvault PostgreSQL لاگز کا بیک اپ بھی لے سکتا ہے۔ مثال کے طور پر، PostgreSQL کے لحاظ سے Veritas NetBackup صرف مکمل بیک اپ بنا سکتا ہے۔

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

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

پیٹرونی ہر کلسٹر کے لیے ایک بنیادی نوڈ کی وضاحت کرتا ہے۔ یہ ڈیٹا سینٹر میں کوئی بھی مفت نوڈ ہوسکتا ہے - لیکن صرف زیادہ تر۔ بیک اپ میں، تمام نوڈس سیکنڈری ہیں۔

Commvault کو یہ سمجھنے کے لیے کہ کون سا کلسٹر نوڈ پرائمری ہے، ہم نے پوسٹگریس کے ساتھ سسٹم (حل کے کھلے فن تعمیر کی بدولت) کو مربوط کیا۔ اس مقصد کے لیے، ایک اسکرپٹ بنایا گیا تھا جو پرائمری نوڈ کے موجودہ مقام کی اطلاع Commvault مینجمنٹ سرور کو دیتا ہے۔

عام طور پر، عمل اس طرح لگتا ہے:

Patroni پرائمری کا انتخاب کرتا ہے → Keepalived IP کلسٹر کو اٹھاتا ہے اور اسکرپٹ چلاتا ہے → منتخب کلسٹر نوڈ پر Commvault ایجنٹ کو ایک اطلاع موصول ہوتی ہے کہ یہ پرائمری → Commvault خودکار طور پر سیوڈو کلائنٹ کے اندر بیک اپ کو دوبارہ ترتیب دیتا ہے۔

اس نقطہ نظر کا فائدہ یہ ہے کہ حل مستقل مزاجی، لاگز کی درستگی، یا پوسٹگریس مثال کی بازیابی کو متاثر نہیں کرتا ہے۔ یہ آسانی سے توسیع پذیر بھی ہے، کیونکہ Commvault پرائمری اور سیکنڈری نوڈس کو ٹھیک کرنا اب ضروری نہیں ہے۔ یہ کافی ہے کہ سسٹم سمجھتا ہے کہ پرائمری کہاں ہے، اور نوڈس کی تعداد کو تقریباً کسی بھی قدر تک بڑھایا جا سکتا ہے۔

حل مثالی ہونے کا بہانہ نہیں کرتا اور اس کی اپنی باریکیاں ہیں۔ Commvault صرف پوری مثال کا بیک اپ لے سکتا ہے، انفرادی ڈیٹا بیس کا نہیں۔ لہذا، ہر ڈیٹا بیس کے لیے ایک الگ مثال بنائی گئی تھی۔ حقیقی کلائنٹس کو ورچوئل سیوڈو کلائنٹس میں ملایا جاتا ہے۔ ہر Commvault pseudo-client ایک UNIX کلسٹر ہے۔ وہ کلسٹر نوڈز جن پر پوسٹگریس کے لیے Commvault ایجنٹ انسٹال ہوتا ہے اس میں شامل کیا جاتا ہے۔ نتیجے کے طور پر، سیوڈو کلائنٹ کے تمام ورچوئل نوڈس کو ایک مثال کے طور پر بیک اپ کیا جاتا ہے۔

ہر چھدم کلائنٹ کے اندر، کلسٹر کے فعال نوڈ کی نشاندہی کی جاتی ہے۔ Commvault کے لیے ہمارا انضمام حل یہی بیان کرتا ہے۔ اس کے آپریشن کا اصول بہت آسان ہے: اگر نوڈ پر کلسٹر آئی پی اٹھایا جاتا ہے، تو اسکرپٹ Commvault ایجنٹ بائنری میں "ایکٹو نوڈ" پیرامیٹر سیٹ کرتا ہے - درحقیقت، اسکرپٹ میموری کے مطلوبہ حصے میں "1" سیٹ کرتا ہے۔ . ایجنٹ اس ڈیٹا کو CommServe میں منتقل کرتا ہے، اور Commvault مطلوبہ نوڈ سے بیک اپ بناتا ہے۔ اس کے علاوہ، اسکرپٹ کی سطح پر ترتیب کی درستگی کی جانچ پڑتال کی جاتی ہے، بیک اپ شروع کرتے وقت غلطیوں سے بچنے میں مدد ملتی ہے۔

ایک ہی وقت میں، آر پی او اور بیک اپ ونڈو کی ضروریات کو پورا کرتے ہوئے، ایک سے زیادہ تھریڈز کے بلاکس میں بڑے ڈیٹا بیس کا بیک اپ لیا جاتا ہے۔ سسٹم پر بوجھ غیر معمولی ہے: مکمل کاپیاں اتنی کثرت سے نہیں آتیں، دوسرے دنوں میں صرف لاگز جمع کیے جاتے ہیں، اور کم بوجھ کے دورانیے میں۔

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

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

فی الحال، IBS پیداواری خدمات کو متاثر نہیں کرتا ہے، لیکن اگر صورتحال بدل جاتی ہے، Commvault لوڈ کو محدود کرنے کو فعال کر سکتا ہے۔

کیا یہ اچھا ہے؟ اچھی!

لہذا، ہمیں پوسٹگری ایس کیو ایل کلسٹر کی تنصیب کے لیے نہ صرف قابل عمل، بلکہ ایک مکمل خودکار بیک اپ بھی ملا ہے، اور یہ انٹرپرائز کالز کے لیے تمام تقاضوں کو پورا کرتا ہے۔

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

یقیناً اس راستے میں ہمیں لوہے کے جوتے کے سات جوڑے پہننے تھے، بہت سی مشکلات پر قابو پانا تھا، کئی ریکوں پر قدم رکھنا تھا اور کئی غلطیوں کو درست کرنا تھا۔ لیکن اب اس نقطہ نظر کو پہلے ہی آزمایا جا چکا ہے اور اسے انٹرپرائز کے سخت حالات میں ملکیتی DBMS کے بجائے اوپن سورس کو لاگو کرنے کے لیے استعمال کیا جا سکتا ہے۔

کیا آپ نے کارپوریٹ ماحول میں PostgreSQL کے ساتھ کام کرنے کی کوشش کی ہے؟

مصنفین:

اولیگ لاورینوف، ڈیٹا سٹوریج سسٹم کے ڈیزائن انجینئر، جیٹ انفو سسٹم

دمتری ایرکن، جیٹ انفو سسٹم میں کمپیوٹر سسٹمز کے ڈیزائن انجینئر

ماخذ: www.habr.com