ناڪامي ڪلستر PostgreSQL + Patroni. عمل درآمد جو تجربو

هن آرٽيڪل ۾ آئون توهان کي ٻڌايان ٿو ته اسان پوسٽ گري ايس ايس ايل جي غلطي رواداري جي مسئلي کي ڪيئن پهچايو، ڇو اهو اسان لاء اهم ٿي ويو، ۽ آخر ۾ ڇا ٿيو.

اسان وٽ تمام گهڻي لوڊ ٿيل سروس آهي: 2,5 ملين استعمال ڪندڙ سڄي دنيا ۾، 50K+ فعال استعمال ڪندڙ هر روز. سرورز آئرلينڊ جي ھڪڙي علائقي ۾ امازون ۾ واقع آھن: 100+ مختلف سرور مسلسل ڪم ۾ آھن، انھن مان لڳ ڀڳ 50 ڊيٽابيس سان.

سڄو پس منظر هڪ وڏو monolithic رياستي جاوا ايپليڪيشن آهي جيڪو ڪلائنٽ سان مسلسل ويب ساکٽ ڪنيڪشن برقرار رکي ٿو. جڏهن ڪيترائي استعمال ڪندڙ هڪ ئي بورڊ تي ڪم ڪن ٿا، اهي سڀئي تبديليون حقيقي وقت ۾ ڏسندا آهن، ڇاڪاڻ ته اسان ڊيٽابيس ۾ هر تبديلي کي رڪارڊ ڪندا آهيون. اسان وٽ تقريبن 10K درخواستون في سيڪنڊ اسان جي ڊيٽابيس ڏانهن. ريڊس ۾ چوٽي لوڊ تي اسان 80-100K درخواستون في سيڪنڊ لکون ٿا.

ڇو اسان تبديل ڪيو Redis کان PostgreSQL ڏانهن

شروعات ۾، اسان جي خدمت Redis سان ڪم ڪيو، هڪ اهم-قيمتي اسٽوريج جيڪو سرور جي رام ۾ سڀني ڊيٽا کي محفوظ ڪري ٿو.

Redis جا فائدا:

1. تيز جواب جي رفتار، ڇاڪاڻ ته هر شيء ياداشت ۾ محفوظ آهي؛
2. آسان بيڪ اپ ۽ نقل.

اسان لاءِ Redis جا نقصان:

1. ڪوبه حقيقي معاملو نه آهي. اسان انهن کي اسان جي درخواست جي سطح تي نقل ڪرڻ جي ڪوشش ڪئي. بدقسمتي سان، اهو هميشه سٺو ڪم نه ڪيو ۽ تمام پيچيده ڪوڊ لکڻ جي ضرورت آهي.
2. ڊيٽا جي مقدار ميموري جي مقدار تائين محدود آهي. جيئن جيئن ڊيٽا جو مقدار وڌندو، تيئن ميموري وڌندي، ۽، آخر ۾، اسين چونڊيل مثال جي خاصيتن ۾ داخل ٿي وينداسين، جن کي AWS ۾ مثال جي قسم کي تبديل ڪرڻ لاءِ اسان جي سروس کي روڪڻ جي ضرورت پوندي.
3. اهو ضروري آهي ته مسلسل گهٽ ويڪرائي واري سطح کي برقرار رکڻ لاء، ڇاڪاڻ ته اسان وٽ درخواستن جو تمام وڏو تعداد آھي. اسان لاءِ 17-20 ايم ايس جي بهترين ويڪرائي سطح آهي. 30-40 ms جي سطح تي، اسان کي اسان جي درخواستن جي درخواستن ۽ خدمت جي تباهي لاء ڊگھو جواب ملي ٿو. بدقسمتي سان، اهو اسان سان سيپٽمبر 2018 ۾ ٿيو، جڏهن ريڊس سان گڏ هڪ واقعا ڪجهه سببن لاء هڪ دير سان ملي ٿي جيڪا معمول کان 2 ڀيرا وڌيڪ هئي. مسئلو حل ڪرڻ لاءِ، اسان ڪم جي ڏينهن جي وچ ۾ اڻ شيڊول سار سنڀال لاءِ سروس بند ڪري ڇڏي ۽ ريڊس جي مشڪلاتي مثال کي تبديل ڪيو.
4. اهو آسان آهي غير مطابقت واري ڊيٽا حاصل ڪرڻ جيتوڻيڪ ڪوڊ ۾ معمولي غلطين سان ۽ پوءِ ان ڊيٽا کي درست ڪرڻ لاءِ ڪوڊ لکڻ ۾ گهڻو وقت گذاريو.

اسان نقصانن کي حساب ۾ ورتو ۽ محسوس ڪيو ته اسان کي وڌيڪ آسان شيءِ ڏانهن وڃڻ جي ضرورت آهي، عام ٽرانزيڪشن سان ۽ دير تي گهٽ انحصار. اسان پنھنجي تحقيق ڪئي، ڪيترن ئي اختيارن جو تجزيو ڪيو ۽ PostgreSQL چونڊيو.

