ڪيترائي ماڻھو واقف آھن PostgreSQL DBMS، ۽ اھو پاڻ کي ننڍڙن تنصيبن ۾ ثابت ڪيو آھي. بهرحال، اوپن سورس ڏانهن رجحان تيزيءَ سان واضح ٿي چڪو آهي، جيتوڻيڪ اهو اچي ٿو وڏين ڪمپنين ۽ ادارن جي گهرج جي. هن آرٽيڪل ۾ اسين توهان کي ٻڌائينداسين ته پوسٽ گريس کي ڪارپوريٽ ماحول ۾ ڪيئن ضم ڪيو وڃي ۽ مثال طور Commvault بيڪ اپ سسٽم استعمال ڪندي هن ڊيٽابيس لاءِ بيڪ اپ سسٽم (BSS) ٺاهڻ جو اسان جو تجربو شيئر ڪيو.
PostgreSQL اڳ ۾ ئي ثابت ڪري چڪو آهي ان جي قيمت - DBMS تمام سٺو ڪم ڪري ٿو، اهو فيشن ايبل ڊجيٽل ڪاروبار جهڙوڪ علي بابا ۽ TripAdvisor پاران استعمال ڪيو ويندو آهي، ۽ لائسنسنگ فيس جي گهٽتائي ان کي MS SQL يا Oracle DB وانگر راکشس جو هڪ پرجوش متبادل بڻائي ٿو. پر جيئن ئي اسان انٽرپرائز جي منظرنامي ۾ PostgreSQL جي باري ۾ سوچڻ شروع ڪيو، اسان فوري طور تي سخت ضرورتن ۾ هلون ٿا: “ڇا ترتيب جي غلطي رواداري بابت؟ آفت جي مزاحمت؟ جامع نگراني ڪٿي آهي؟ خودڪار بيڪ اپ بابت ڇا؟ ٽيپ لائبريرين کي سڌو ۽ ثانوي اسٽوريج تي استعمال ڪرڻ بابت ڇا؟
هڪ طرف، PostgreSQL وٽ بلٽ ان بيڪ اپ ٽولز نه آهن، جهڙوڪ ”بالغ“ DBMSs جهڙوڪ RMAN Oracle DB ۾ يا SAP ڊيٽابيس بيڪ اپ. ٻئي طرف، ڪارپوريٽ بيڪ اپ سسٽم جا سپلائرز (Veeam، Veritas، Commvault) جيتوڻيڪ اهي PostgreSQL کي سپورٽ ڪن ٿا، حقيقت ۾ اهي صرف هڪ خاص (عام طور تي اسٽينڊل) ترتيب سان ڪم ڪن ٿا ۽ مختلف پابندين جي سيٽ سان.
بيڪ اپ سسٽم خاص طور تي PostgreSQL لاءِ ٺهيل آهن، جهڙوڪ Barman, Wal-g, pg_probackup، انتهائي مقبول آهن PostgreSQL DBMS جي ننڍين تنصيبن ۾ يا جتي آئي ٽي لينڊ اسڪيپ جي ٻين عنصرن جي ڳري بيڪ اپ جي ضرورت ناهي. مثال طور، PostgreSQL کان علاوه، انفراسٽرڪچر ۾ جسماني ۽ ورچوئل سرور شامل ٿي سگھي ٿو، OpenShift، Oracle، MariaDB، Cassandra، وغيره. اهو سڀ ڪجهه هڪ عام اوزار سان بيڪ اپ ڪرڻ جي صلاح ڏني آهي. هڪ الڳ حل انسٽال ڪرڻ خاص طور تي PostgreSQL لاءِ هڪ خراب خيال آهي: ڊيٽا کي نقل ڪيو ويندو ڪنهن هنڌ ڊسڪ تي، ۽ پوءِ ان کي هٽائڻ جي ضرورت پوندي ٽيپ ڪرڻ لاءِ. هي ڊبل بيڪ اپ وڌائي ٿو بيڪ اپ وقت، ۽ پڻ، وڌيڪ نازڪ طور تي، وصولي وقت.
هڪ انٽرنيشنل حل ۾، تنصيب جو بيڪ اپ هڪ مخصوص ڪلستر ۾ نوڊس جي هڪ خاص تعداد سان ٿئي ٿو. ساڳئي وقت، مثال طور، Commvault صرف ٻن نوڊ ڪلستر سان ڪم ڪري سگهي ٿو، جنهن ۾ پرائمري ۽ سيڪنڊري سختي سان مخصوص نوڊس کي لڳايو ويو آهي. ۽ اهو صرف پرائمري کان بيڪ اپ ڪرڻ جو احساس رکي ٿو، ڇو ته سيڪنڊري کان بيڪ اپ جون حدون آهن. DBMS جي خاصيتن جي ڪري، ثانوي تي ڊمپ پيدا نه ڪيو ويو آهي، ۽ تنهن ڪري صرف فائل جي بيڪ اپ جو امڪان رهي ٿو.
گھٽتائي جي خطري کي گھٽائڻ لاءِ، جڏھن غلطي برداشت ڪرڻ وارو نظام ٺاھيو ويندو آھي، ھڪ ”لائيو“ ڪلسٽر ٺاھ جوڙ ٺاھيو ويندو آھي، ۽ پرائمري کي مختلف سرورن جي وچ ۾ ھلائي سگھي ٿو. مثال طور، Patroni سافٽ ويئر پاڻ شروع ڪري ٿو پرائمري کي بي ترتيب چونڊيل ڪلستر نوڊ تي. IBS وٽ ڪوبه طريقو ناهي ته هن کي باڪس مان ٽريڪ ڪرڻ لاء، ۽ جيڪڏهن ترتيب تبديل ٿئي ٿي، پروسيس ٽوڙي ٿو. اهو آهي، ٻاهرين ڪنٽرول جو تعارف ISR کي مؤثر طريقي سان ڪم ڪرڻ کان روڪي ٿو، ڇاڪاڻ ته ڪنٽرول سرور صرف اهو نه ٿو سمجهي ته ڪٿي ۽ ڪهڙي ڊيٽا کي نقل ڪرڻ جي ضرورت آهي.
ٻيو مسئلو پوسٽ گريس ۾ بيڪ اپ تي عمل درآمد آهي. اهو ممڪن آهي ڊمپ ذريعي، ۽ اهو ڪم ڪري ٿو ننڍن ڊيٽابيس تي. پر وڏي ڊيٽابيس ۾، ڊمپ هڪ ڊگهو وقت وٺندو آهي، ڪيترن ئي وسيلن جي ضرورت آهي ۽ ڊيٽابيس جي مثال جي ناڪامي جي ڪري سگھي ٿو.
فائل بيڪ اپ صورتحال کي درست ڪري ٿو، پر وڏي ڊيٽابيس تي اهو سست آهي ڇو ته اهو اڪيلو ٿريڊ موڊ ۾ ڪم ڪري ٿو. ان کان علاوه، وينڊرز وٽ ڪيترائي اضافي پابنديون آھن. يا ته توهان هڪ ئي وقت فائل ۽ ڊمپ بيڪ اپ استعمال نٿا ڪري سگهو، يا نقل ڪرڻ جي سهولت نه آهي. اتي ڪيترائي مسئلا آھن، ۽ اڪثر ڪري اھو آسان آھي ھڪڙو قيمتي پر ثابت ٿيل ڊي بي ايم ايس چونڊڻ بدران پوسٽ گريس.
پوئتي هٽڻ لاءِ ڪٿي به ناهي! ماسڪو ڊولپرز پويان آهن!
بهرحال، تازو اسان جي ٽيم کي هڪ مشڪل چئلينج کي منهن ڏيڻو پيو: AIS OSAGO 2.0 ٺاهڻ جي منصوبي ۾، جتي اسان آئي ٽي انفراسٽرڪچر ٺاهيو، ڊولپرن نئين سسٽم لاءِ PostgreSQL چونڊيو.
وڏي سافٽ ويئر ڊولپرز لاءِ ”رجحان“ اوپن سورس حل استعمال ڪرڻ تمام آسان آهي. Facebook وٽ ڪافي ماهر آھن جيڪي ھن ڊي بي ايم ايس جي آپريشن کي سپورٽ ڪن. ۽ RSA جي صورت ۾، "ٻئي ڏينهن" جا سڀ ڪم اسان جي ڪلهن تي ڪري پيا. اسان کي ضرورت هئي ته غلطي رواداري کي يقيني بڻائڻ، هڪ ڪلستر گڏ ڪرڻ ۽، يقينا، بيڪ اپ قائم ڪرڻ. عمل جي منطق هن ريت هئي:
- SRK کي سيکاريو ته ڪلستر جي پرائمري نوڊ مان بيڪ اپ ٺاهڻ. هن کي ڪرڻ لاءِ، SRK کي ان کي ڳولڻ گهرجي - جنهن جو مطلب آهي هڪ يا ٻئي PostgreSQL ڪلسٽر مئنيجمينٽ حل سان انضمام جي ضرورت آهي. RSA جي صورت ۾، Patroni سافٽ ويئر ان لاء استعمال ڪيو ويو.
- ڊيٽا جي مقدار ۽ وصولي جي ضرورتن جي بنياد تي بيڪ اپ جي قسم تي فيصلو ڪريو. مثال طور، جڏهن توهان صفحن کي گرينولر طور تي بحال ڪرڻ جي ضرورت آهي، ڊمپ استعمال ڪريو، ۽ جيڪڏهن ڊيٽابيس وڏا آهن ۽ گرينولر بحالي جي ضرورت ناهي، فائل سطح تي ڪم ڪريو.
- ملٽي ٿريڊ موڊ ۾ بيڪ اپ ڪاپي ٺاهڻ لاءِ حل ۾ بلاڪ بيڪ اپ جو امڪان شامل ڪريو.
ساڳئي وقت، اسان شروعاتي طور تي هڪ مؤثر ۽ سادي سسٽم ٺاهڻ لاء مقرر ڪيو آهي بغير اضافي اجزاء جي زبردستي استعمال جي. گهٽ ڪرچ، عملي تي گهٽ ڪم لوڊ ۽ IBS ناڪامي جو گهٽ خطرو. اسان فوري طور تي نڪتل طريقا جيڪي ويم ۽ RMAN استعمال ڪيا آهن، ڇاڪاڻ ته ٻن حلن جو هڪ سيٽ اڳ ۾ ئي سسٽم جي ناقابل اعتبار تي اشارو ڪري ٿو.
ڪاروبار لاء ٿورو جادو
تنهن ڪري، اسان کي قابل اعتماد بيڪ اپ جي ضمانت ڏيڻ جي ضرورت آهي 10 ڪلسٽرز جي 3 نوڊس هر هڪ، ساڳئي انفراسٽرڪچر سان گڏ بيڪ اپ ڊيٽا سينٽر ۾ آئيني طور تي. PostgreSQL جي لحاظ کان ڊيٽا مرڪز فعال-غير فعال اصول تي ڪم ڪن ٿا. ڪل ڊيٽابيس سائيز 50 TB هئي. ڪو به ڪارپوريٽ-سطح ڪنٽرول نظام آساني سان هن کي منهن ڏئي سگهي ٿو. پر غار اهو آهي ته شروعاتي طور تي پوسٽ گريس کي بيڪ اپ سسٽم سان مڪمل ۽ گہرے مطابقت لاءِ ڪو اشارو نه آهي. تنهن ڪري، اسان کي هڪ حل ڳولڻو پوندو جيڪو شروعاتي طور تي PostgreSQL سان گڏ وڌ ۾ وڌ ڪارڪردگي هجي، ۽ سسٽم کي بهتر بڻائي.
اسان 3 اندروني "هيڪٿون" منعقد ڪيا - اسان پنجاهه کان وڌيڪ ترقيات کي ڏٺو، انهن کي جانچيو، اسان جي مفروضن جي سلسلي ۾ تبديليون ڪيون، ۽ انهن کي ٻيهر آزمايو. دستياب اختيارن جو جائزو وٺڻ کان پوء، اسان چونڊيو Commvault. دٻي کان ٻاهر، هي پراڊڪٽ آسان ترين PostgreSQL ڪلستر تنصيب سان ڪم ڪري سگهي ٿو، ۽ ان جي کليل آرڪيٽيڪچر ڪامياب ترقي ۽ انضمام لاءِ اميدون (جيڪي درست ڪيون ويون) وڌيون. Commvault پڻ بيڪ اپ ڪري سگھي ٿو PostgreSQL لاگ. مثال طور، Veritas NetBackup PostgreSQL جي لحاظ کان صرف مڪمل بيڪ اپ ڪري سگھي ٿو.
فن تعمير بابت وڌيڪ اصطلاح. Commvault مينيجمينٽ سرور نصب ڪيا ويا ھر ھڪ ٻن ڊيٽا سينٽرن ۾ CommServ HA ترتيب ۾. سسٽم آئيني آهي، هڪ ڪنسول ذريعي منظم ڪيو ويو آهي ۽، HA نقطي نظر کان، سڀني انٽرنيشنل گهرجن کي پورو ڪري ٿو.
اسان هر ڊيٽا سينٽر ۾ ٻه فزيڪل ميڊيا سرور پڻ شروع ڪيا، جن سان اسان ڳنڍيو ڊسڪ صفن ۽ ٽيپ لائبريرين کي خاص طور تي بيڪ اپ لاءِ وقف ڪيل SAN ذريعي فائبر چينل ذريعي. توسيع ٿيل ڊيپليڪيشن ڊيٽابيس ميڊيا سرورز جي غلطي رواداري کي يقيني بڻائي، ۽ هر سرور کي هر CSV سان ڳنڍڻ مسلسل آپريشن کي فعال ڪيو جيڪڏهن ڪو جزو ناڪام ٿيو. سسٽم آرڪيٽيڪچر بيڪ اپ کي جاري رکڻ جي اجازت ڏئي ٿو جيتوڻيڪ ڊيٽا سينٽرن مان هڪ پوي ٿو.
Patroni هر ڪلستر لاء هڪ پرائمري نوڊ بيان ڪري ٿو. اهو ڊيٽا سينٽر ۾ ڪنهن به مفت نوڊ ٿي سگهي ٿو - پر صرف اڪثر. بيڪ اپ ۾، سڀ نوڊس ثانوي آھن.
Commvault لاءِ سمجھڻ لاءِ ته ڪھڙو ڪلستر نوڊ پرائمري آھي، اسان پوسٽ گريس سان سسٽم (حل جي کليل فن تعمير جي مھرباني) کي ضم ڪيو. هن مقصد لاء، هڪ اسڪرپٽ ٺاهي وئي جيڪا پرائمري نوڊ جي موجوده جڳهه کي Commvault مئنيجمينٽ سرور ڏانهن رپورٽ ڪري ٿي.
عام طور تي، عمل هن طرح نظر اچي ٿو:
Patroni پرائمري کي منتخب ڪري ٿو → Keepalived IP ڪلسٽر کي کڻي ٿو ۽ اسڪرپٽ هلائي ٿو → Commvault ايجنٽ چونڊيل ڪلسٽر نوڊ تي هڪ نوٽيفڪيشن حاصل ڪري ٿو ته هي پرائمري → Commvault خودڪار طريقي سان pseudo-client جي اندر بيڪ اپ کي ٻيهر ترتيب ڏئي ٿو.
هن طريقي جو فائدو اهو آهي ته حل مستقل مزاجي، لاگز جي درستگي، يا پوسٽ گريس مثال جي وصولي تي اثر انداز نٿو ڪري. اهو پڻ آساني سان اسڪيلبل آهي، ڇاڪاڻ ته اهو هاڻي ضروري ناهي ته Commvault پرائمري ۽ سيڪنڊري نوڊس کي درست ڪرڻ لاء. اهو ڪافي آهي ته سسٽم سمجهي ٿو جتي پرائمري آهي، ۽ نوڊس جو تعداد تقريبا ڪنهن به قدر تائين وڌائي سگهجي ٿو.
حل مثالي ٿيڻ جو مظاهرو نٿو ڪري ۽ ان جي پنهنجي nuances آهي. Commvault صرف سڄي مثال جو بيڪ اپ ڪري سگھي ٿو، ۽ انفرادي ڊيٽابيس نه. تنهن ڪري، هر ڊيٽابيس لاء هڪ الڳ مثال ٺاهي وئي. حقيقي گراهڪ ورچوئل pseudo-ڪلائنٽ ۾ گڏيل آهن. هر Commvault pseudo-client هڪ UNIX ڪلستر آهي. اهي ڪلسٽر نوڊس جن تي Commvault ايجنٽ for Postgres انسٽال ٿيل آهي ان ۾ شامل ڪيا ويا آهن. نتيجي طور، pseudo-client جي سڀني مجازي نوڊس هڪ مثال طور پٺتي پيل آهن.
هر pseudo-client جي اندر، ڪلستر جو فعال نوڊ اشارو ڪيو ويو آهي. اھو اھو آھي جيڪو اسان جي انضمام حل لاءِ Commvault وضاحت ڪري ٿو. ان جي آپريشن جو اصول بلڪل سادو آهي: جيڪڏهن ڪو ڪلسٽر IP ڪنهن نوڊ تي اٿاريو وڃي ٿو، ته اسڪرپٽ سيٽ ڪندو آهي ”فعال نوڊ“ پيٽرول کي Commvault ايجنٽ بائنري ۾- حقيقت ۾، اسڪرپٽ ميموري جي گهربل حصي ۾ “1” سيٽ ڪري ٿي. . ايجنٽ هن ڊيٽا کي CommServe ڏانهن منتقل ڪري ٿو، ۽ Commvault گهربل نوڊ مان بيڪ اپ ٺاهي ٿو. ان کان علاوه، ترتيب جي درستي کي اسڪرپٽ سطح تي چيڪ ڪيو ويو آهي، بيڪ اپ شروع ڪرڻ دوران غلطين کان بچڻ ۾ مدد ڪندي.
ساڳئي وقت، وڏي ڊيٽابيس ڪيترن ئي موضوعن ۾ بلاڪ ۾ بيڪ اپ ڪيا ويا آهن، آر پي او ۽ بيڪ اپ ونڊو گهرجن کي پورو ڪرڻ. سسٽم تي لوڊ غير معمولي آهي: مڪمل ڪاپيون اڪثر نه ٿينديون آهن، ٻين ڏينهن تي صرف لاگ گڏ ڪيا ويندا آهن، ۽ گهٽ لوڊ جي عرصي دوران.
رستي ۾، اسان PostgreSQL آرڪائيو لاگز کي بيڪ اپ ڪرڻ لاءِ الڳ پاليسيون لاڳو ڪيون آهن - اهي مختلف قاعدن مطابق ذخيرو ٿيل آهن، مختلف شيڊول موجب نقل ڪيون ويون آهن، ۽ انهن لاءِ نقل نه ڪئي وئي آهي، ڇاڪاڻ ته اهي لاگ ان منفرد ڊيٽا تي مشتمل آهن.
پوري IT انفراسٽرڪچر ۾ مستقل مزاجي کي يقيني بڻائڻ لاءِ، هر هڪ ڪلسٽر نوڊس تي الڳ Commvault فائل ڪلائنٽ انسٽال ٿيل آهن. اهي پوسٽ گريس فائلن کي بيڪ اپ مان خارج ڪن ٿا ۽ صرف او ايس ۽ ايپليڪيشن بيڪ اپ لاءِ آهن. ڊيٽا جو هي حصو پڻ پنهنجي پاليسي ۽ اسٽوريج جي مدت آهي.
في الحال، IBS پيداوار جي خدمتن کي متاثر نٿو ڪري، پر جيڪڏهن صورتحال تبديل ٿئي ٿي، Commvault لوڊ محدود ڪرڻ کي چالو ڪري سگهي ٿو.
ڇا اهو سٺو آهي؟ سٺو!
تنهن ڪري، اسان حاصل ڪيو آهي نه صرف هڪ قابل عمل، پر هڪ مڪمل طور تي خودڪار بيڪ اپ هڪ PostgreSQL ڪلستر تنصيب لاء، ۽ اهو انٽرنيشنل ڪالن لاء سڀني گهرجن کي پورو ڪري ٿو.
1 ڪلاڪ ۽ 2 ڪلاڪ جي آر پي او ۽ آر ٽي او پيرا ميٽرز هڪ مارجن سان ڍڪيل آهن، جنهن جو مطلب آهي ته سسٽم انهن جي تعميل ڪندو جيتوڻيڪ ذخيرو ٿيل ڊيٽا جي مقدار ۾ هڪ اهم اضافو سان. ڪيترن ئي شڪن جي برعڪس، PostgreSQL ۽ ڪاروباري ماحول بلڪل مطابقت رکندڙ ثابت ٿيو. ۽ ھاڻي اسان پنھنجي تجربي مان ڄاڻون ٿا ته اھڙين ڊي بي ايم ايس لاءِ بيڪ اپ مختلف قسمن جي ترتيبن ۾ ممڪن آھي.
يقينن، هن رستي تي اسان کي لوهه جي بوٽن جا ست جوڙا پائڻا هئا، ڪيترن ئي مشڪلاتن تي قابو پائڻ، ڪيترن ئي ريڪن تي قدم کڻڻ ۽ ڪيترن ئي غلطين کي درست ڪرڻو پوندو. پر هاڻي اهو طريقو اڳ ۾ ئي آزمائي چڪو آهي ۽ استعمال ڪري سگهجي ٿو اوپن سورس کي لاڳو ڪرڻ لاءِ مالڪي DBMS جي بدران سخت ڪاروباري حالتن ۾.
ڇا توهان ڪارپوريٽ ماحول ۾ PostgreSQL سان ڪم ڪرڻ جي ڪوشش ڪئي آهي؟
ليکڪ:
Oleg Lavrenov، ڊيٽا اسٽوريج سسٽم جو ڊيزائن انجنيئر، جيٽ انفو سسٽم
دمتري ايريڪن، جيٽ انفو سسٽم ۾ ڪمپيوٽر سسٽم جو ڊيزائن انجنيئر
جو ذريعو: www.habr.com