هيلو، Khabrovsk جي رهاڪن. ڪورس جي پهرين گروپ ۾ ڪلاس اڄ شروع ٿيندا . ان سلسلي ۾، اسان توهان کي ٻڌائڻ چاهيون ٿا ته هن ڪورس تي اوپن ويبينار ڪيئن ٿي.
В اسان بادل ۽ ڪبرنيٽس جي دور ۾ SQL ڊيٽابيس کي منهن ڏيڻ وارن چئلينجن بابت ڳالهايو. ساڳئي وقت، اسان ڏٺو ته ڪيئن SQL ڊيٽابيس انهن چئلينجن جي اثر هيٺ موافقت ۽ ميوٽيٽ ڪيو.
ويبينار منعقد ڪيو ويو , Google Cloud Practice Delivery Manager at EPAM Systems.
جڏهن وڻ ننڍا هئا...
پهرين، اچو ته ياد رکون ته گذريل صديء جي آخر ۾ ڊي بي ايم ايس جي چونڊ ڪيئن شروع ٿي. بهرحال، اهو ڏکيو نه ٿيندو، ڇاڪاڻ ته انهن ڏينهن ۾ ڊي بي ايم ايس جو انتخاب شروع ٿيو ۽ ختم ٿي ويو Oracle.
90 جي ڏهاڪي جي آخر ۾ ۽ 2 جي شروعات ۾، بنيادي طور تي ڪو به اختيار نه هو جڏهن اهو اچي ٿو صنعتي اسپيبلبل ڊيٽابيسس. ها، اتي IBM DBXNUMX، Sybase ۽ ڪجهه ٻيا ڊيٽابيس هئا جيڪي آيا ۽ ويا، پر عام طور تي اهي Oracle جي پس منظر جي خلاف ايترو قابل ذڪر نه هئا. ان جي مطابق، ان وقت جي انجنيئرن جي صلاحيتن کي ڪنهن به صورت ۾ موجود صرف پسند سان ڳنڍيل هئا.
Oracle DBA ڪرڻ جي قابل هوندو هو:
- ورهائڻ واري کٽ مان Oracle سرور انسٽال ڪريو؛
- Oracle سرور ترتيب ڏيو:
- init.ora؛
- listener.ora؛
- ٺاھڻ:
- ٽيبل اسپيس؛
- اسڪيمون؛
- استعمال ڪندڙ؛
- بيڪ اپ ۽ بحال ڪريو؛
- نگراني ڪرڻ؛
- ذيلي مناسب درخواستن سان ڊيل ڪريو.
ساڳئي وقت، Oracle DBA کان ڪا خاص ضرورت نه هئي:
- ڊيٽا کي محفوظ ڪرڻ ۽ پروسيسنگ لاءِ بهترين ڊي بي ايم ايس يا ٻي ٽيڪنالاجي چونڊڻ جي قابل ٿي؛
- اعلي دستيابي ۽ افقي اسڪاليبلٽي مهيا ڪريو (اهو هميشه DBA مسئلو نه هو)؛
- مضمون جي سٺي ڄاڻ، انفراسٽرڪچر، ايپليڪيشن آرڪيٽيڪچر، او ايس؛
- ڊيٽا لوڊ ۽ لوڊ ڪريو، مختلف ڊي بي ايم ايس جي وچ ۾ ڊيٽا کي منتقل ڪريو.
عام طور تي، جيڪڏهن اسان انهن ڏينهن ۾ پسند جي باري ۾ ڳالهايون ٿا، اهو 80s جي آخر ۾ سوويت جي دڪان ۾ پسند وانگر آهي:
اسان جو وقت
ان وقت کان وٺي، يقينا، وڻ وڌيا آهن، دنيا بدلجي وئي آهي، ۽ اهو ڪجهه هن طرح ٿيو:
ڊي بي ايم ايس مارڪيٽ پڻ تبديل ٿي چڪو آهي، جيئن واضح طور تي ڏسي سگهجي ٿو گارٽنر جي تازي رپورٽ مان:
۽ هتي اهو ياد رکڻ گهرجي ته بادل، جن جي مقبوليت وڌي رهي آهي، انهن جي جڳهه تي قبضو ڪيو آهي. جيڪڏهن اسان ساڳئي گارٽنر جي رپورٽ کي پڙهون ٿا، اسان هيٺ ڏنل نتيجن کي ڏسندا سين:
- ڪيترائي گراهڪ بادل ڏانهن ايپليڪيشنن کي منتقل ڪرڻ جي رستي تي آهن.
- نئين ٽيڪنالاجيون پهريون ڀيرو بادل ۾ ظاهر ٿيندا آهن ۽ اها حقيقت ناهي ته اهي ڪڏهن به غير ڪلائوڊ انفراسٽرڪچر ڏانهن منتقل ٿيندا.
- ادا-جيئن-توهان-وڃڻ وارو نمونو عام ٿي چڪو آهي. هرڪو چاهي ٿو ادا ڪرڻ صرف ان لاءِ جيڪو هو استعمال ڪن ٿا، ۽ اهو به هڪ رجحان نه آهي، پر صرف حقيقت جو بيان.
ھاڻ ڇا؟
اڄ اسان سڀ بادل ۾ آهيون. ۽ سوال جيڪي اسان لاءِ پيدا ٿين ٿا اهي چونڊ جا سوال آهن. ۽ اهو تمام وڏو آهي، جيتوڻيڪ جيڪڏهن اسان صرف ڊي بي ايم ايس ٽيڪنالاجيز جي چونڊ جي باري ۾ ڳالهايون ٿا آن-پريمسس فارميٽ ۾. اسان پڻ منظم ڪيل خدمتون ۽ SaaS. اهڙيء طرح، چونڊ صرف هر سال وڌيڪ ڏکيو ٿيندو.
چونڊ جي سوالن سان گڏ، اتي پڻ آهن محدود عنصر:
- قيمت. ڪيتريون ئي ٽيڪنالاجيون اڃا تائين پئسا خرچ ڪن ٿا.
- صلاحيتون. جيڪڏهن اسان مفت سافٽ ويئر جي ڳالهه ڪري رهيا آهيون، ته پوءِ مهارتن جو سوال پيدا ٿئي ٿو، ڇو ته مفت سافٽ ويئر کي انهن ماڻهن کان ڪافي صلاحيت جي ضرورت آهي جيڪي ان کي ترتيب ڏيڻ ۽ هلائڻ وارا آهن؛
- فعال. نه سڀئي خدمتون جيڪي ڪلائوڊ ۾ موجود آهن ۽ ٺاهيل آهن، چئو، ايستائين ساڳئي پوسٽ گريس تي، ساڳيون خاصيتون آهن پوسٽ گريس آن-پريمسس. اهو هڪ لازمي عنصر آهي جنهن کي ڄاڻڻ ۽ سمجهڻ جي ضرورت آهي. ان کان علاوه، هي عنصر هڪ واحد DBMS جي ڪجهه لڪيل صلاحيتن جي ڄاڻ کان وڌيڪ اهم ٿي ويندو آهي.
هاڻي DA/DE کان ڇا توقع آهي:
- موضوع واري علائقي ۽ ايپليڪيشن فن تعمير جي سٺي ڄاڻ؛
- صحيح طور تي مناسب ڊي بي ايم ايس ٽيڪنالاجي کي چونڊڻ جي صلاحيت، ڪم کي هٿ ۾ کڻڻ؛
- موجوده حدن جي تناظر ۾ چونڊيل ٽيڪنالاجي کي لاڳو ڪرڻ لاء بهترين طريقو چونڊڻ جي صلاحيت؛
- ڊيٽا جي منتقلي ۽ لڏپلاڻ ڪرڻ جي صلاحيت؛
- منتخب ٿيل حل کي لاڳو ڪرڻ ۽ هلائڻ جي صلاحيت.
هيٺيون مثال GCP جي بنياد تي اهو ظاهر ڪري ٿو ته ڊيٽا سان ڪم ڪرڻ لاء هڪ يا ٻئي ٽيڪنالاجي جو انتخاب ان جي جوڙجڪ تي منحصر ڪري ٿو:
مهرباني ڪري نوٽ ڪريو ته PostgreSQL اسڪيما ۾ شامل نه آهي، ۽ اهو ئي سبب آهي ته اهو اصطلاحن هيٺ لڪيل آهي ڪلائوڊ SQL. ۽ جڏهن اسان Cloud SQL ڏانهن وڃون ٿا، اسان کي ٻيهر چونڊڻ جي ضرورت آهي:
اهو ياد رکڻ گهرجي ته هي اختيار هميشه واضح ناهي، تنهنڪري ايپليڪيشن ڊولپرز اڪثر ڪري وجدان جي رهنمائي ڪندا آهن.
Total:
- وڌيڪ توهان اڳتي وڌو، وڌيڪ دٻايو انتخاب جو سوال. ۽ جيتوڻيڪ جيڪڏهن توهان صرف GCP، منظم ڪيل خدمتون ۽ SaaS تي نظر اچن ٿا، پوء RDBMS جو ڪجهه ذڪر صرف 4th قدم تي ظاهر ٿئي ٿو (۽ اتي اسپنر ويجھو آهي). ان سان گڏ، PostgreSQL جو انتخاب 5 هين قدم ۾ ظاهر ٿئي ٿو، ۽ ان جي اڳيان پڻ MySQL ۽ SQL سرور آهن، اهو آهي اتي تمام گهڻو آهي، پر توهان کي چونڊڻ گهرجي.
- اسان کي آزمائش جي پس منظر جي خلاف پابنديون نه وسارڻ گهرجي. بنيادي طور تي هرڪو اسپنر چاهي ٿو، پر اهو مهانگو آهي. نتيجي طور، هڪ عام درخواست هن طرح ڪجهه ڏسڻ ۾ اچي ٿو: "مهرباني ڪري اسان کي اسپنر ٺاهيو پر ڪلائوڊ SQL جي قيمت لاءِ، توهان پروفيسر آهيو!"
اسان کي ڇا ڪرڻ گهرجي؟
حتمي سچ هجڻ جي دعويٰ ڪرڻ کان سواءِ، اچو ته هيٺين کي چئون:
اسان کي سکڻ لاء اسان جي انداز کي تبديل ڪرڻ جي ضرورت آهي:
- سيکارڻ جو ڪو به مطلب ناهي ته جيئن ڊي بي اي کي اڳ ۾ سيکاريو ويندو هو؛
- هڪ پيداوار جي ڄاڻ هاڻي ڪافي نه آهي؛
- پر هڪ جي سطح تي درجنين کي ڄاڻڻ ناممڪن آهي.
توهان کي نه رڳو ڄاڻڻ جي ضرورت آهي ۽ نه پراڊڪٽ ڪيترو آهي، پر:
- ان جي درخواست جي صورت ۾ استعمال؛
- مختلف لڳائڻ جا طريقا؛
- هر طريقي جي فائدن ۽ نقصان؛
- هڪجهڙا ۽ متبادل پراڊڪٽس هڪ باخبر ۽ بهترين چونڊ ڪرڻ لاءِ ۽ نه هميشه هڪ واقف پيداوار جي حق ۾.
توهان کي ڊيٽا کي لڏپلاڻ ڪرڻ ۽ ETL سان انضمام جي بنيادي اصولن کي سمجهڻ جي ضرورت پڻ آهي.
حقيقي ڪيس
تازو ماضي ۾، اهو ضروري هو ته موبائل ايپليڪيشن لاء هڪ پس منظر ٺاهيو. جڏهن ته ان تي ڪم شروع ڪيو ويو، پس منظر اڳ ۾ ئي ترقي ڪئي وئي هئي ۽ عملدرآمد لاء تيار هئي، ۽ ترقياتي ٽيم هن منصوبي تي تقريبا ٻه سال گذاريا. هيٺيان ڪم مقرر ڪيا ويا:
- CI/CD تعمير ڪريو؛
- فن تعمير جو جائزو وٺو؛
- اهو سڀ ڪم ۾ وجهي.
ايپليڪيشن پاڻ مائڪرو سروسز هئي، ۽ Python/Jjango ڪوڊ ترقي يافته کان شروع ڪيو ويو ۽ سڌو GCP ۾. جيئن ته حدف ٿيل سامعين لاء، اهو فرض ڪيو ويو ته اتي ٻه علائقا هوندا - يو ايس ۽ اي يو، ۽ ٽرئفڪ کي گلوبل لوڊ بيلنس ذريعي ورهايو ويو. سڀئي ڪم لوڊ ۽ ڪمپيوٽ ڪم لوڊ Google Kubernetes Engine تي هليا.
ڊيٽا جي طور تي، اتي 3 جوڙجڪ هئا:
- Cloud Storage؛
- ڊيٽا اسٽور؛
- Cloud SQL (PostgreSQL).
ھڪڙو حيران ٿي سگھي ٿو ڇو Cloud SQL چونڊيو ويو آھي؟ سچ ٻڌائڻ لاء، اهڙي سوال گذريل سالن ۾ ڪجهه قسم جي بيچيني توقف جو سبب بڻيا آهن - هڪ احساس اهو آهي ته ماڻهو لاڳاپا ڊيٽابيس بابت شرما ٿي ويا آهن، پر ان جي باوجود اهي انهن کي فعال طور تي استعمال ڪرڻ جاري رکندا آهن ؛-).
اسان جي صورت ۾، Cloud SQL کي هيٺين سببن لاء چونڊيو ويو:
- جيئن ذڪر ڪيو ويو آهي، ايپليڪيشن Django استعمال ڪندي ترقي ڪئي وئي هئي، ۽ اهو هڪ ماڊل آهي مسلسل ڊيٽا کي ميپ ڪرڻ لاء هڪ SQL ڊيٽابيس کان پائٿون آبجڪس (Jjango ORM).
- فريم ورڪ پاڻ کي سپورٽ ڪئي ڊي بي ايم ايس جي ڪافي محدود فهرست:
- PostgreSQL؛
- ماريا ڊي بي؛
- MySQL؛
- اوريڪل؛
- SQLite.
ان جي مطابق، PostgreSQL هن فهرست مان چونڊيو ويو بلڪه سمجهه سان (چڱو، اهو چونڊڻ لاء Oracle ناهي، واقعي).
ڇا غائب هو:
- اپليڪيشن صرف 2 علائقن ۾ لڳايو ويو، ۽ 3rd هڪ منصوبن ۾ ظاهر ٿيو (ايشيا)؛
- ڊيٽابيس اتر آمريڪي علائقي (آئوا) ۾ واقع هو؛
- ڪسٽمر جي حصي تي ممڪن بابت خدشا هئا دير تائين رسائي يورپ ۽ ايشيا کان ۽ رڪاوٽون خدمت ۾ DBMS بند وقت جي صورت ۾.
ان حقيقت جي باوجود ته جينگو پاڻ ڪيترن ئي ڊيٽابيس سان گڏ ڪم ڪري سگهي ٿو ۽ انهن کي پڙهڻ ۽ لکڻ ۾ ورهائي سگهي ٿو، ايپليڪيشن ۾ ايترو گهڻو لکڻ نه هو (90٪ کان وڌيڪ پڙهي رهيو آهي). ۽ عام طور تي، ۽ عام طور تي، جيڪڏهن اهو ممڪن هو يورپ ۽ ايشيا ۾ مکيه بنياد جي ريپليڪا، اهو هڪ سمجھوتي حل هوندو. خير، ان جي باري ۾ ايترو پيچيده ڇا آهي؟
ڏکيائي اها هئي ته گراهڪ منظم ڪيل خدمتون ۽ Cloud SQL استعمال ڪرڻ ڇڏي ڏيڻ نه چاهيندو هو. ۽ Cloud SQL جون صلاحيتون في الحال محدود آهن. Cloud SQL سپورٽ ڪري ٿو اعلي دستيابي (HA) ۽ ريپليڪا (RR)، پر ساڳئي RR صرف ھڪڙي علائقي ۾ سپورٽ آھي. آمريڪي علائقي ۾ ڊيٽابيس ٺاهي، توهان Cloud SQL استعمال ڪندي يورپي علائقي ۾ پڙهڻ واري نقل نه ٿا ڪري سگهو، جيتوڻيڪ پوسٽ گريس پاڻ توهان کي ائين ڪرڻ کان روڪي نه ٿو. گوگل ملازمن سان خط و ڪتابت ڪٿي به نه ٿي ۽ واعدن سان ختم ٿي وئي “اسان مسئلي کي ڄاڻون ٿا ۽ ان تي ڪم ڪري رهيا آهيون، هڪ ڏينهن اهو مسئلو حل ٿي ويندو.”
جيڪڏهن اسان مختصر طور تي Cloud SQL جي صلاحيتن کي لسٽ ڪريون ٿا، اهو ڪجهه هن طرح نظر ايندو:
1. اعلي دستيابي (HA):
- هڪ علائقي اندر؛
- ڊسڪ جي نقل ذريعي؛
- PostgreSQL انجڻ استعمال نه ڪيا ويا آهن؛
- خودڪار ۽ دستياب ڪنٽرول ممڪن - ناڪامي / ناڪامي؛
- جڏهن سوئچنگ، DBMS ڪيترن ئي منٽن لاء دستياب ناهي.
2. ريپليڪا پڙهو (آر آر):
- هڪ علائقي اندر؛
- گرم اسٽينڊ بائي؛
- PostgreSQL اسٽريمنگ نقل.
اضافي طور تي، جيئن رواج آهي، جڏهن هڪ ٽيڪنالاجي چونڊيو توهان هميشه ڪجهه سان منهن ڪيو آهي پابنديون:
- گراهڪ نه ٿي چاهيو ته ادارا ٺاهي ۽ IaaS استعمال ڪن، سواءِ GKE جي ذريعي؛
- گراهڪ نه چاهيندو ته سيلف سروس PostgreSQL/MySQL مقرر ڪرڻ؛
- خير، عام طور تي، گوگل اسپنر بلڪل مناسب هوندو جيڪڏهن اهو ان جي قيمت لاءِ نه هجي ها، جڏهن ته، جيانگو ORM ان سان ڪم نٿو ڪري سگهي، پر اها سٺي ڳالهه آهي.
صورتحال تي غور ڪندي، گراهڪ هڪ فالو اپ سوال حاصل ڪيو: ”ڇا توھان ڪجھھ ائين ڪري سگھوٿا ته جيئن اھو گوگل اسپنر وانگر ھجي، پر Django ORM سان پڻ ڪم ڪري سگھي ٿو؟
حل اختيار نمبر 0
پهرين شيء جيڪا ذهن ۾ آئي:
- CloudSQL اندر رهڻ؛
- ڪنهن به شڪل ۾ علائقن جي وچ ۾ ڪو به تعمير ٿيل نقل نه هوندو؛
- PostgreSQL پاران موجوده Cloud SQL سان نقل ڳنڍڻ جي ڪوشش ڪريو؛
- لانچ ڪريو پوسٽ گري ايس ايس ايل مثال ڪٿي ۽ ڪنهن نه ڪنهن طرح، پر گهٽ ۾ گهٽ ماسٽر کي هٿ نه ڪريو.
افسوس، اهو ظاهر ٿيو ته اهو نه ٿو ڪري سگهجي، ڇاڪاڻ ته ميزبان تائين رسائي ناهي (اهو مڪمل طور تي هڪ مختلف منصوبي ۾ آهي) - pg_hba ۽ انهي تي، ۽ سپر يوزر جي تحت پڻ ڪا رسائي ناهي.
حل اختيار نمبر 1
وڌيڪ غور ۽ فڪر ڪرڻ کان پوءِ پوئين حالتن کي نظر ۾ رکندي، سوچ جي ٽرين ڪجهه بدلجي وئي:
- اسان اڃا تائين CloudSQL ۾ رهڻ جي ڪوشش ڪري رهيا آهيون، پر اسان MySQL ڏانهن رخ ڪري رهيا آهيون، ڇاڪاڻ ته Cloud SQL وٽ MySQL جو هڪ خارجي ماسٽر آهي، جيڪو:
- ٻاهرين MySQL لاءِ هڪ پراڪسي آهي؛
- هڪ MySQL مثال وانگر نظر اچي ٿو؛
- ٻين بادلن يا آن-پريمسس مان ڊيٽا لڏڻ لاءِ ايجاد ڪئي وئي.
MySQL ريپليڪشن کي ترتيب ڏيڻ کان وٺي ميزبان تائين رسائي جي ضرورت ناهي، اصول ۾ سڀ ڪجهه ڪم ڪيو، پر اهو تمام غير مستحڪم ۽ تڪليف هو. ۽ جڏهن اسان اڳتي وڌو، اهو مڪمل طور تي خوفناڪ ٿي ويو، ڇاڪاڻ ته اسان سڄي جوڙجڪ کي ٽيرافارم سان لڳايو، ۽ اوچتو اهو ظاهر ٿيو ته ٻاهرئين ماسٽر ٽيرافارم سان سهڪار نه ڪيو ويو. ها، گوگل وٽ هڪ CLI آهي، پر ڪجهه سببن لاءِ هر شيءِ هتي هر وقت ڪم ڪري رهي آهي - ڪڏهن ڪڏهن اها ٺاهي وئي آهي، ڪڏهن ڪڏهن اها ٺاهي ناهي. شايد ڇاڪاڻ ته CLI ٻاهرين ڊيٽا لڏپلاڻ لاء ايجاد ڪئي وئي هئي، ۽ نقلن لاء نه.
دراصل، هن موقعي تي اهو واضح ٿي ويو آهي ته Cloud SQL بلڪل مناسب ناهي. جيئن اهي چون ٿا، اسان سڀ ڪجهه ڪيو جيڪو اسان ڪري سگهون ٿا.
حل اختيار نمبر 2
جيئن ته Cloud SQL فريم ورڪ ۾ رهڻ ممڪن نه هو، اسان هڪ سمجهوتي حل لاءِ گهرجون تيار ڪرڻ جي ڪوشش ڪئي. گهرجون هيٺيون هيون:
- ڪبرنيٽس ۾ ڪم، وسيلن جو وڌ کان وڌ استعمال ۽ ڪبرنيٽس (DCS، ...) ۽ GCP (LB، ...)؛
- بادل ۾ غير ضروري شين جي هڪ گروپ مان بيلٽ جي کوٽ جهڙوڪ HA پراکسي؛
- مکيه HA علائقي ۾ PostgreSQL يا MySQL هلائڻ جي صلاحيت؛ ٻين علائقن ۾ - مکيه علائقي جي آر آر کان HA ۽ ان جي ڪاپي (اعتماد لاءِ)؛
- ملٽي ماسٽر (مان هن سان رابطو ڪرڻ نه ٿي چاهيو، پر اهو تمام ضروري نه هو)
.
انهن مطالبن جي نتيجي ۾، پيمناسب DBMS ۽ پابند اختيارن:
- MySQL Galera؛
- ڪاڪروچ ڊي بي؛
- PostgreSQL اوزار
:
- pgpool-II؛
- سرپرستي.
MySQL گليرا
MySQL Galera ٽيڪنالاجي Codership پاران ترقي ڪئي وئي ۽ InnoDB لاءِ هڪ پلگ ان آهي. خاصيتون:
- گھڻن ماسٽر؛
- هم وقت سازي جي نقل؛
- ڪنهن به نوڊ کان پڙهڻ؛
- ڪنهن به نوڊ تي رڪارڊنگ؛
- تعمير ٿيل HA ميڪانيزم؛
- بتنامي کان هڪ هيلم چارٽ آهي.
ڪاڪروچ ڊي بي
تفصيل موجب اها شيءِ بلڪل بم آهي ۽ گو ۾ لکيل هڪ اوپن سورس پروجيڪٽ آهي. مکيه حصو وٺندڙ Cockroach Labs (گوگل جي ماڻهن پاران قائم ڪيل) آهي. هي لاڳاپو DBMS اصل ۾ ورهائڻ لاءِ ٺهيل هو (دٻي کان ٻاهر افقي اسڪيلنگ سان) ۽ غلطي برداشت ڪندڙ. ڪمپني مان ان جي ليکڪن جو مقصد بيان ڪيو آهي "SQL ڪارڪردگي جي دولت کي گڏ ڪرڻ سان افقي رسائي سان واقف NoSQL حل."
هڪ سٺو بونس پوسٽ گريس ڪنيڪشن پروٽوڪول لاءِ سپورٽ آهي.
pgpool
اھو ھڪڙو اضافو آھي PostgreSQL تي، حقيقت ۾، ھڪڙو نئون ادارو جيڪو سڀني ڪنيڪشن تي قبضو ڪري ٿو ۽ انھن کي پروسيس ڪري ٿو. ان جو پنهنجو لوڊ بيلنس ۽ پارسر آهي، جيڪو BSD لائسنس تحت لائسنس يافته آهي. اهو ڪافي موقعا فراهم ڪري ٿو، پر ڪجهه خوفناڪ ڏسڻ ۾ اچي ٿو، ڇاڪاڻ ته نئين اداري جي موجودگي ڪجهه اضافي ڪمن جو ذريعو بڻجي سگهي ٿي.
پتروني
هي آخري شيء آهي جنهن تي منهنجي نظر پئجي وئي، ۽ جيئن اهو نڪتو، بيڪار نه. Patroni هڪ اوپن سورس يوٽيليٽي آهي، جيڪو بنيادي طور تي هڪ Python ڊيمون آهي جيڪو توهان کي خودڪار طريقي سان برقرار رکڻ جي اجازت ڏئي ٿو PostgreSQL ڪلسٽرز کي مختلف قسمن جي نقل ۽ خودڪار رول سوئچنگ سان. اها شيء ڏاڍي دلچسپ ٿي چڪي آهي، ڇاڪاڻ ته اهو ڪبر سان چڱي طرح ضم ٿي ويو آهي ۽ ڪنهن به نئين ادارن کي متعارف نٿو ڪري.
آخر توهان ڇا چونڊيو؟
چونڊ آسان نه هئي:
- ڪاڪروچ ڊي بي - باهه، پر اونداهي؛
- MySQL گليرا - پڻ خراب ناهي، اهو ڪيترن ئي هنڌن تي استعمال ٿيندو آهي، پر MySQL؛
- pgpool - تمام گھڻا غير ضروري ادارا، اھڙيءَ طرح بادل ۽ K8s سان انضمام؛
- پتروني - K8s سان شاندار انضمام، ڪو به غير ضروري ادارو، GCP LB سان چڱي طرح ضم ٿي.
اهڙيء طرح، انتخاب Patroni تي ڪري پيو.
پهچڻ
مختصر طور تي بيان ڪرڻ جو وقت آهي. ها، آئي ٽي انفراسٽرڪچر جي دنيا خاص طور تي تبديل ٿي چڪي آهي، ۽ اهو صرف شروعات آهي. ۽ جيڪڏهن بادل کان اڳ صرف هڪ ٻئي قسم جي زيربناء هئا، هاڻي هر شيء مختلف آهي. ان کان سواء، بادلن ۾ جدت مسلسل ظاهر ٿي رهي آهي، اهي ظاهر ٿيندا ۽، شايد، اهي صرف بادلن ۾ ظاهر ٿيندا ۽ صرف تڏهن، شروع ٿيندڙ ڪوششن سان، انهن کي آن پريمسس ڏانهن منتقل ڪيو ويندو.
SQL لاءِ، SQL رھندو. ان جو مطلب اهو آهي ته توهان کي ڄاڻڻ جي ضرورت آهي PostgreSQL ۽ MySQL ۽ انهن سان ڪم ڪرڻ جي قابل ٿي، پر ان کان به وڌيڪ ضروري آهي ته انهن کي صحيح طريقي سان استعمال ڪرڻ جي قابل ٿي.
جو ذريعو: www.habr.com