اسان ھاڻي 1,5 سالن کان ھڪ نئين ڊيٽابيس ڏانھن منتقل ٿي رھيا آھيون ۽ صرف ڊيٽا جو ھڪڙو ننڍڙو حصو منتقل ڪيو آھي، تنھنڪري ھاڻي اسان گڏجي ڪم ڪري رھيا آھيون Redis ۽ PostgreSQL سان. ڊيٽابيس جي وچ ۾ ڊيٽا کي منتقل ڪرڻ ۽ تبديل ڪرڻ جي مرحلن بابت وڌيڪ معلومات ۾ لکيو ويو آهي منهنجي ساٿي پاران آرٽيڪل.

جڏهن اسان پهريون ڀيرو هلڻ شروع ڪيو، اسان جي ايپليڪيشن سڌو سنئون ڊيٽابيس سان ڪم ڪيو ۽ ريڊس ۽ پوسٽ گري ايس ايس ايل ماسٽر تائين رسائي ڪئي. PostgreSQL ڪلستر هڪ ماسٽر ۽ هڪ ريپليڪا تي مشتمل آهي asynchronous replication سان. هي اهو آهي جيڪو ڊيٽابيس جي ڪم جي فلو وانگر نظر آيو:

PgBouncer لاڳو ڪرڻ

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

اسان وٽ ڪنيڪشن مينيجر لاءِ ٻه آپشن هئا: Pgpool ۽ PgBouncer. پر پهريون ڊيٽابيس سان ڪم ڪرڻ جي ٽرانزيڪشنل موڊ کي سپورٽ نٿو ڪري، تنهنڪري اسان چونڊيو PgBouncer.

اسان ھيٺ ڏنل ڪم جي اسڪيم کي ترتيب ڏنو آھي: اسان جي ايپليڪيشن ھڪڙي PgBouncer تائين پھچائي ٿي، جنھن جي پويان PostgreSQL ماسٽرز آھن، ۽ ھر ماسٽر جي پويان ھڪڙو نقل آھي غير مطابقت واري نقل سان.


ساڳئي وقت، اسان PostgreSQL ۾ ڊيٽا جي پوري مقدار کي ذخيرو نٿا ڪري سگهون ۽ ڊيٽابيس سان ڪم ڪرڻ جي رفتار اسان لاء اهم هئي، تنهنڪري اسان ايپليڪيشن سطح تي PostgreSQL کي شارڊنگ ڪرڻ شروع ڪيو. مٿي بيان ڪيل اسڪيم هن لاءِ نسبتاً آسان آهي: جڏهن هڪ نئون PostgreSQL شارڊ شامل ڪيو وڃي، اهو ڪافي آهي PgBouncer ترتيب کي اپڊيٽ ڪرڻ ۽ ايپليڪيشن فوري طور تي نئين شارڊ سان ڪم ڪري سگهي ٿي.

PgBouncer غلطي رواداري

اهو منصوبو ڪم ڪيو جيستائين صرف PgBouncer مثال مري ويو. اسان AWS ۾ آهيون، جتي سڀئي مثال هارڊويئر تي شروع ڪيا ويا آهن جيڪي وقتي طور تي مري ويندا آهن. اهڙين حالتن ۾، مثال صرف نئين هارڊويئر ڏانهن هلندو آهي ۽ ٻيهر ڪم ڪندو آهي. اهو PgBouncer سان ٿيو، پر اهو دستياب ناهي. ان حادثي جو نتيجو اهو نڪتو ته اسان جي سروس 25 منٽن لاءِ دستياب نه رهي. اهڙين حالتن لاءِ، AWS سفارش ڪري ٿو استعمال ڪندڙ جي پاسي تي فالتو استعمال، جنهن کي اسان ان وقت لاڳو نه ڪيو هو.

ان کان پوء، اسان PgBouncer ۽ PostgreSQL ڪلستر جي غلطي رواداري بابت سنجيدگي سان سوچيو، ڇو ته ساڳي صورتحال اسان جي AWS اڪائونٽ ۾ ڪنهن به مثال سان ٻيهر ٿي سگهي ٿي.

اسان PgBouncer فالٽ ٽولرنس اسڪيم هن ريت ٺاهي آهي: سڀ ايپليڪيشن سرور نيٽ ورڪ لوڊ بيلنس تائين رسائي ڪن ٿا، جنهن جي پويان ٻه PgBouncers آهن. PgBouncers مان هر هڪ شارڊ جي ساڳئي ماسٽر PostgreSQL تي نظر اچي ٿو. جيڪڏهن AWS مثال جي حادثي سان صورتحال ٻيهر ورجائي ٿي، سڀني ٽرئفڪ کي ٻئي PgBouncer ذريعي ريڊريٽ ڪيو ويندو. نيٽ ورڪ لوڊ بيلنس جي غلطي رواداري AWS پاران مهيا ڪئي وئي آهي.

هي اسڪيم توهان کي آساني سان نئون PgBouncer سرور شامل ڪرڻ جي اجازت ڏئي ٿي.

هڪ PostgreSQL ناڪامي ڪلستر ٺاهڻ

هن مسئلي کي حل ڪرڻ وقت، اسان مختلف اختيارن تي غور ڪيو: خود لکيل ناڪامي، repmgr، AWS RDS، Patroni.

خود لکيل اسڪرپٽ

اهي ماسٽر جي ڪم جي نگراني ڪري سگهن ٿا ۽، جيڪڏهن اهو ناڪام ٿئي ٿو، نقل کي ماسٽر ڏانهن وڌايو ۽ PgBouncer ترتيب کي اپڊيٽ ڪريو.

