Maqolada men sizga PostgreSQL xatolarga bardoshliligi masalasiga qanday yondashganimizni, nima uchun bu biz uchun muhim bo'lganini va oxirida nima bo'lganini aytib beraman.
Bizda yuqori yuklangan xizmat bor: butun dunyo bo'ylab 2,5 million foydalanuvchi, har kuni 50K+ faol foydalanuvchilar. Serverlar Irlandiyaning bir mintaqasidagi Amazone shahrida joylashgan: 100 dan ortiq turli serverlar doimiy ravishda ishlaydi, ulardan deyarli 50 tasi ma'lumotlar bazasiga ega.
Butun backend - bu mijoz bilan doimiy veb-soket ulanishini ta'minlaydigan katta monolit holatli Java ilovasi. Bir vaqtning o'zida bir nechta foydalanuvchi bir doskada ishlaganda, ularning barchasi real vaqt rejimida o'zgarishlarni ko'radi, chunki biz har bir o'zgarishni ma'lumotlar bazasiga yozamiz. Bizning ma'lumotlar bazalarimizga sekundiga taxminan 10 ming so'rovimiz bor. Redis-da eng yuqori yuklanishda biz soniyada 80-100K so'rov yozamiz.
Nima uchun biz Redis-dan PostgreSQL-ga o'tdik
Dastlab, bizning xizmatimiz serverning operativ xotirasida barcha ma'lumotlarni saqlaydigan asosiy qiymatlar do'koni Redis bilan ishlagan.
Redisning afzalliklari:
- Yuqori javob tezligi, chunki hamma narsa xotirada saqlanadi;
- Zaxiralash va replikatsiya qilish qulayligi.
Biz uchun Redisning kamchiliklari:
- Haqiqiy bitimlar mavjud emas. Biz ularni ilovamiz darajasida taqlid qilishga harakat qildik. Afsuski, bu har doim ham yaxshi ishlamadi va juda murakkab kod yozishni talab qildi.
- Ma'lumotlar hajmi xotira hajmi bilan cheklangan. Ma'lumotlar miqdori oshgani sayin, xotira o'sib boradi va oxirida biz tanlangan namunaning xususiyatlariga duch kelamiz, bu AWSda namuna turini o'zgartirish uchun xizmatimizni to'xtatishni talab qiladi.
- Doimiy ravishda past kechikish darajasini saqlab turish kerak, chunki. bizda juda ko'p so'rovlar bor. Biz uchun optimal kechikish darajasi 17-20 ms. 30-40 ms darajasida biz ilovamizdan so'rovlarga uzoq javoblar va xizmatning yomonlashuviga erishamiz. Afsuski, bu biz bilan 2018 yil sentyabr oyida sodir bo'ldi, o'shanda Redis bilan bo'lgan holatlardan biri negadir odatdagidan 2 baravar ko'proq kechikishni oldi. Muammoni hal qilish uchun biz rejadan tashqari texnik xizmat ko'rsatish uchun kun o'rtasida xizmatni to'xtatdik va muammoli Redis nusxasini almashtirdik.
- Koddagi kichik xatolar bo'lsa ham, ma'lumotlarning nomuvofiqligini olish oson va keyin bu ma'lumotlarni tuzatish uchun kod yozish uchun ko'p vaqt sarflashingiz mumkin.
Biz kamchiliklarni hisobga oldik va oddiy tranzaktsiyalar va kechikishga kamroq bog'liqlik bilan qulayroq narsaga o'tishimiz kerakligini tushundik. Tadqiqot o'tkazdi, ko'plab variantlarni tahlil qildi va PostgreSQL ni tanladi.
Biz 1,5 yildan beri yangi ma'lumotlar bazasiga o'tdik va ma'lumotlarning faqat kichik qismini ko'chirdik, shuning uchun endi biz Redis va PostgreSQL bilan bir vaqtda ishlayapmiz. Ma'lumotlar bazalari o'rtasida ma'lumotlarni ko'chirish va almashtirish bosqichlari haqida ko'proq ma'lumot yozilgan .
Biz birinchi marta ko'chirishni boshlaganimizda, bizning ilovamiz to'g'ridan-to'g'ri ma'lumotlar bazasi bilan ishladi va master Redis va PostgreSQL-ga kirdi. PostgreSQL klasteri master va asinxron replikatsiyaga ega replikadan iborat edi. Ma'lumotlar bazasi sxemasi shunday ko'rinishga ega edi:
PgBouncer amalga oshirilmoqda
Biz harakatlanar ekanmiz, mahsulot ham rivojlanib bordi: foydalanuvchilar soni va PostgreSQL bilan ishlaydigan serverlar soni ko'paydi va bizda ulanishlar yetishmay qoldi. PostgreSQL har bir ulanish uchun alohida jarayon yaratadi va resurslarni sarflaydi. Siz ulanishlar sonini ma'lum bir nuqtaga ko'paytirishingiz mumkin, aks holda suboptimal ma'lumotlar bazasi ishlashiga erishish imkoniyati mavjud. Bunday vaziyatda ideal variant bazaning oldida turadigan ulanish menejerini tanlash bo'ladi.
Bizda ulanish menejeri uchun ikkita variant bor edi: Pgpool va PgBouncer. Ammo birinchisi ma'lumotlar bazasi bilan ishlashning tranzaktsion rejimini qo'llab-quvvatlamaydi, shuning uchun biz PgBouncer ni tanladik.
Biz quyidagi ish sxemasini o'rnatdik: bizning ilovamiz bitta PgBouncer-ga kiradi, uning orqasida PostgreSQL masterlari va har bir masterning orqasida asinxron replikatsiyaga ega bitta nusxa mavjud.
Shu bilan birga, biz PostgreSQL-da ma'lumotlarning butun hajmini saqlay olmadik va ma'lumotlar bazasi bilan ishlash tezligi biz uchun muhim edi, shuning uchun biz PostgreSQL-ni dastur darajasida parchalashni boshladik. Buning uchun yuqorida tavsiflangan sxema nisbatan qulay: yangi PostgreSQL parchasini qo'shganda, PgBouncer konfiguratsiyasini yangilash kifoya va dastur darhol yangi parcha bilan ishlashi mumkin.
PgBouncer o'chirilishi
Ushbu sxema PgBouncerning yagona nusxasi o'lgunga qadar ishladi. Biz AWSdamiz, u erda barcha nusxalar vaqti-vaqti bilan o'chib turadigan apparatda ishlaydi. Bunday hollarda, misol shunchaki yangi uskunaga o'tadi va yana ishlaydi. Bu PgBouncer bilan sodir bo'ldi, lekin u mavjud bo'lmadi. Ushbu kuzning natijasi bizning xizmatimiz 25 daqiqa davomida mavjud emas edi. AWS o'sha paytda mamlakatimizda joriy etilmagan bunday holatlar uchun foydalanuvchi tomonidan ortiqcha foydalanishni tavsiya qiladi.
Shundan so'ng, biz PgBouncer va PostgreSQL klasterlarining xatolarga chidamliligi haqida jiddiy o'ylab ko'rdik, chunki shunga o'xshash vaziyat bizning AWS hisobimizdagi har qanday misol bilan sodir bo'lishi mumkin.
Biz PgBouncer nosozliklarga chidamlilik sxemasini quyidagicha qurdik: barcha dastur serverlari Tarmoq yukini muvozanatlash moslamasiga kirishadi, ularning ortida ikkita PgBouncer mavjud. Har bir PgBouncer har bir parchaning bir xil PostgreSQL masteriga qaraydi. Agar AWS nusxasi buzilishi yana sodir bo'lsa, barcha trafik boshqa PgBouncer orqali qayta yo'naltiriladi. Network Load Balancer o'zgartirish AWS tomonidan taqdim etiladi.
Ushbu sxema yangi PgBouncer serverlarini qo'shishni osonlashtiradi.
PostgreSQL Failover klasterini yarating
Ushbu muammoni hal qilishda biz turli xil variantlarni ko'rib chiqdik: o'z-o'zidan yozilgan muvaffaqiyatsizlik, repmgr, AWS RDS, Patroni.
O'z-o'zidan yozilgan skriptlar
Ular usta ishini kuzatishi va agar u muvaffaqiyatsiz bo'lsa, replikani masterga targ'ib qilishi va PgBouncer konfiguratsiyasini yangilashi mumkin.
Ushbu yondashuvning afzalliklari maksimal soddalikdir, chunki siz skriptlarni o'zingiz yozasiz va ular qanday ishlashini aniq tushunasiz.
Kamchiliklari:
- Usta o'lmagan bo'lishi mumkin, buning o'rniga tarmoqdagi nosozlik yuz bergan bo'lishi mumkin. Failover, bundan bexabar, replikani ustaga targ'ib qiladi, eski usta esa ishlashda davom etadi. Natijada, biz master rolida ikkita serverga ega bo'lamiz va ularning qaysi biri eng so'nggi ma'lumotlarga ega ekanligini bilmaymiz. Bu holat split-miya deb ham ataladi;
- Biz javobsiz qoldik. Bizning konfiguratsiyamizda master va bitta replika, almashtirilgandan so'ng, replika masterga o'tadi va bizda endi replika yo'q, shuning uchun biz yangi nusxani qo'lda qo'shishimiz kerak;
- Bizda 12 ta PostgreSQL parchasi mavjud bo'lsa-da, biz 12 ta klasterni kuzatishimiz kerak degan ma'noni anglatadigan holda, uzilish jarayonining qo'shimcha monitoringi kerak. Shardlar sonining ko'payishi bilan siz muvaffaqiyatsizlikni yangilashni ham unutmasligingiz kerak.
O'z-o'zidan yozilgan muvaffaqiyatsizlik juda murakkab ko'rinadi va ahamiyatsiz yordamni talab qiladi. Bitta PostgreSQL klasteri bilan bu eng oson variant bo'ladi, lekin u miqyosda emas, shuning uchun u bizga mos kelmaydi.
Repmgr
PostgreSQL klasterlarining ishlashini boshqarishi mumkin bo'lgan PostgreSQL klasterlari uchun replikatsiya menejeri. Shu bilan birga, u qutidan avtomatik ravishda uzilishga ega emas, shuning uchun ish uchun siz tayyor echimning ustiga o'zingizning "o'rashingiz" ni yozishingiz kerak bo'ladi. Shunday qilib, hamma narsa o'z-o'zidan yozilgan skriptlarga qaraganda ancha murakkab bo'lishi mumkin, shuning uchun biz hatto Repmgr-ni sinab ko'rmadik.
AWS RDS
Bizga kerak bo'lgan hamma narsani qo'llab-quvvatlaydi, zaxira nusxalarini yaratishni biladi va ulanishlar havzasini saqlaydi. U avtomatik almashtirishga ega: master vafot etganida, replika yangi masterga aylanadi va AWS dns yozuvini yangi masterga o'zgartiradi, replikalar esa turli AZlarda joylashgan bo'lishi mumkin.
Kamchiliklarga nozik sozlashlarning yo'qligi kiradi. Nozik sozlash misoli sifatida: bizning misollarimizda tcp ulanishlari uchun cheklovlar mavjud, ularni, afsuski, RDS da amalga oshirib bo'lmaydi:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
Bundan tashqari, AWS RDS oddiy namuna narxidan deyarli ikki baravar qimmat, bu ushbu yechimdan voz kechishning asosiy sababi edi.
Patroni
Bu yaxshi hujjatlar, avtomatik uzilish va github-dagi manba kodi bilan PostgreSQL-ni boshqarish uchun python shablonidir.
Patronining afzalliklari:
- Har bir konfiguratsiya parametri tasvirlangan, u qanday ishlashi aniq;
- Avtomatik uzilish qutidan tashqarida ishlaydi;
- Pythonda yozilgan va biz o'zimiz pythonda ko'p yozganimiz sababli, muammolarni hal qilish biz uchun osonroq bo'ladi va, ehtimol, loyihani rivojlantirishga yordam beradi;
- PostgreSQL-ni to'liq boshqaradi, bir vaqtning o'zida klasterning barcha tugunlaridagi konfiguratsiyani o'zgartirishga imkon beradi va agar yangi konfiguratsiyani qo'llash uchun klasterni qayta ishga tushirish kerak bo'lsa, bu Patroni yordamida yana amalga oshirilishi mumkin.
Kamchiliklari:
- PgBouncer bilan qanday qilib to'g'ri ishlash kerakligi hujjatlardan aniq emas. Garchi buni minus deb atash qiyin bo'lsa-da, chunki Patronining vazifasi PostgreSQLni boshqarish va Patroni bilan bog'lanish qanday davom etishi allaqachon bizning muammomiz;
- Patronini katta hajmlarda amalga oshirishning bir nechta misollari mavjud, noldan boshlab amalga oshirishning ko'plab misollari mavjud.
Natijada, biz muvaffaqiyatsiz klaster yaratish uchun Patronini tanladik.
Patronni amalga oshirish jarayoni
Patronidan oldin bizda asinxron replikatsiyali bitta master va bitta replika konfiguratsiyasida 12 ta PostgreSQL parchalari bor edi. Ilova serverlari ma'lumotlar bazalariga Network Load Balancer orqali kirishdi, ularning orqasida PgBouncer bilan ikkita nusxa va ularning orqasida barcha PostgreSQL serverlari bor edi.
Patroni-ni amalga oshirish uchun biz taqsimlangan saqlash klaster konfiguratsiyasini tanlashimiz kerak edi. Patroni etcd, Zookeeper, Consul kabi taqsimlangan konfiguratsiya saqlash tizimlari bilan ishlaydi. Bizda bozorda to'liq huquqli Konsul klasteri bor, u Vault bilan birgalikda ishlaydi va biz undan endi foydalanmaymiz. Konsuldan maqsadli foydalanishni boshlash uchun ajoyib sabab.
Patroni konsul bilan qanday ishlaydi
Bizda uchta tugundan iborat Konsul klasteri va yetakchi va replikadan iborat Patroni klasteri mavjud (Patronida usta klaster rahbari, qullar esa replika deb ataladi). Patroni klasterining har bir nusxasi doimiy ravishda konsulga klaster holati haqida ma'lumot yuboradi. Shu sababli, Konsuldan siz har doim Patroni klasterining joriy konfiguratsiyasini va hozirda kim etakchi ekanligini bilib olishingiz mumkin.
Patronni konsulga ulash uchun konsul bilan qanday ishlashimizga qarab http yoki https formatida xostni va ulanish sxemasini ixtiyoriy ravishda belgilashingiz kerak bo'lgan rasmiy hujjatlarni o'rganish kifoya:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpBu oddiy ko'rinadi, lekin bu erda tuzoqlar boshlanadi. Konsul bilan biz https orqali xavfsiz ulanish ustida ishlaymiz va ulanish konfiguratsiyasi quyidagicha ko'rinadi:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Lekin bu ishlamayapti. Ishga tushganda Patroni konsulga ulana olmaydi, chunki u baribir http orqali o'tishga harakat qiladi.
Patronining manba kodi muammoni hal qilishga yordam berdi. Yaxshiyamki, u python tilida yozilgan. Ma'lum bo'lishicha, xost parametri hech qanday tarzda tahlil qilinmagan va protokol sxemada ko'rsatilishi kerak. Konsul bilan ishlash uchun ishchi konfiguratsiya bloki biz uchun shunday ko'rinadi:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}konsul shabloni
Shunday qilib, biz konfiguratsiya uchun saqlash joyini tanladik. Endi biz Patroni klasteridagi liderni o'zgartirganda PgBouncer o'z konfiguratsiyasini qanday o'zgartirishini tushunishimiz kerak. Hujjatlarda bu savolga javob yo'q, chunki. u erda, qoida tariqasida, PgBouncer bilan ishlash tasvirlanmagan.
Yechim izlab, biz maqolani topdik (afsuski, sarlavhani eslay olmayman), unda Konsul shablonlari PgBouncer va Patroni-ni ulashda katta yordam bergani yozilgan. Bu bizni Konsul shablonining qanday ishlashini tekshirishga undadi.
Aniqlanishicha, Consul-shabloni doimiy ravishda Konsuldagi PostgreSQL klasteri konfiguratsiyasini kuzatib boradi. Rahbar o'zgarganda, u PgBouncer konfiguratsiyasini yangilaydi va uni qayta yuklash uchun buyruq yuboradi.
Shablonning katta afzalligi shundaki, u kod sifatida saqlanadi, shuning uchun yangi parcha qo'shganda, yangi majburiyatni bajarish va shablonni avtomatik ravishda yangilash, Infratuzilmani kod printsipi sifatida qo'llab-quvvatlash kifoya.
Patroni bilan yangi arxitektura
Natijada biz quyidagi ish sxemasini oldik:
Barcha dastur serverlari balanslagichga kirishadi β uning orqasida ikkita PgBouncer nusxasi mavjud β har bir misolda har bir Patroni klasterining holatini kuzatuvchi va joriy rahbarga so'rov yuboradigan PgBouncer konfiguratsiyasining dolzarbligini nazorat qiluvchi Konsul shablonini ishga tushiradi. har bir klasterdan.
Qo'lda sinov
Biz ushbu sxemani kichik sinov muhitida ishga tushirishdan oldin ishga tushirdik va avtomatik almashtirishning ishlashini tekshirdik. Ular doskani ochishdi, stikerni siljitishdi va o'sha paytda ular klaster rahbarini "o'ldirishdi". AWS-da bu konsol orqali misolni o'chirish kabi oddiy.
Stiker 10-20 soniya ichida qaytib keldi va keyin yana normal harakatlana boshladi. Bu Patroni klasteri to'g'ri ishlaganligini anglatadi: u rahbarni o'zgartirdi, ma'lumotni Konsulga yubordi va Konsul shablon darhol bu ma'lumotni oldi, PgBouncer konfiguratsiyasini almashtirdi va qayta yuklash uchun buyruq yubordi.
Qanday qilib yuqori yuk ostida omon qolish va ish vaqtini minimal saqlash kerak?
Hammasi mukammal ishlaydi! Ammo yangi savollar bor: u yuqori yuk ostida qanday ishlaydi? Qanday qilib hamma narsani tez va xavfsiz tarzda ishlab chiqarishga chiqarish mumkin?
Biz yuk testini o'tkazadigan sinov muhiti birinchi savolga javob berishga yordam beradi. Arxitektura jihatidan ishlab chiqarish bilan mutlaqo bir xil va ishlab chiqarish hajmiga taxminan teng bo'lgan sinov ma'lumotlarini yaratdi. Sinov paytida biz PostgreSQL ustalaridan birini "o'ldirishga" va nima bo'lishini ko'rishga qaror qildik. Ammo bundan oldin avtomatik prokatni tekshirish muhim, chunki bu muhitda bizda bir nechta PostgreSQL parchalari mavjud, shuning uchun ishlab chiqarishdan oldin konfiguratsiya skriptlarini mukammal sinovdan o'tkazamiz.
Ikkala vazifa ham shuhratparast ko'rinadi, ammo bizda PostgreSQL 9.6. Darhol 11.2 ga yangilashimiz mumkinmi?
Biz buni 2 bosqichda amalga oshirishga qaror qildik: birinchi navbatda 11.2 ga yangilang, keyin Patronini ishga tushiring.
PostgreSQL yangilanishi
PostgreSQL versiyasini tezda yangilash uchun opsiyadan foydalaning -k, unda qattiq havolalar diskda yaratilgan va ma'lumotlaringizni nusxalashning hojati yo'q. 300-400 GB bazalarda yangilanish 1 soniya davom etadi.
Bizda juda ko'p parchalar bor, shuning uchun yangilanish avtomatik ravishda amalga oshirilishi kerak. Buning uchun biz butun yangilash jarayonini boshqaradigan Ansible o'yin kitobini yozdik:
/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='Bu erda shuni ta'kidlash kerakki, yangilashni boshlashdan oldin uni parametr bilan bajarishingiz kerak --tekshirishyangilashingiz mumkinligiga ishonch hosil qilish uchun. Bizning skriptimiz yangilanish davomida konfiguratsiyalarni almashtirishni ham amalga oshiradi. Bizning skriptimiz 30 soniyada yakunlandi, bu ajoyib natija.
Patroni-ni ishga tushiring
Ikkinchi muammoni hal qilish uchun Patroni konfiguratsiyasiga qarang. Rasmiy omborda initdb bilan namuna konfiguratsiyasi mavjud bo'lib, u Patronni birinchi marta ishga tushirganingizda yangi ma'lumotlar bazasini ishga tushirish uchun javobgardir. Ammo bizda allaqachon tayyor ma'lumotlar bazasi mavjud bo'lganligi sababli, biz ushbu bo'limni konfiguratsiyadan olib tashladik.
Biz allaqachon mavjud PostgreSQL klasteriga Patroni o'rnatishni va uni ishga tushirishni boshlaganimizda, biz yangi muammoga duch keldik: ikkala server ham yetakchi sifatida ish boshladi. Patroni klasterning dastlabki holati haqida hech narsa bilmaydi va ikkala serverni bir xil nomdagi ikkita alohida klaster sifatida ishga tushirishga harakat qiladi. Ushbu muammoni hal qilish uchun siz quldagi ma'lumotlar bilan katalogni o'chirishingiz kerak:
rm -rf /var/lib/postgresql/Buni faqat qulda qilish kerak!
Toza replika ulanganda, Patroni bazaviy zaxira yetakchisini yaratadi va uni replikaga tiklaydi, so'ngra wal jurnallariga ko'ra joriy holatni ushlaydi.
Biz duch kelgan yana bir qiyinchilik shundaki, barcha PostgreSQL klasterlari sukut bo'yicha asosiy deb nomlanadi. Har bir klaster boshqasi haqida hech narsa bilmasa, bu normal holat. Ammo Patroni-dan foydalanmoqchi bo'lganingizda, barcha klasterlar noyob nomga ega bo'lishi kerak. Yechim PostgreSQL konfiguratsiyasida klaster nomini o'zgartirishdir.
yuk sinovi
Biz platalarda foydalanuvchi tajribasini simulyatsiya qiluvchi testni ishga tushirdik. Yuk bizning o'rtacha kunlik qiymatimizga yetganda, biz xuddi shu testni takrorladik, PostgreSQL yetakchisi bilan bitta misolni o'chirib qo'ydik. Avtomatik uzilish biz kutgandek ishladi: Patroni yetakchini oβzgartirdi, Konsul shablon PgBouncer konfiguratsiyasini yangiladi va qayta yuklash uchun buyruq yubordi. Grafana-dagi grafiklarimizdan ma'lum bo'lishicha, ma'lumotlar bazasiga ulanish bilan bog'liq serverlardan 20-30 soniya kechikishlar va oz miqdorda xatolar borligi aniq edi. Bu odatiy holat, bunday qiymatlar bizning uzilishlarimiz uchun maqbuldir va xizmatning uzilish vaqtidan yaxshiroq.
Patroni ishlab chiqarishga olib kelish
Natijada biz quyidagi rejani tuzdik:
- Konsul shablonini PgBouncer serverlariga joylashtiring va ishga tushiring;
- PostgreSQL 11.2 versiyasiga yangilanadi;
- Klaster nomini o'zgartiring;
- Patroni klasterini ishga tushirish.
Shu bilan birga, bizning sxemamiz deyarli istalgan vaqtda birinchi fikrni aytishga imkon beradi, biz har bir PgBouncerni navbat bilan ishdan olib tashlashimiz va konsul shablonini joylashtirishimiz va ishga tushirishimiz mumkin. Shunday qildik.
Tez o'rnatish uchun biz Ansible-dan foydalandik, chunki biz barcha o'yin kitoblarini sinov muhitida sinab ko'rdik va to'liq skriptni bajarish vaqti har bir parcha uchun 1,5 dan 2 minutgacha edi. Biz xizmatimizni to'xtatmasdan hamma narsani navbatma-navbat har bir qismga tarqatishimiz mumkin edi, lekin har bir PostgreSQLni bir necha daqiqaga o'chirib qo'yishimiz kerak edi. Bunday holda, ma'lumotlari ushbu parchada bo'lgan foydalanuvchilar hozirda to'liq ishlay olmaydilar va bu biz uchun qabul qilinishi mumkin emas.
Ushbu vaziyatdan chiqish yo'li har 3 oyda bir marta o'tkaziladigan rejalashtirilgan ta'mirlash edi. Bu biz xizmatimizni to'liq o'chirib, ma'lumotlar bazasi namunalarini yangilaganimizda rejalashtirilgan ish uchun oyna. Keyingi oynaga bir hafta qoldi va biz kutishga va ko'proq tayyorgarlik ko'rishga qaror qildik. Kutish vaqtida biz qo'shimcha ravishda o'zimizni himoya qildik: har bir PostgreSQL parchasi uchun so'nggi ma'lumotlar saqlanmasa, zaxira nusxasini yaratdik va har bir parcha uchun Patroni klasterida yangi nusxaga aylanishi kerak bo'lgan yangi nusxani qo'shdik, ma'lumotlarni o'chirish uchun buyruqni bajarmaslik uchun. Bularning barchasi xato xavfini minimallashtirishga yordam berdi.
Biz xizmatimizni qayta ishga tushirdik, hamma narsa kerak bo'lganidek ishladi, foydalanuvchilar ishlashda davom etishdi, ammo grafiklarda biz konsul serverlarida g'ayritabiiy yuqori yukni ko'rdik.
Nega biz buni sinov muhitida ko'rmadik? Bu muammo Infratuzilmani kod printsipi sifatida kuzatish va sinov muhitidan tortib ishlab chiqarishgacha bo'lgan butun infratuzilmani takomillashtirish zarurligini juda yaxshi ko'rsatadi. Aks holda, biz ega bo'lgan muammoni hal qilish juda oson. Nima sodir bo `LDI? Konsul dastlab ishlab chiqarishda paydo bo'ldi, so'ngra sinov muhitida, natijada sinov muhitida konsul versiyasi ishlab chiqarishdan yuqori bo'ldi. Relizlarning birida konsul shablonlari bilan ishlashda protsessor oqishi hal qilindi. Shuning uchun biz konsulni yangiladik, shu bilan muammoni hal qildik.
Patroni klasterini qayta ishga tushiring
Biroq, bizda yangi muammo paydo bo'ldi, biz buni hatto gumon qilmagan edik. Konsulni yangilashda biz konsulni tark etish buyrug'i yordamida konsul tugunini klasterdan olib tashlaymiz β Patroni boshqa Konsul serveriga ulanadi β hammasi ishlaydi. Ammo biz Konsul klasterining oxirgi nusxasiga etib borganimizda va unga konsul ruxsati buyrug'ini yuborganimizda, barcha Patroni klasterlari shunchaki qayta ishga tushdi va jurnallarda biz quyidagi xatoni ko'rdik:
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 klasteri oΚ»z klasteri haqida maΚΌlumot ololmadi va qayta ishga tushdi.
Yechim topish uchun biz githubβdagi muammo orqali Patroni mualliflari bilan bogβlandik. Ular konfiguratsiya fayllarimizni yaxshilashni taklif qilishdi:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Biz muammoni sinov muhitida takrorlay oldik va u yerda bu variantlarni sinab ko'rdik, lekin afsuski, ular ishlamadi.
Muammo haligacha hal etilmagan. Biz quyidagi echimlarni sinab ko'rishni rejalashtirmoqdamiz:
- Har bir Patroni klaster misolida Konsul-agentdan foydalaning;
- Koddagi muammoni hal qiling.
Xato qaerda sodir bo'lganini tushunamiz: muammo, ehtimol, konfiguratsiya fayli orqali bekor qilinmagan standart vaqt tugashidan foydalanishdir. Oxirgi Konsul serveri klasterdan olib tashlanganda, butun Konsul klasteri bir soniyadan ko'proq vaqt davomida osilib qoladi, shu sababli Patroni klaster holatini ololmaydi va butun klasterni butunlay qayta ishga tushiradi.
Yaxshiyamki, biz boshqa xatolarga duch kelmadik.
Patronidan foydalanish natijalari
Patroni muvaffaqiyatli ishga tushirilgandan so'ng, biz har bir klasterga qo'shimcha nusxa qo'shdik. Endi har bir klasterda kvorumning o'xshashligi mavjud: kommutatsiya paytida miya bo'linishida xavfsizlik tarmog'i uchun bitta etakchi va ikkita replika.
Patroni uch oydan ortiq ishlab chiqarish ustida ishlamoqda. Bu vaqt ichida u allaqachon bizga yordam berishga muvaffaq bo'ldi. Yaqinda klasterlardan birining rahbari AWSda vafot etdi, avtomatik uzilish ishladi va foydalanuvchilar ishlashda davom etishdi. Patroni o'zining asosiy vazifasini bajardi.
Patroni-dan foydalanishning kichik xulosasi:
- Konfiguratsiyani o'zgartirish qulayligi. Bitta nusxada konfiguratsiyani o'zgartirish kifoya va u butun klasterga tortiladi. Agar yangi konfiguratsiyani qo'llash uchun qayta ishga tushirish kerak bo'lsa, Patroni sizga xabar beradi. Patroni butun klasterni bitta buyruq bilan qayta ishga tushirishi mumkin, bu ham juda qulay.
- Avtomatik uzilish ishlaydi va allaqachon bizga yordam berishga muvaffaq bo'ldi.
- PostgreSQL yangilanishi ilovaning uzilish vaqtisiz. Avval replikalarni yangi versiyaga yangilashingiz kerak, keyin Patroni klasteridagi yetakchini o'zgartiring va eski yetakchini yangilang. Bunday holda, avtomatik uzilishning zaruriy sinovi sodir bo'ladi.
Manba: www.habr.com