ھن طريقي جا فائدا وڌ ۾ وڌ سادگي آھن، ڇاڪاڻ⁠تہ توھان لکندا آھيو پاڻ لکندا ۽ سمجھندا آھيو ته اھي ڪيئن ڪم ڪن ٿيون.

ڪن

• ماسٽر شايد مري نه سگهيو آهي؛ ان جي بدران، اتي هڪ نيٽ ورڪ ناڪامي ٿي سگهي ٿي. ناڪام، ان کان بي خبر، ماسٽر ڏانهن نقل کي فروغ ڏيندو، ۽ پراڻو ماسٽر ڪم جاري رکندو. نتيجي طور، اسان ماسٽر رول ۾ ٻه سرور حاصل ڪنداسين ۽ نه ڄاڻنداسين ته انهن مان ڪهڙي تازي موجوده ڊيٽا آهي. هن صورتحال کي پڻ سڏيو ويندو آهي تقسيم دماغ؛
• اسان بغير جواب جي ڇڏي ويا. اسان جي ٺاھ جوڙ ۾ ھڪڙو ماسٽر ۽ ھڪڙو نقل آھي، تبديل ڪرڻ کان پوء ريپليڪا کي ماسٽر ڏانھن وڌايو ويندو آھي ۽ اسان وٽ ھاڻي نقل نه آھن، تنھنڪري اسان کي دستي طور تي ھڪڙو نئون ريپليڪا شامل ڪرڻو پوندو؛
• اسان کي فال اوور آپريشن جي اضافي نگراني جي ضرورت آھي، ۽ اسان وٽ 12 PostgreSQL شارڊز آھن، جنھن جو مطلب آھي ته اسان کي 12 ڪلستر مانيٽر ڪرڻ جي ضرورت آھي. جڏهن شارڊز جو تعداد وڌايو، توهان کي پڻ ياد رکڻ گهرجي ته ناڪامي کي اپڊيٽ ڪرڻ.

هڪ خود لکيل ناڪامي تمام پيچيده لڳي ٿو ۽ غير معمولي مدد جي ضرورت آهي. ھڪڙي PostgreSQL ڪلستر سان، اھو آسان ترين اختيار ھوندو، پر اھو ماپ نٿو ڪري، تنھنڪري اھو اسان لاء مناسب نه آھي.

Repmgr

Replication Manager for PostgreSQL ڪلستر، جيڪو PostgreSQL ڪلستر جي آپريشن کي منظم ڪري سگھي ٿو. ساڳئي وقت، ان کي دٻي کان ٻاهر خودڪار ناڪامي نه آهي، تنهنڪري ڪم ڪرڻ لاء توهان کي تيار ڪيل حل جي چوٽي تي پنهنجو "ريپر" لکڻ جي ضرورت پوندي. تنهن ڪري هر شيءِ پاڻمرادو لکيل لکتن جي ڀيٽ ۾ اڃا به وڌيڪ پيچيده ٿي سگهي ٿي، اهو ئي سبب آهي ته اسان Repmgr جي ڪوشش به نه ڪئي.

AWS RDS

اهو هر شي کي سپورٽ ڪري ٿو جيڪو اسان کي گهربل آهي، بيڪ اپ ڪري سگهي ٿو ۽ ڪنيڪشن جي تلاء کي سپورٽ ڪري ٿو. ان ۾ خودڪار سوئچنگ آهي: جڏهن ماسٽر مري ويندو آهي، نقل نئون ماسٽر بڻجي ويندو آهي، ۽ AWS DNS رڪارڊ کي نئين ماسٽر ۾ تبديل ڪري ٿو، جڏهن ته نقل مختلف AZs ۾ واقع ٿي سگهي ٿو.

نقصانن ۾ سٺي سيٽنگن جي کوٽ شامل آهي. فائن ٽيوننگ جي مثال طور: اسان جي مثالن تي پابنديون آهن tcp ڪنيڪشن، جيڪي، بدقسمتي سان، RDS ۾ نٿا ٿي سگهن:

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

ان کان علاوه، AWS RDS باقاعده مثال جي قيمت جي ڀيٽ ۾ تقريبا ٻه ڀيرا قيمتي آهي، جيڪو هن حل کي ڇڏڻ جو بنيادي سبب هو.

پتروني

هي هڪ پٿون ٽيمپليٽ آهي PostgreSQL کي منظم ڪرڻ لاءِ سٺي دستاويزن سان، خودڪار ناڪامي ۽ گٿب تي سورس ڪوڊ.

Patroni جا فائدا:

• هر تشڪيل جي پيٽرول بيان ڪئي وئي آهي، اهو واضح آهي ته اهو ڪيئن ڪم ڪري ٿو.
• خودڪار ناڪامي دٻي کان ٻاهر ڪم؛
• python ۾ لکيو ويو آهي، ۽ جيئن ته اسان پاڻ python ۾ گهڻو ڪجهه لکندا آهيون، اهو اسان لاء آسان ٿيندو ته مسئلن کي منهن ڏيڻ ۽، شايد، پروجيڪٽ جي ترقي ۾ پڻ مدد ڪندي؛
• PostgreSQL مڪمل طور تي ڪنٽرول ڪري ٿو، توهان کي ڪلستر جي سڀني نوڊس تي هڪ ئي وقت ۾ ترتيب تبديل ڪرڻ جي اجازت ڏئي ٿي، ۽ جيڪڏهن نئين ترتيب کي لاڳو ڪرڻ لاء ڪلستر کي ٻيهر شروع ڪرڻ جي ضرورت آهي، اهو پيٽروني استعمال ڪندي ٻيهر ڪري سگهجي ٿو.

ڪن

• اهو دستاويز مان واضح ناهي ته PgBouncer سان صحيح طريقي سان ڪيئن ڪم ڪجي. جيتوڻيڪ ان کي مائنس سڏڻ ڏکيو آهي، ڇاڪاڻ ته Patroni جو ڪم PostgreSQL کي منظم ڪرڻ آهي، ۽ Patroni سان ڪنيڪشن ڪيئن ڪم ڪندو اڳ ۾ ئي اسان جو مسئلو آهي؛
• وڏي پيماني تي Patroni تي عملدرآمد جا ٿورا مثال آهن، جڏهن ته شروع کان ئي عمل درآمد جا ڪيترائي مثال آهن.

نتيجي طور، اسان پيٽروني کي هڪ ناڪامي ڪلستر ٺاهڻ لاء چونڊيو.

Patroni تي عملدرآمد جو عمل

Patroni کان اڳ، اسان وٽ ھڪڙو ماسٽر ۾ 12 PostgreSQL شارڊز ۽ ھڪڙي ريپليڪا ٺاھ جوڙ غير مطابقت واري نقل سان. ايپليڪيشن سرورز نيٽ ورڪ لوڊ بيلنسر ذريعي ڊيٽابيس تائين رسائي حاصل ڪئي، جنهن جي پويان PgBouncer سان ٻه مثال هئا، ۽ انهن جي پويان سڀئي PostgreSQL سرور هئا.


Patroni کي لاڳو ڪرڻ لاء، اسان کي ورهايل ڪلستر جي ترتيب واري اسٽوريج کي چونڊڻ جي ضرورت آهي. Patroni ورهايل ترتيب واري اسٽوريج سسٽم سان ڪم ڪري ٿو جهڙوڪ etcd، Zookeeper، Consul. اسان وٽ پيداوار ۾ هڪ مڪمل قونصل ڪلسٽر آهي، جيڪو والٽ سان گڏ ڪم ڪري ٿو ۽ اسان ان کي وڌيڪ استعمال نٿا ڪريون. ان جي گهربل مقصد لاء قونصل استعمال ڪرڻ شروع ڪرڻ جو هڪ وڏو سبب.

ڪيئن Patroni قونصل سان ڪم

اسان وٽ هڪ ڪنسل ڪلستر آهي، جيڪو ٽن نوڊس تي مشتمل آهي، ۽ هڪ پيٽروني ڪلستر، جنهن ۾ ليڊر ۽ هڪ ريپليڪا (Patroni ۾، ماسٽر کي ڪلستر ليڊر سڏيو ويندو آهي، ۽ غلامن کي replicas سڏيو ويندو آهي). هر Patroni ڪلستر مثال مسلسل ڪلستر جي حالت بابت قونصل کي معلومات موڪلي ٿو. تنهن ڪري، قونصل کان توهان هميشه ڳولي سگهو ٿا موجوده تشڪيل جي پيٽروني ڪلستر ۽ هن وقت اڳواڻ ڪير آهي.

Patroni کي قونصل سان ڳنڍڻ لاءِ، صرف سرڪاري دستاويزن جو مطالعو ڪريو، جيڪو چوي ٿو ته توھان کي ھوسٽ کي http يا https فارميٽ ۾ بيان ڪرڻ جي ضرورت آھي، ان تي منحصر آھي ته اسان قونصل سان ڪيئن ڪم ڪريون ٿا، ۽ ڪنيڪشن ڊاگرام، اختياري طور تي:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

اهو سادو ڏسڻ ۾ اچي ٿو، پر اهو آهي جتي نقصان شروع ٿئي ٿو. Consul سان اسان https ذريعي محفوظ ڪنيڪشن تي ڪم ڪريون ٿا ۽ اسان جي ڪنيڪشن جي ترتيب هن طرح نظر ايندي:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

پر اهو انهي طريقي سان ڪم نٿو ڪري. شروعات ۾، Patroni قونصل سان ڳنڍي نٿو سگهي ڇاڪاڻ ته اهو اڃا تائين http ذريعي وڃڻ جي ڪوشش ڪري ٿو.

Patroni سورس ڪوڊ مسئلو حل ڪرڻ ۾ مدد ڪئي. اهو سٺو آهي ته اهو پٿرن ۾ لکيو ويو آهي. اهو ظاهر ٿئي ٿو ته ميزبان پيٽرولر ڪنهن به طريقي سان پارس نه ڪيو ويو آهي، ۽ پروٽوڪول کي اسڪيم ۾ بيان ڪيو وڃي. هي اهو آهي جيڪو قونصل سان ڪم ڪرڻ لاءِ ڪم ڪندڙ ترتيب وارو بلاڪ اسان لاءِ ڏسڻ جهڙو آهي:

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

قونصل- ٽيمپليٽ

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

هڪ حل جي ڳولا ۾، اسان کي هڪ مضمون مليو (بدقسمتي سان، مون کي نالو ياد ناهي)، جتي اهو لکيل هو ته قونصل ٽيمپليٽ PgBouncer ۽ Patroni کي گڏ ڪرڻ ۾ تمام مددگار ثابت ٿيو. ان ڪري اسان کي قونصل جي ٽيمپليٽ جي ڪم جو مطالعو ڪرڻ جي ترغيب ڏني.

اهو ظاهر ٿيو ته Consul-template مسلسل Consul ۾ PostgreSQL ڪلستر جي ترتيب جي نگراني ڪندو آهي. جڏهن ليڊر تبديل ٿئي ٿو، اهو تازه ڪاري ڪري ٿو PgBouncer ترتيب ۽ ان کي ٻيهر لوڊ ڪرڻ لاءِ حڪم موڪلي ٿو.

ٽيمپليٽ جو وڏو فائدو اهو آهي ته اهو ڪوڊ جي طور تي ذخيرو ٿيل آهي، تنهنڪري جڏهن نئون شارڊ شامل ڪيو وڃي، اهو ڪافي آهي ته نئين ڪمٽ ٺاهڻ ۽ ٽيمپليٽ کي خودڪار طور تي اپڊيٽ ڪرڻ، بنيادي طور تي ڪوڊ اصول جي طور تي انفراسٽرڪچر کي سپورٽ ڪندي.

Patroni سان نئون فن تعمير

نتيجي طور، اسان ڪم جي هيٺين منصوبي حاصل ڪئي:


سڀئي ايپليڪيشن سرورز بيلنس تائين پهچن ٿا → ان جي پويان PgBouncer جا ٻه مثال آهن → هر هڪ مثال تي هڪ قونصل ٽيمپليٽ هلي رهيو آهي، جيڪو هر Patroni ڪلستر جي حالت کي مانيٽر ڪري ٿو ۽ PgBouncer config جي مطابقت کي مانيٽر ڪري ٿو، جيڪو موجوده ليڊر ڏانهن درخواستون سڌو ڪري ٿو. هر ڪلستر جي.

دستي جاچ

ان کي پيداوار ۾ شروع ڪرڻ کان اڳ، اسان هن اسڪيم کي هڪ ننڍڙي ٽيسٽ ماحول تي شروع ڪيو ۽ خودڪار سوئچنگ جي آپريشن کي جانچيو. انهن بورڊ کوليو، اسٽيڪر کي منتقل ڪيو ۽ ان وقت ڪلستر جي اڳواڻ کي "ماري ڇڏيو". AWS ۾، توهان سڀني کي ڪرڻ جي ضرورت آهي مثال کي ڪنسول ذريعي بند ڪريو.

اسٽيڪر 10-20 سيڪنڊن اندر واپس آيو، ۽ پوء عام طور تي ٻيهر هلڻ شروع ڪيو. هن جو مطلب آهي ته Patroni ڪلستر صحيح ڪم ڪيو: هن ليڊر کي تبديل ڪيو، قونصل ڏانهن معلومات موڪلي، ۽ قونصل ٽيمپليٽ هن معلومات کي فوري طور تي ورتو، PgBouncer ترتيب کي تبديل ڪيو ۽ ٻيهر لوڊ ڪرڻ لاء هڪ حڪم موڪليو.

وڌيڪ لوڊ هيٺ رهڻ ۽ گهٽ ۾ گهٽ وقت کي برقرار رکڻ ڪيئن؟

هر شي مڪمل طور تي ڪم ڪري ٿو! پر نوان سوال پيدا ٿين ٿا: اهو ڪيئن ڪم ڪندو اعلي لوڊ هيٺ؟ جلدي ۽ محفوظ طريقي سان پيداوار ۾ هر شيء کي ڪيئن وڌايو؟

امتحان وارو ماحول جنهن تي اسان لوڊ ٽيسٽنگ ڪريون ٿا اسان کي پهرين سوال جو جواب ڏيڻ ۾ مدد ڪري ٿي. اهو فن تعمير ۾ پيداوار سان مڪمل طور تي هڪجهڙائي آهي ۽ ٽيسٽ ڊيٽا ٺاهي وئي آهي، جيڪا پيداوار جي مقدار ۾ تقريبن برابر آهي. اسان فيصلو ڪيو ته "مارڻ" جي پوسٽ گري ايس ايس ايل ماسٽرز مان هڪ کي ٽيسٽ دوران ۽ ڏسو ته ڇا ٿئي ٿو. پر ان کان اڳ، اهو ضروري آهي ته خودڪار رول آئوٽ کي چيڪ ڪريو، ڇاڪاڻ ته هن ماحول تي اسان وٽ ڪيترائي PostgreSQL شارڊز آهن، تنهنڪري اسان پيداوار کان اڳ ترتيب واري اسڪرپٽ جي بهترين جانچ حاصل ڪنداسين.

ٻئي ڪم شاندار نظر اچن ٿا، پر اسان وٽ آهي PostgreSQL 9.6. ٿي سگهي ٿو اسان فوري طور تي 11.2 تائين تازه ڪاري ڪري سگهون ٿا؟

اسان ان کي 2 مرحلن ۾ ڪرڻ جو فيصلو ڪيو: پهريون نسخو 11.2 تائين اپڊيٽ ڪريو، پوءِ Patroni لانچ ڪريو.

PostgreSQL اپڊيٽ

PostgreSQL ورجن کي جلدي اپڊيٽ ڪرڻ لاءِ، توھان کي لازمي طور استعمال ڪرڻ گھرجي -k، جنهن ۾ ڊسڪ تي هڪ هارڊ لنڪ ٺاهي وئي آهي ۽ توهان جي ڊيٽا کي نقل ڪرڻ جي ڪا ضرورت ناهي. 300-400 GB جي ڊيٽابيس تي، تازه ڪاري 1 سيڪنڊ وٺندو آهي.

اسان وٽ تمام گھڻا حصا آھن، تنھنڪري اپڊيٽ کي خودڪار طريقي سان ٿيڻ جي ضرورت آھي. هن کي ڪرڻ لاء، اسان هڪ جوابي راند جو ڪتاب لکيو آهي جيڪو اسان لاء مڪمل تازه ڪاري جي عمل کي انجام ڏئي ٿو:

/usr/lib/postgresql/11/bin/pg_upgrade 
<b>--link </b>
--old-datadir='' --new-datadir='' 
 --old-bindir=''  --new-bindir='' 
 --old-options=' -c config_file=' 
 --new-options=' -c config_file='

هتي اهو نوٽ ڪرڻ ضروري آهي ته اپ گريڊ شروع ڪرڻ کان پهريان، توهان کي ان کي پيٽرولر سان انجام ڏيڻ گهرجي --چيڪانهي کي يقيني بڻائڻ ته اپ گريڊ ممڪن آهي. اسان جي اسڪرپٽ پڻ اپ گريڊ دوران ترتيبن کي تبديل ڪري ٿي. اسان جو اسڪرپٽ 30 سيڪنڊن ۾ مڪمل ٿيو، جيڪو هڪ بهترين نتيجو آهي.

Patroni جي شروعات

ٻئي مسئلي کي حل ڪرڻ لاء، صرف ڏسو Patroni ترتيب. سرڪاري مخزن ۾ initdb سان هڪ مثالي ترتيب ڏنل آهي، جيڪا نئين ڊيٽابيس کي شروع ڪرڻ جي ذميوار آهي جڏهن Patroni پهريون ڀيرو شروع ڪئي وئي آهي. پر جيئن ته اسان وٽ اڳ ۾ ئي تيار ڪيل ڊيٽابيس آهي، اسان صرف هن حصي کي ترتيب مان هٽايو.

جڏهن اسان پيٽروني کي انسٽال ڪرڻ شروع ڪيو هڪ تيار ٿيل PostgreSQL ڪلستر تي ۽ ان کي لانچ ڪيو، اسان هڪ نئين مسئلي سان منهن ڪيو: ٻئي سرورز ليڊر طور شروع ڪيا ويا. Patroni ڪلستر جي شروعاتي حالت بابت ڪجھ به نه ڄاڻي ٿو ۽ ڪوشش ڪري ٿو ته ٻنهي سرورن کي ٻن الڳ ڪلستر وانگر ساڳئي نالي سان. هن مسئلي کي حل ڪرڻ لاء، توهان کي غلام تي ڊيٽا ڊاريڪٽري کي ختم ڪرڻ جي ضرورت آهي:

rm -rf /var/lib/postgresql/

اهو ڪم رڳو ٻانهن تي ٿيڻ گهرجي!

جڏهن هڪ صاف ريپليڪا کي ڳنڍيندي، پيٽروني هڪ بنيادي بيڪ اپ ليڊر ٺاهي ٿو ۽ ان کي ريپليڪا ڏانهن بحال ڪري ٿو، ۽ پوء وال لاگ استعمال ڪندي موجوده حالت سان پڪڙي ٿو.

هڪ ٻي ڏکيائي جيڪا اسان کي سامهون آئي آهي اها آهي ته سڀئي PostgreSQL ڪلسٽرز کي بنيادي طور تي ڊفالٽ سڏيو وڃي ٿو. جڏهن هر ڪلستر ٻئي جي باري ۾ ڪجھ به نه ڄاڻي، اهو عام آهي. پر جڏھن توھان استعمال ڪرڻ چاھيو ٿا Patroni، سڀني ڪلسترن کي ھڪڙو منفرد نالو ھئڻ گھرجي. حل آهي ڪلستر جو نالو تبديل ڪرڻ PostgreSQL ترتيب ۾.

لوڊ ٽيسٽ

اسان ھڪڙو امتحان شروع ڪيو آھي جيڪو سميليٽ ڪري ٿو ته صارف ڪيئن بورڊ تي ڪم ڪن ٿا. جڏهن لوڊ اسان جي روزاني اوسط تي پهچي ويو، اسان ساڳئي امتحان کي ورجايو، اسان هڪ مثال بند ڪيو ليڊر PostgreSQL سان. خودڪار ناڪامي ڪم ڪيو جيئن اسان توقع ڪئي: Patroni ليڊر کي تبديل ڪيو، قونصل ٽيمپليٽ PgBouncer ترتيب کي اپڊيٽ ڪيو ۽ ٻيهر لوڊ ڪرڻ لاء هڪ حڪم موڪليو. Grafana ۾ اسان جي گراف جي مطابق، اهو واضح ٿيو ته 20-30 سيڪنڊن جي دير ٿي وئي ۽ ڊيٽابيس جي ڪنيڪشن سان لاڳاپيل سرورز کان غلطي جي هڪ ننڍڙي رقم هئي. اها هڪ عام صورتحال آهي، اهڙيون قيمتون اسان جي ناڪامي لاءِ قابل قبول آهن ۽ يقيني طور تي خدمت جي وقت کان بهتر آهن.

پيداوار ۾ Patroni جي شروعات

نتيجي طور، اسان ھيٺ ڏنل منصوبي سان آيا:

• Consul-template کي PgBouncer سرور تي لڳايو ۽ لانچ ڪريو؛
• PostgreSQL ورجن 11.2 ڏانهن اپڊيٽ؛
• ڪلستر جو نالو تبديل ڪرڻ؛
• Patroni ڪلستر جو آغاز.

ساڳئي وقت، اسان جي اسڪيم اسان کي اجازت ڏئي ٿي ته پهرين نقطي تي تقريبا ڪنهن به وقت؛ اسان هر هڪ PgBouncer کي ڪم مان هڪ هڪ ڪري هٽائي سگھون ٿا ۽ ان تي قونصل ٽيمپليٽ جي مقرري ۽ لانچ ڪري سگھون ٿا. اهو ئي اسان ڪيو.

تڪڙي جاچ لاءِ، اسان جوابي استعمال ڪيو، ڇاڪاڻ ته اسان اڳ ۾ ئي پوري پلي بڪ کي ٽيسٽ ماحول تي آزمايو هو، ۽ مڪمل اسڪرپٽ لاءِ عمل جو وقت هر شارڊ لاءِ 1,5 کان 2 منٽن تائين هو. اسان پنهنجي خدمت کي روڪڻ کان سواءِ هر شي کي هڪ هڪ ڪري هر شارڊ ڏانهن رول آئوٽ ڪري سگهون ٿا، پر اسان کي هر PostgreSQL کي ڪيترن ئي منٽن لاءِ بند ڪرڻو پوندو. انهي صورت ۾، صارف جن جي ڊيٽا هن شارڊ تي آهي هن وقت مڪمل طور تي ڪم ڪرڻ جي قابل نه هوندا، ۽ اهو اسان لاء ناقابل قبول آهي.

هن صورتحال مان نڪرڻ جو طريقو منصوبابندي ڪيل سار سنڀال، جيڪو اسان هر 3 مهينن ۾ ڪندا آهيون. هي هڪ ونڊو آهي مقرر ڪيل ڪم لاءِ، جڏهن اسان مڪمل طور تي اسان جي سروس بند ڪريون ٿا ۽ ڊيٽابيس جا مثال تازه ڪاري ڪريون ٿا. ايندڙ ونڊو تائين هڪ هفتو باقي هو، ۽ اسان انتظار ڪرڻ جو فيصلو ڪيو ۽ اڳتي تيار ڪيو. انتظار جي دوران، اسان اضافي طور تي پنهنجي شرطن کي هٽايو: هر PostgreSQL شارڊ لاءِ اسان ناڪامي جي صورت ۾ هڪ اضافي نقل اٿاريو، جديد ڊيٽا کي محفوظ ڪرڻ لاءِ، ۽ هر شارڊ لاءِ هڪ نئون مثال شامل ڪيو، جيڪو Patroni ۾ هڪ نئين ريپليڪا بڻجي وڃي. ڪلستر، جيئن ته ڊيٽا کي ختم ڪرڻ لاء حڪم جاري نه ڪيو وڃي. هي سڀ غلطي جي خطري کي گهٽائڻ ۾ مدد ڪئي.


اسان اسان جي سروس کي ٻيهر شروع ڪيو، سڀ ڪجھ ڪم ڪيو جيئن ان کي گهرجي، صارفين ڪم ڪرڻ جاري رکي، پر گرافس تي اسان قونصلن جي سرورز تي غير معمولي تيز لوڊ محسوس ڪيو.


اسان اهو امتحان واري ماحول ۾ ڇو نه ڏٺو؟ اهو مسئلو تمام چڱيءَ طرح بيان ڪري ٿو ته ضروري آهي ته بنيادي ڍانچي کي ڪوڊ اصول جي طور تي عمل ڪيو وڃي ۽ پوري انفراسٽرڪچر کي بهتر بڻايو وڃي، ٽيسٽ ماحول کان وٺي پيداوار تائين. ٻي صورت ۾، اسان کي حاصل ڪرڻ جو مسئلو تمام آسان آهي. ڇا ٿيو؟ قونصل پهريون ڀيرو پيداوار ۾ ظاهر ٿيو، ۽ پوء ٽيسٽ ماحول ۾؛ نتيجي طور، ٽيسٽ ماحول ۾ قونصل جو نسخو پيداوار کان وڌيڪ هو. صرف هڪ رليز ۾، هڪ سي پي يو ليڪ جڏهن قونصل-ٽيمپليٽ سان ڪم ڪندي حل ڪيو ويو. تنهنڪري اسان صرف قونصل کي اپڊيٽ ڪيو، اهڙي طرح مسئلو حل ڪيو.

Patroni ڪلستر ٻيهر شروع ڪريو

بهرحال، اسان کي هڪ نئون مسئلو مليو جنهن بابت اسان کي شڪ به نه هو. Consul کي اپڊيٽ ڪرڻ وقت، اسان صرف قونصل جي موڪل واري ڪمانڊ کي استعمال ڪندي ڪلسٽر مان قونصل نوڊ کي هٽائي ڇڏيون ٿا → Patroni ڪنيڪٽ ٿئي ٿو ٻي ڪنسل سرور سان → سڀ ڪجھ ڪم ڪري ٿو. پر جڏهن اسان قونصل ڪلسٽر جي آخري مثال تي پهتاسين ۽ ان کي قونصل موڪل جو حڪم موڪليو، سڀ پيٽروني ڪلسٽر آسانيءَ سان ٻيهر شروع ٿي ويا، ۽ لاگن ۾ اسان ھيٺ ڏنل نقص ڏٺو:

ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>

Patroni ڪلستر پنهنجي ڪلستر جي باري ۾ معلومات حاصل ڪرڻ جي قابل نه هو ۽ ٻيهر شروع ڪيو ويو.

حل ڳولڻ لاء، اسان گٿب تي هڪ مسئلي ذريعي Patroni جي ليکڪن سان رابطو ڪيو. انهن تجويز ڪيو ته اسان جي ترتيب واري فائلن ۾ بهتري:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

اسان هڪ امتحان واري ماحول ۾ مسئلي کي نقل ڪرڻ جي قابل هئا ۽ انهن سيٽنگن کي جانچيو، پر بدقسمتي سان انهن ڪم نه ڪيو.

مسئلو اڃا تائين حل ٿيل نه آهي. اسان هيٺ ڏنل حل جي ڪوشش ڪرڻ جو ارادو ڪيو:

• Patroni ڪلستر جي هر مثال تي قونصل-ايجنٽ استعمال ڪريو؛
• ڪوڊ ۾ مسئلو حل ڪريو.

اسان سمجهون ٿا ته غلطي ڪٿي ٿي آهي: شايد مسئلو ڊفالٽ ٽائيم آئوٽ استعمال ڪرڻ ۾ آهي، جيڪو ترتيب واري فائل ذريعي ختم نه ڪيو ويو آهي. جڏهن آخري قونصل سرور ڪلستر مان هٽايو ويندو آهي، سڄو قونصل ڪلستر منجمد ٿي ويندو آهي، جيڪو هڪ سيڪنڊ کان وڌيڪ ڊگهو آهي؛ ان جي ڪري، پيٽروني ڪلستر جي حالت حاصل نه ڪري سگهي ٿي ۽ مڪمل طور تي پوري ڪلستر کي ٻيهر شروع ڪري ٿو.

خوشقسمتيءَ سان، اسان کي وڌيڪ غلطيون نه ٿيون مليون.

Patroni استعمال ڪرڻ جا نتيجا

Patroni جي ڪامياب لانچ کان پوء، اسان هر ڪلستر ۾ هڪ اضافي نقل شامل ڪيو. ھاڻي ھر ڪلستر ۾ ھڪڙي ھڪڙي ڪورم جي جھلڪ آھي: ھڪڙو ليڊر ۽ ٻه ريپليڪس، تبديل ڪرڻ وقت تقسيم دماغ جي خلاف بچاء لاء.


Patroni ٽن مهينن کان وڌيڪ عرصي تائين پيداوار ۾ ڪم ڪري رهيو آهي. هن عرصي دوران، هن اڳ ۾ ئي اسان جي مدد ڪرڻ ۾ مدد ڪئي. تازو، هڪ ڪلستر جو اڳواڻ AWS ۾ مري ويو، خودڪار ناڪامي ڪم ڪيو ۽ صارفين ڪم ڪرڻ جاري رکي. محب وطن پنهنجو بنيادي ڪم پورو ڪيو آهي.

Patroni استعمال ڪرڻ جو مختصر خلاصو:

• ترتيب جي تبديلين جي آساني. اھو ڪافي آھي ھڪڙي مثال تي ترتيب کي تبديل ڪرڻ ۽ اھو پوري ڪلستر تي لاڳو ٿيندو. جيڪڏهن نئين ترتيب لاڳو ڪرڻ لاءِ ريبوٽ گهربل آهي، Patroni توهان کي ان بابت مطلع ڪندو. Patroni هڪ حڪم سان سڄي ڪلستر کي ٻيهر شروع ڪري سگهي ٿو، جيڪو پڻ تمام آسان آهي.
• خودڪار ناڪامي ڪم ڪري رهيو آهي ۽ اڳ ۾ ئي اسان جي مدد ڪئي آهي.
• اپڊيٽ ڪرڻ PostgreSQL بغير ايپليڪيشن ڊائون ٽائم. توھان کي پھريائين ريپليڪس کي نئين ورزن ۾ اپڊيٽ ڪرڻ گھرجي، پوءِ پيٽروني ڪلستر ۾ ليڊر تبديل ڪريو ۽ پراڻي ليڊر کي اپڊيٽ ڪريو. انهي حالت ۾، خودڪار ناڪامي جي ضروري جاچ ٿيندي آهي.

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