Patronining asosiy maqsadi PostgreSQL uchun yuqori darajada mavjudligini ta'minlashdir. Ammo Patroni tayyor vosita emas, shunchaki shablondir (bu, umuman olganda, hujjatlarda aytilgan). Bir qarashda, Patroni-ni sinov laboratoriyasida o'rnatganingizdan so'ng, siz uning qanday ajoyib vosita ekanligini va klasterni buzishga urinishlarimizni qanchalik osonlik bilan hal qilishini ko'rishingiz mumkin. Biroq, amalda ishlab chiqarish muhitida hamma narsa har doim ham sinov laboratoriyasidagi kabi chiroyli va oqlangan tarzda sodir bo'lmaydi.
Men sizga o'zim haqimda bir oz aytib beraman. Men tizim administratori sifatida ish boshladim. Veb ishlab chiqishda ishlagan. Men Data Egret kompaniyasida 2014 yildan beri ishlayman. Kompaniya Postgres sohasida konsalting bilan shug'ullanadi. Va biz aynan Postgres-ga xizmat qilamiz va biz Postgres bilan har kuni ishlaymiz, shuning uchun biz operatsiya bilan bog'liq turli xil tajribaga egamiz.
Va 2018 yil oxirida biz Patronidan asta-sekin foydalana boshladik. Va ba'zi tajribalar to'plangan. Biz qandaydir tarzda tashxis qo'ydik, sozladik va eng yaxshi tajribamizga keldik. Va bu hisobotda men ular haqida gapiraman.
Postgresdan tashqari, men Linuxni yaxshi ko'raman. Men uni aylanib o'tishni va kashf qilishni yaxshi ko'raman, men yadrolarni yig'ishni yaxshi ko'raman. Menga virtualizatsiya, konteynerlar, docker, Kubernetes yoqadi. Bularning barchasi meni qiziqtiradi, chunki eski administrator odatlari ta'sir qiladi. Men monitoring bilan shug'ullanishni yaxshi ko'raman. Va men postgresni boshqaruv bilan bog'liq narsalarni yaxshi ko'raman, ya'ni replikatsiya, zaxira. Bo'sh vaqtimda esa Go'da yozaman. Men dasturiy ta'minot muhandisi emasman, faqat Go'da o'zim uchun yozaman. Va bu menga zavq bag'ishlaydi.
- O'ylaymanki, ko'plaringiz Postgres-da HA (Yuqori mavjudlik) mavjud emasligini bilasiz. HAni olish uchun siz biror narsani o'rnatishingiz, uni sozlashingiz, harakat qilishingiz va uni olishingiz kerak.
- Bir nechta vositalar mavjud va Patroni ulardan biri HAni juda ajoyib va ββjuda yaxshi hal qiladi. Ammo bularning barchasini sinov laboratoriyasiga qo'yish va uni ishga tushirish orqali biz hammasi ishlayotganini ko'rishimiz mumkin, biz ba'zi muammolarni takrorlashimiz mumkin, Patroni ularga qanday xizmat qilishini ko'rishimiz mumkin. Va biz hammasi ajoyib ishlayotganini ko'ramiz.
- Ammo amalda biz turli muammolarga duch keldik. Va men bu muammolar haqida gapiraman.
- Sizga qanday tashxis qo'yganimizni, nimani o'zgartirganimizni - bu bizga yordam berdimi yoki yo'qmi, aytib beraman.
- Men sizga Patronni qanday o'rnatishni aytmayman, chunki siz Internetda google qilishingiz mumkin, barchasi qanday boshlanganini, qanday tuzilganligini tushunish uchun konfiguratsiya fayllarini ko'rishingiz mumkin. Siz sxemalarni, arxitekturalarni tushunishingiz mumkin, bu haqda Internetda ma'lumot topasiz.
- Men boshqa birovning tajribasi haqida gapirmayman. Men faqat biz duch kelgan muammolar haqida gapiraman.
- Va men Patroni va PostgreSQL-dan tashqaridagi muammolar haqida gapirmayman. Agar, masalan, muvozanat bilan bog'liq muammolar mavjud bo'lsa, bizning klasterimiz qulab tushganda, men bu haqda gapirmayman.
Va hisobotimizni boshlashdan oldin kichik bir rad etish.
Biz duch kelgan bu muammolarning barchasi bizda operatsiyaning dastlabki 6-7-8 oylarida bo'lgan. Vaqt o'tishi bilan biz eng yaxshi ichki amaliyotimizga keldik. Va bizning muammolarimiz yo'qoldi. Shuning uchun, hisobot taxminan olti oy oldin e'lon qilingan edi, o'shanda hammasi yangi edi va men hammasini yaxshi esladim.
Hisobotni tayyorlash jarayonida men allaqachon eski postmortemlarni ko'tardim, jurnallarga qaradim. Muammolarni tahlil qilish chogβida baβzi tafsilotlarni unutib qoβyish yoki baβzi tafsilotlarni toβliq oβrganib boβlmaydi, shuning uchun ham baβzi nuqtalarda muammolar toβliq koβrib chiqilmagandek tuyulishi yoki maβlumotlarning yetishmasligi kuzatilishi mumkin. Va shuning uchun sizdan bu daqiqa uchun meni kechirishingizni so'rayman.
Patroni nima?
- Bu HA qurish uchun shablondir. Hujjatlarda shunday deyilgan. Va mening nuqtai nazarimdan, bu juda to'g'ri tushuntirish. Patroni barcha muammolaringizni hal qiladigan kumush o'q emas, ya'ni uning ishlashi va foyda keltirishi uchun harakat qilish kerak.
- Bu har bir ma'lumotlar bazasi xizmatiga o'rnatilgan agent xizmati va Postgres uchun o'ziga xos init tizimidir. U Postgres-ni ishga tushiradi, to'xtatadi, qayta ishga tushiradi, qayta sozlaydi va klasteringiz topologiyasini o'zgartiradi.
- Shunga ko'ra, klaster holatini saqlash uchun uning hozirgi ko'rinishi, ko'rinishidan, qandaydir saqlash kerak. Va shu nuqtai nazardan, Patroni tashqi tizimda davlatni saqlash yo'lini oldi. Bu taqsimlangan konfiguratsiyani saqlash tizimi. Bu Etcd, Consul, ZooKeeper yoki kubernetes Etcd bo'lishi mumkin, ya'ni ushbu variantlardan biri.
- Patronining xususiyatlaridan biri shundaki, siz avtofilerni qutidan chiqarib olasiz, faqat uni sozlash orqali. Taqqoslash uchun Repmgr-ni oladigan bo'lsak, u erda faylni o'z ichiga oladi. Repmgr bilan biz o'tishni olamiz, lekin agar biz avtofilerni xohlasak, uni qo'shimcha ravishda sozlashimiz kerak. Patronida allaqachon avtofiler mavjud.
- Va boshqa ko'plab narsalar mavjud. Masalan, konfiguratsiyalarni saqlash, yangi nusxalarni quyish, zaxiralash va hokazo. Lekin bu hisobot doirasidan tashqarida, men bu haqda gapirmayman.
Va kichik natija shundaki, Patronining asosiy vazifasi avtofaylni yaxshi va ishonchli bajarishdir, shunda bizning klasterimiz ishlaydi va dastur klaster topologiyasidagi o'zgarishlarni sezmaydi.
Ammo biz Patroni-dan foydalanishni boshlaganimizda, tizimimiz biroz murakkablashadi. Agar ilgari bizda Postgres bo'lsa, Patroni-dan foydalanganda biz Patronining o'zini olamiz, davlat saqlanadigan DCSni olamiz. Va barchasi qandaydir tarzda ishlashi kerak. Xo'sh, nima noto'g'ri bo'lishi mumkin?
Buzilishi mumkin:
- Postgres buzilishi mumkin. Bu usta yoki replika bo'lishi mumkin, ulardan biri muvaffaqiyatsiz bo'lishi mumkin.
- Patronining o'zi sinishi mumkin.
- Holat saqlanadigan DCS buzilishi mumkin.
- Va tarmoq uzilishi mumkin.
Bu fikrlarning barchasini men hisobotda ko'rib chiqaman.
Men ishlarni ko'p tarkibiy qismlarni o'z ichiga oladi degan nuqtai nazardan emas, balki ular yanada murakkablashgani uchun ko'rib chiqaman. Va sub'ektiv his-tuyg'ular nuqtai nazaridan, bu ish men uchun qiyin edi, uni qismlarga ajratish qiyin edi ... va aksincha, ba'zi holatlar engil edi va uni qismlarga ajratish oson edi.
Va birinchi holat eng oson. Biz ma'lumotlar bazasi klasterini olganimizda va DCS xotiramizni xuddi shu klasterda joylashtirganimizda shunday bo'ladi. Bu eng keng tarqalgan xato. Bu arxitekturalarni qurishda xato, ya'ni turli komponentlarni bir joyda birlashtirish.
Shunday qilib, filler bor edi, keling, nima bo'lganini hal qilish uchun boraylik.
Va bu erda biz filler qachon sodir bo'lganligi bilan qiziqamiz. Ya'ni, bizni klaster holati o'zgargan paytda qiziqtiradi.
Lekin filler har doim ham bir zumda emas, ya'ni vaqt birligini talab qilmaydi, uni kechiktirish mumkin. Bu uzoq davom etishi mumkin.
Shuning uchun, uning boshlanish vaqti va tugash vaqti bor, ya'ni bu doimiy hodisadir. Va biz barcha hodisalarni uchta intervalga ajratamiz: bizda to'ldiruvchidan oldin, to'ldiruvchi paytida va to'ldiruvchidan keyin vaqt bor. Ya'ni, biz ushbu vaqt jadvalidagi barcha voqealarni ko'rib chiqamiz.
Va birinchi narsa, filler sodir bo'lganida, biz nima sodir bo'lganligini, nima sabab bo'lganini fillerga olib kelganini qidiramiz.
Agar jurnallarga qarasak, ular klassik Patroni jurnallari bo'ladi. U bizga ularda server ustaga aylanganligini va masterning roli bu tugunga o'tganligini aytadi. Bu erda ta'kidlangan.
Keyinchalik, filler nima uchun sodir bo'lganini, ya'ni asosiy rolning bir tugundan ikkinchisiga o'tishiga sabab bo'lgan qanday voqealar sodir bo'lganini tushunishimiz kerak. Va bu holda, hamma narsa oddiy. Saqlash tizimi bilan ishlashda xatolik yuz berdi. Usta DCS bilan ishlay olmasligini, ya'ni o'zaro aloqada qandaydir muammo borligini tushundi. U esa endi usta boβlolmasligini aytib, ishdan ketadi. Bu "o'zini pastga tushirilgan" qatori aynan shuni aytadi.
Agar biz to'ldiruvchidan oldingi voqealarni ko'rib chiqsak, u erda sehrgarning davom etishi uchun muammo bo'lgan sabablarni ko'rishimiz mumkin.
Agar Patroni jurnallarini ko'rib chiqsak, bizda juda ko'p xatolar, vaqt tugashi borligini ko'ramiz, ya'ni Patroni agenti DCS bilan ishlay olmaydi. Bu holda, bu 8500 portida aloqa o'rnatadigan konsul agenti.
Muammo shundaki, Patroni va ma'lumotlar bazasi bir xil xostda ishlaydi. Va konsul serverlari xuddi shu tugunda ishga tushirildi. Serverda yuk yaratish orqali biz Konsul serverlari uchun ham muammolarni yaratdik. Ular to'g'ri muloqot qila olmadilar.
Bir muncha vaqt o'tgach, yuk kamaygach, bizning Patronimiz yana agentlar bilan bog'lanishga muvaffaq bo'ldi. Oddiy ish qayta tiklandi. Va o'sha Pgdb-2 serveri yana usta bo'ldi. Ya'ni, kichik bir burilish sodir bo'ldi, buning natijasida tugun ustaning vakolatlaridan voz kechdi va keyin ularni yana o'z zimmasiga oldi, ya'ni hamma narsa avvalgidek qaytdi.
Va buni yolg'on signal deb hisoblash mumkin yoki Patroni hamma narsani to'g'ri qilgan deb hisoblash mumkin. Ya'ni, u klaster holatini saqlay olmasligini tushundi va o'z vakolatini olib tashladi.
Va bu erda muammo Konsul serverlari bazalar bilan bir xil uskunada bo'lganligi sababli paydo bo'ldi. Shunga ko'ra, har qanday yuk: disklar yoki protsessorlardagi yuk bo'ladimi, u ham Konsul klasteri bilan o'zaro ta'sir qiladi.
Va biz birga yashamaslikka qaror qildik, biz konsul uchun alohida klaster ajratdik. Va Patroni allaqachon alohida Konsul bilan ishlagan, ya'ni alohida Postgres klasteri, alohida Konsul klasteri mavjud edi. Bu barcha narsalarni birga yashamasligi uchun qanday qilib olib yurish va saqlash bo'yicha asosiy ko'rsatma.
Variant sifatida siz ttl, loop_wait, retry_timeout parametrlarini burishingiz mumkin, ya'ni ushbu parametrlarni oshirish orqali ushbu qisqa muddatli yuk cho'qqilaridan omon qolishga harakat qiling. Lekin bu eng mos variant emas, chunki bu yuk uzoq vaqt davomida bo'lishi mumkin. Va biz ushbu parametrlarning chegaralaridan tashqariga chiqamiz. Va bu haqiqatan ham yordam bermasligi mumkin.
Birinchi muammo, siz tushunganingizdek, oddiy. Biz DCSni baza bilan birga olib, joylashtirdik, muammoga duch keldik.
Ikkinchi muammo birinchisiga o'xshaydi. Shunga o'xshab, bizda yana DCS tizimi bilan o'zaro ishlashda muammolar mavjud.
Agar biz jurnallarga qarasak, bizda yana aloqa xatosi borligini ko'ramiz. Va Patronining aytishicha, men DCS bilan aloqa qila olmayman, shuning uchun joriy master replika rejimiga o'tadi.
Qadimgi usta nusxaga aylanadi, bu erda Patroni shunday bo'lishi kerak bo'lgan tarzda ishlaydi. U tranzaktsiyalar jurnalini orqaga o'tkazish uchun pg_rewind-ni ishga tushiradi, so'ngra yangi master bilan aloqa qilish uchun yangi masterga ulanadi. Bu erda Patroni kerak bo'lganidek ishlaydi.
Bu erda biz to'ldiruvchidan oldingi joyni, ya'ni faylga ega bo'lishimizga sabab bo'lgan xatolarni topishimiz kerak. Va shu nuqtai nazardan, Patroni jurnallari bilan ishlash juda qulay. U ma'lum bir oraliqda bir xil xabarlarni yozadi. Va agar biz ushbu jurnallarni tezda aylanib chiqa boshlasak, u holda jurnallardan jurnallar o'zgarganini ko'ramiz, bu ba'zi muammolar boshlanganligini anglatadi. Biz tezda bu joyga qaytamiz, nima bo'lishini ko'ramiz.
Va oddiy holatda, jurnallar shunday ko'rinadi. Qulfning egasi tekshiriladi. Va agar egasi, masalan, o'zgargan bo'lsa, Patroni javob berishi kerak bo'lgan ba'zi voqealar sodir bo'lishi mumkin. Ammo bu holatda biz yaxshimiz. Biz xatolar boshlangan joyni qidirmoqdamiz.
Va xatolar paydo bo'ladigan nuqtaga o'tib, biz avtomatik faylni o'tkazganimizni ko'ramiz. Va bizning xatolarimiz DCS bilan o'zaro aloqada bo'lganligi sababli va bizning holatlarimizda biz Konsuldan foydalanganmiz, biz konsul jurnallariga ham qaraymiz, u erda nima sodir bo'lgan.
Taxminan konsul klasteridagi qo'shnilarimiz konsul klasterining boshqa a'zolari mavjudligiga shubha qila boshlaganini ko'ramiz.
Va agar siz boshqa konsul agentlarining jurnallariga ham qarasangiz, u erda qandaydir tarmoq qulashi sodir bo'layotganini ham ko'rishingiz mumkin. Konsul klasterining barcha a'zolari bir-birlarining mavjudligiga shubha qilishadi. Va bu filler uchun turtki bo'ldi.
Agar siz ushbu xatolardan oldin sodir bo'lgan narsalarni ko'rsangiz, har xil xatolar mavjudligini ko'rishingiz mumkin, masalan, oxirgi muddat, RPC tushib ketdi, ya'ni konsul klasteri a'zolarining bir-biri bilan o'zaro munosabatlarida qandaydir muammo borligi aniq. .
Eng oddiy javob - tarmoqni ta'mirlash. Lekin shohsupada turgan men uchun buni aytish oson. Ammo vaziyat shundayki, mijoz har doim ham tarmoqni ta'mirlashga qodir emas. U DCda yashashi va tarmoqni ta'mirlay olmasligi, uskunaga ta'sir qilishi mumkin. Va shuning uchun boshqa variantlar kerak.
Variantlar mavjud:
- Mening fikrimcha, hujjatlarda yozilgan eng oddiy variant - bu konsul tekshiruvlarini o'chirish, ya'ni bo'sh massivni o'tkazish. Va biz konsul agentiga hech qanday cheklardan foydalanmaslikni aytamiz. Ushbu tekshiruvlar yordamida biz ushbu tarmoq bo'ronlarini e'tiborsiz qoldiramiz va faylni ishga tushirmasligimiz mumkin.
- Yana bir variant - raft_multiplierni ikki marta tekshirish. Bu Konsul serverining o'zi parametridir. Odatiy bo'lib, u 5 ga o'rnatiladi. Bu qiymat staging muhitlari uchun hujjatlar tomonidan tavsiya etiladi. Aslida, bu Konsul tarmog'i a'zolari o'rtasidagi xabar almashish chastotasiga ta'sir qiladi. Aslida, bu parametr Konsul klasteri a'zolari o'rtasidagi xizmat aloqasi tezligiga ta'sir qiladi. Va ishlab chiqarish uchun, tugunlar tez-tez xabar almashishi uchun uni kamaytirish tavsiya etiladi.
- Biz o'ylab topgan yana bir variant - bu operatsion tizimning jarayon rejalashtiruvchisi uchun boshqa jarayonlar orasida Konsul jarayonlarining ustuvorligini oshirish. Bunday "yaxshi" parametr mavjud, u faqat rejalashtirishda OS rejalashtiruvchisi tomonidan hisobga olinadigan jarayonlarning ustuvorligini belgilaydi. Shuningdek, biz konsul agentlari uchun yoqimli qiymatni kamaytirdik, ya'ni. operatsion tizim konsul jarayonlariga ishlash va kodini bajarish uchun ko'proq vaqt berish uchun ustuvorlikni oshirdi. Bizning holatlarimizda bu bizning muammomizni hal qildi.
- Yana bir variant - konsuldan foydalanmaslik. Mening Etcd ning katta tarafdori bo'lgan do'stim bor. Va biz muntazam ravishda u bilan qaysi biri yaxshiroq Etcd yoki Konsul deb bahslashamiz. Ammo qaysi biri yaxshiroq bo'lsa, biz odatda konsulning har bir tugunda ma'lumotlar bazasi bilan ishlashi kerak bo'lgan agenti borligi bilan rozi bo'lamiz. Ya'ni, Patronining Konsul klasteri bilan o'zaro aloqasi ushbu agent orqali o'tadi. Va bu agent darboΔazga aylanadi. Agar agentga biror narsa yuz bersa, Patroni endi Konsul klasteri bilan ishlay olmaydi. Va bu muammo. Etcd rejasida agent yo'q. Patroni to'g'ridan-to'g'ri Etcd serverlari ro'yxati bilan ishlashi va ular bilan allaqachon aloqa qilishi mumkin. Shu munosabat bilan, agar siz kompaniyangizda Etcd dan foydalansangiz, Etcd konsuldan ko'ra yaxshiroq tanlov bo'lishi mumkin. Ammo biz mijozlarimiz sifatida har doim mijoz tanlagan va foydalanadigan narsalar bilan cheklanamiz. Va bizda barcha mijozlar uchun konsul bor.
- Va oxirgi nuqta - parametr qiymatlarini qayta ko'rib chiqish. Bizning qisqa muddatli tarmoq muammolarimiz qisqa bo'ladi va bu parametrlar doirasidan tashqariga chiqmaydi degan umidda ushbu parametrlarni oshirishimiz mumkin. Shunday qilib, agar tarmoq muammolari yuzaga kelsa, biz Patronining avtomatik faylga agressivligini kamaytirishimiz mumkin.
O'ylaymanki, Patroni ishlatadigan ko'pchilik bu buyruq bilan tanish.
Ushbu buyruq klasterning joriy holatini ko'rsatadi. Va birinchi qarashda, bu rasm odatiy ko'rinishi mumkin. Bizda usta bor, bizda replika bor, replikatsiya kechikishi yo'q. Ammo biz ushbu klasterda ikkita emas, uchta tugun bo'lishi kerakligini bilmagunimizcha, bu rasm normaldir.
Shunga ko'ra, avtofayl mavjud edi. Va bu avtofayldan keyin bizning nusxamiz yo'qoldi. Biz uning nima uchun g'oyib bo'lganini aniqlashimiz va uni qaytarib olib kelishimiz, uni tiklashimiz kerak. Va biz yana jurnallarga o'tamiz va nima uchun bizda avtomatik faylni ko'rishni bilib olamiz.
Bunday holda, ikkinchi nusxa ustaga aylandi. Bu yerda hammasi joyida.
Va biz tushib qolgan va klasterda bo'lmagan nusxaga qarashimiz kerak. Biz Patroni jurnallarini ochamiz va pg_rewind bosqichida klasterga ulanish jarayonida muammoga duch kelganimizni ko'ramiz. Klasterga ulanish uchun siz tranzaktsiyalar jurnalini orqaga o'tkazishingiz, masterdan kerakli tranzaktsiyalar jurnalini so'rashingiz va undan masterga yetib olish uchun foydalanishingiz kerak.
Bunday holda, bizda tranzaktsiyalar jurnali yo'q va replikatsiya boshlana olmaydi. Shunga ko'ra, biz Postgresni xato bilan to'xtatamiz. Va shuning uchun u klasterda emas.
Nima uchun u klasterda emasligini va nima uchun jurnallar yo'qligini tushunishimiz kerak. Biz yangi ustaga boramiz va uning jurnallarida nima borligini ko'rib chiqamiz. Ma'lum bo'lishicha, pg_rewind bajarilganda, nazorat nuqtasi paydo bo'lgan. Va eski tranzaksiya jurnallarining ba'zilari shunchaki nomi o'zgartirildi. Qadimgi usta yangi ustaga ulanishga va ushbu jurnallarni so'rashga harakat qilganda, ular allaqachon nomini o'zgartirdilar, ular yo'q edi.
Men bu voqealar sodir bo'lgan vaqt belgilarini solishtirdim. Va bu erda farq tom ma'noda 150 millisekundni tashkil etadi, ya'ni nazorat punkti 369 millisekundda yakunlandi, WAL segmentlari qayta nomlandi. Va tom ma'noda 517 yilda, 150 millisekunddan so'ng, eski nusxada orqaga o'rash boshlandi. Ya'ni, replika ulana olmasligi va pul ishlamasligi uchun biz uchun tom ma'noda 150 millisekund etarli edi.
Qanday variantlar mavjud?
Biz dastlab replikatsiya slotlaridan foydalanganmiz. Biz buni yaxshi deb o'yladik. Garchi operatsiyaning birinchi bosqichida biz uyalarni o'chirib qo'ydik. Bizga tuyuldiki, agar uyalar juda ko'p WAL segmentlarini to'plasa, biz masterni tashlab yuborishimiz mumkin. U tushadi. Biz uyalarsiz bir muncha vaqt azob chekdik. Va biz uyalar kerakligini angladik, biz uyalarni qaytarib oldik.
Ammo bu erda muammo bor, master replikaga o'tganda, u slotlarni o'chiradi va WAL segmentlarini uyalar bilan birga o'chiradi. Va bu muammoni bartaraf qilish uchun biz wal_keep_segments parametrini oshirishga qaror qildik. U 8 ta segmentga o'rnatiladi. Biz uni 1 ga ko'tardik va bizda qancha bo'sh joy borligini ko'rib chiqdik. Va biz wal_keep_segments uchun 000 gigabayt sovg'a qildik. Ya'ni, almashtirishda bizda har doim barcha tugunlarda 16 gigabaytlik tranzaksiya jurnallari zaxirasi mavjud.
Va ortiqcha - bu hali ham uzoq muddatli texnik xizmat ko'rsatish vazifalari uchun dolzarbdir. Aytaylik, replikalardan birini yangilashimiz kerak. Va biz uni o'chirmoqchimiz. Biz dasturiy ta'minotni yangilashimiz kerak, ehtimol operatsion tizim, boshqa narsa. Va biz replikani o'chirib qo'yganimizda, ushbu replika uchun slot ham olib tashlanadi. Va agar biz kichik wal_keep_segments dan foydalansak, u holda uzoq vaqt davomida replika bo'lmasa, tranzaktsiyalar jurnallari yo'qoladi. Biz replika yaratamiz, u to'xtagan joyda tranzaksiya jurnallarini so'raydi, lekin ular masterda bo'lmasligi mumkin. Va replika ham ulana olmaydi. Shuning uchun biz jurnallarning katta zaxirasini saqlaymiz.
Bizning ishlab chiqarish bazamiz bor. Hozirda amalga oshirilayotgan loyihalar mavjud.
Filler bor edi. Biz kirdik va qaradik - hammasi joyida, nusxalar joyida, replikatsiyada kechikish yo'q. Jurnallarda ham xatolik yo'q, hammasi joyida.
Mahsulot jamoasi ba'zi ma'lumotlar bo'lishi kerakligini aytadi, lekin biz uni bir manbadan ko'ramiz, lekin biz uni ma'lumotlar bazasida ko'rmayapmiz. Va biz ularga nima bo'lganini tushunishimiz kerak.
pg_rewind ularni o'tkazib yuborganligi aniq. Biz buni darhol angladik, lekin nima bo'layotganini ko'rish uchun bordik.
Jurnallarda biz har doim faylni beruvchi qachon sodir bo'lganini, kim usta bo'lganini bilib olamiz va kim eski usta bo'lganini va qachon u replika bo'lishni xohlayotganini aniqlashimiz mumkin, ya'ni bizga tranzaksiya jurnallari miqdorini bilish uchun bu jurnallar kerak. yo'qolgan edi.
Bizning eski ustamiz qayta ishga tushdi. Va Patroni avtorunda ro'yxatdan o'tgan. Patroni ishga tushirildi. Keyin u Postgresni boshladi. Aniqrog'i, Postgresni ishga tushirishdan oldin va uni replikatsiya qilishdan oldin Patroni pg_rewind jarayonini ishga tushirdi. Shunga ko'ra, u tranzaksiya jurnallarining bir qismini o'chirib tashladi, yangilarini yuklab oldi va ulandi. Bu erda Patroni aqlli ishladi, ya'ni kutilganidek. Klaster tiklandi. Bizda 3 ta tugun bor edi, to'ldiruvchidan keyin 3 ta tugun - hamma narsa ajoyib.
Biz ba'zi ma'lumotlarni yo'qotdik. Va biz qancha yo'qotganimizni tushunishimiz kerak. Biz ortga qaytgan paytni qidirmoqdamiz. Biz buni bunday jurnal yozuvlarida topishimiz mumkin. Orqaga o'tkazish boshlandi, u erda nimadir qildi va tugadi.
Biz tranzaktsiyalar jurnalida eski usta to'xtagan joyni topishimiz kerak. Bunday holda, bu belgi. Va bizga ikkinchi belgi kerak, ya'ni eski usta yangidan farq qiladigan masofa.
Biz odatdagi pg_wal_lsn_diffni olamiz va bu ikki belgini solishtiramiz. Va bu holda, biz 17 megabayt olamiz. Ko'p yoki oz, har kim o'zi uchun qaror qiladi. Chunki kimdir uchun 17 megabayt ko'p emas, kimdir uchun bu juda ko'p va qabul qilinishi mumkin emas. Bu erda har bir shaxs biznes ehtiyojlariga muvofiq o'zi uchun belgilaydi.
Ammo biz o'zimiz uchun nimani bilib oldik?
Birinchidan, biz o'zimiz qaror qabul qilishimiz kerak - tizimni qayta ishga tushirgandan so'ng bizga har doim Patroni avtomatik ishga tushishi kerakmi? Ko'pincha biz eski ustaning oldiga borishimiz kerak, u qanchalik uzoqqa ketganini ko'rishimiz kerak. Ehtimol, tranzaktsiyalar jurnalining segmentlarini tekshiring, u erda nima borligini ko'ring. Va biz ushbu ma'lumotlarni yo'qotishimiz mumkinmi yoki bu ma'lumotlarni olib tashlash uchun eski masterni mustaqil rejimda ishga tushirishimiz kerakligini tushunish uchun.
Va shundan keyingina biz ushbu ma'lumotlarni o'chirib tashlashimiz mumkinmi yoki uni qayta tiklashimiz mumkinmi, bu tugunni klasterimizga replika sifatida ulashimiz kerak.
Bundan tashqari, "maximum_lag_on_failover" parametri mavjud. Odatiy bo'lib, agar xotiram menga xizmat qilsa, bu parametr 1 megabayt qiymatiga ega.
U qanday ishlaydi? Agar replikamiz replikatsiya kechikishida 1 megabayt ma'lumotlarga ortda qolsa, bu replika saylovlarda qatnashmaydi. Va agar to'satdan fayl paydo bo'lsa, Patroni qaysi replikalarning orqada qolayotganiga qaraydi. Agar ular ko'p sonli tranzaksiya jurnallaridan ortda qolsalar, ular usta bo'lolmaydilar. Bu juda ko'p ma'lumotlarni yo'qotishdan saqlaydigan juda yaxshi xavfsizlik xususiyati.
Ammo Patroni klasteridagi replikatsiya kechikishi va DCS ma'lum bir vaqt oralig'ida yangilanishi bilan bog'liq muammo bor. Menimcha, 30 soniya standart ttl qiymatidir.
Shunga ko'ra, DCS-da replikatsiyalar uchun bitta replikatsiya kechikishi mavjud bo'lgan vaziyat bo'lishi mumkin, lekin aslida butunlay boshqacha kechikish bo'lishi mumkin yoki umuman kechikish bo'lmasligi mumkin, ya'ni bu narsa real vaqtda emas. Va u har doim ham haqiqiy rasmni aks ettirmaydi. Va buning ustida chiroyli mantiq qilishning hojati yo'q.
Va yo'qotish xavfi doimo saqlanib qoladi. Va eng yomon holatda, bitta formula va o'rtacha holatda, boshqa formula. Ya'ni, biz Patronini amalga oshirishni rejalashtirganimizda va qancha ma'lumotlarni yo'qotishimiz mumkinligini baholaganimizda, biz ushbu formulalarga tayanishimiz va qancha ma'lumot yo'qotishimiz mumkinligini taxmin qilishimiz kerak.
Va yaxshi yangilik bor. Qadimgi usta oldinga o'tib ketganda, u ba'zi fon jarayonlari tufayli oldinga borishi mumkin. Ya'ni, qandaydir avtovakuum bor edi, u ma'lumotlarni yozdi, ularni tranzaktsiyalar jurnaliga saqladi. Va biz bu ma'lumotlarni osongina e'tiborsiz qoldirishimiz va yo'qotishimiz mumkin. Bunda hech qanday muammo yo'q.
Maksimal_lag_on_failover o'rnatilgan bo'lsa va fayl paydo bo'lgan bo'lsa, jurnallar shunday ko'rinadi va siz yangi masterni tanlashingiz kerak. Replika o'zini saylovda ishtirok eta olmaydi, deb baholaydi. Va u etakchilik poygasida qatnashishdan bosh tortadi. Va u yangi usta tanlanishini kutadi, shunda u unga ulanishi mumkin. Bu ma'lumotlar yo'qolishiga qarshi qo'shimcha chora.
Bu erda bizda mahsulot guruhi bor, ular o'z mahsuloti Postgres bilan bog'liq muammolarga duch kelmoqda. Shu bilan birga, masterning o'ziga kirish mumkin emas, chunki u SSH orqali mavjud emas. Va avtomatik fayl ham sodir bo'lmaydi.
Bu xostni qayta ishga tushirishga majbur boβldi. Qayta yuklash tufayli avtomatik fayl sodir bo'ldi, garchi men endi tushunganimdek, qo'lda avtomatik faylni bajarish mumkin edi. Va qayta ishga tushirgandan so'ng, biz hozirgi usta bilan nima qilganimizni ko'ramiz.
Shu bilan birga, biz disklar bilan bog'liq muammolar mavjudligini oldindan bilardik, ya'ni qaerda qazish va nimani izlash kerakligini kuzatishdan allaqachon bilar edik.
Biz postgres jurnaliga kirdik va u erda nima bo'layotganini ko'ra boshladik. Biz bir, ikki, uch soniya davom etadigan majburiyatlarni ko'rdik, bu umuman normal emas. Bizning avtovakuumimiz juda sekin va g'alati tarzda ishga tushishini ko'rdik. Va biz diskdagi vaqtinchalik fayllarni ko'rdik. Ya'ni, bularning barchasi disklar bilan bog'liq muammolarning ko'rsatkichlari.
Biz dmesg (yadro jurnali) tizimiga qaradik. Va biz disklardan birida muammolarimiz borligini ko'rdik. Diskning quyi tizimi dasturiy ta'minot Raid edi. Biz /proc/mdstat ga qaradik va bizda bitta disk etishmayotganligini ko'rdik. Ya'ni, 8 ta diskdan iborat Reyd bor, bizda bittasi etishmayapti. Agar siz slaydni diqqat bilan ko'rib chiqsangiz, chiqishda bizda u erda sde yo'qligini ko'rishingiz mumkin. Bizda, shartli ravishda, disk tushib ketdi. Bu diskdagi muammolarni keltirib chiqardi va ilovalar Postgres klasteri bilan ishlashda ham muammolarga duch keldi.
Va bu holatda, Patroni bizga hech qanday yordam bermaydi, chunki Patronining server holatini, disk holatini kuzatish vazifasi yo'q. Biz esa bunday vaziyatlarni tashqi monitoring orqali kuzatishimiz kerak. Biz tezda tashqi monitoringga disk monitoringini qo'shdik.
Va shunday fikr bor edi - qilichbozlik yoki qo'riqchi dasturlari bizga yordam bera oladimi? Biz bu holatda u bizga deyarli yordam bera olmaydi deb o'ylagandik, chunki muammolar paytida Patroni DCS klasteri bilan o'zaro aloqani davom ettirdi va hech qanday muammo ko'rmadi. Ya'ni, DCS va Patroni nuqtai nazaridan, klasterda hamma narsa yaxshi edi, garchi aslida diskda muammolar mavjud bo'lsa-da, ma'lumotlar bazasi mavjudligi bilan bog'liq muammolar mavjud edi.
Menimcha, bu men juda uzoq vaqt davomida tadqiq qilgan eng g'alati muammolardan biri, men ko'plab jurnallarni o'qib chiqdim, qayta tanladim va uni klaster simulyatori deb atadim.
Muammo shundaki, eski usta oddiy nusxaga aylana olmadi, ya'ni Patroni uni boshladi, Patroni bu tugun replika sifatida mavjudligini ko'rsatdi, lekin ayni paytda u oddiy replika emas edi. Endi nima uchun buni bilib olasiz. Men bu muammoni tahlil qilishdan saqlagan narsam.
Va hammasi qanday boshlandi? Avvalgi muammoda bo'lgani kabi, disk tormozlari bilan boshlandi. Bizda bir soniya, ikkita majburiyat bor edi.
Aloqalarda uzilishlar bor edi, ya'ni mijozlar yirtilgan.
Turli zo'ravonlikdagi blokirovkalar mavjud edi.
Va shunga ko'ra, disk quyi tizimi juda sezgir emas.
Va men uchun eng sirli narsa bu darhol o'chirish so'rovi. Postgres uchta o'chirish rejimiga ega:
- Barcha mijozlar o'z-o'zidan uzilishini kutganimizda juda yoqimli.
- Mijozlarni o'chirishga majburlaganimizda tez bo'ladi, chunki biz o'chirib qo'ymoqchimiz.
- Va darhol. Bunday holda, immediate mijozlarga hatto o'chirishni ham aytmaydi, faqat ogohlantirishsiz o'chadi. Va barcha mijozlarga operatsion tizim allaqachon RST xabarini yuboradi (ulanish uzilganligi va mijozda boshqa hech narsa qo'lga kiritilmaganligi haqida TCP xabari).
Bu signalni kim yubordi? Postgres fon jarayonlari bunday signallarni bir-biriga yubormaydi, ya'ni bu kill-9. Ular bir-biriga bunday narsalarni yubormaydilar, ular faqat bunday narsalarga munosabat bildiradilar, ya'ni bu Postgresning favqulodda qayta ishga tushirilishi. Kim yubordi, bilmayman.
Men "oxirgi" buyrug'iga qaradim va men ushbu serverga biz bilan kirgan bir odamni ko'rdim, lekin men savol berishga juda uyaldim. Balki o'ldirish -9 edi. Men loglarda kill -9 ni ko'raman, chunki Postgresning aytishicha, o'ldirish uchun -9 kerak edi, lekin men buni jurnallarda ko'rmadim.
Keyinchalik qarasam, Patronining jurnalga juda uzoq vaqt - 54 soniya yozmaganini ko'rdim. Va agar ikkita vaqt belgilarini solishtirsak, taxminan 54 soniya davomida hech qanday xabar yo'q edi.
Va bu vaqt ichida avtomatik fayl mavjud edi. Patroni bu yerda yana ajoyib ish qildi. Bizning eski xo'jayinimiz mavjud emas edi, unga nimadir bo'ldi. Va yangi ustani tanlash boshlandi. Bu erda hamma narsa yaxshi chiqdi. Bizning pgsql01 yangi yetakchiga aylandi.
Bizda ustaga aylangan nusxamiz bor. Va ikkinchi javob bor. Va ikkinchi nusxada muammolar bor edi. U qayta sozlashga harakat qildi. Men tushunganimdek, u recovery.conf-ni o'zgartirishga, Postgres-ni qayta ishga tushirishga va yangi masterga ulanishga harakat qildi. U har 10 soniyada u harakat qilayotgani haqida xabarlar yozadi, lekin u muvaffaqiyatga erishmaydi.
Va bu urinishlar paytida eski ustaga darhol o'chirish signali keladi. Master qayta ishga tushirildi. Va shuningdek, tiklash to'xtaydi, chunki eski usta qayta ishga tushadi. Ya'ni, replika unga ulana olmaydi, chunki u o'chirish rejimida.
Bir nuqtada u ishladi, lekin replikatsiya boshlanmadi.
Mening taxminimcha, recovery.conf da eski asosiy manzil bor edi. Va yangi usta paydo bo'lganda, ikkinchi nusxa hali ham eski ustaga ulanishga harakat qildi.
Patroni ikkinchi nusxada ishga tushirilganda, tugun ishga tushdi, lekin takrorlana olmadi. Va shunga o'xshash ko'rinishdagi replikatsiya lag hosil bo'ldi. Ya'ni, uchta tugun ham joyida edi, lekin ikkinchi tugun orqada qoldi.
Shu bilan birga, agar siz yozilgan jurnallarga qarasangiz, tranzaksiya jurnallari boshqacha bo'lganligi sababli replikatsiya boshlana olmasligini ko'rishingiz mumkin. Magistr taklif qiladigan, recovery.conf da ko'rsatilgan tranzaksiya jurnallari bizning joriy tugunimizga mos kelmaydi.
Va bu erda men xato qildim. Men kelib, biz noto'g'ri ustaga ulanayotganimiz haqidagi farazimni sinab ko'rish uchun recovery.conf da nima borligini ko'rishim kerak edi. Ammo keyin men bu bilan shug'ullanardim va bu xayolimga ham kelmadi, yoki men replika ortda qolayotganini va uni to'ldirish kerakligini ko'rdim, ya'ni men qandaydir tarzda beparvo ishladim. Bu mening qo'shig'im edi.
30 daqiqadan so'ng, administrator allaqachon keldi, ya'ni Patroniyni replikada qayta ishga tushirdim. Men bunga chek qo'ydim, uni qayta to'ldirish kerak deb o'yladim. Va men o'yladim - men Patronni qayta ishga tushiraman, ehtimol yaxshi narsa chiqadi. Qayta tiklash boshlandi. Va baza hatto ochildi, u ulanishlarni qabul qilishga tayyor edi.
Replikatsiya boshlandi. Ammo bir daqiqadan so'ng u tranzaksiya jurnallari unga mos kelmaydi degan xatoga yo'l qo'ydi.
Men yana qayta boshlayman deb o'yladim. Men Patroni-ni qayta ishga tushirdim va Postgres-ni qayta ishga tushirmadim, balki ma'lumotlar bazasini sehrli tarzda ishga tushiradi degan umidda Patroni-ni qayta ishga tushirdim.
Replikatsiya yana boshlandi, lekin tranzaktsiyalar jurnalidagi belgilar boshqacha edi, ular avvalgi boshlash urinishi bilan bir xil emas edi. Replikatsiya yana toΚ»xtatildi. Va xabar allaqachon biroz boshqacha edi. Va bu men uchun juda ma'lumotli emas edi.
Va keyin xayolimga keldi - agar Postgres-ni qayta ishga tushirsam nima bo'ladi, bu vaqtda men tranzaksiya jurnalidagi nuqtani biroz oldinga siljitish uchun joriy masterda nazorat nuqtasini qilaman, shunda tiklanish boshqa daqiqadan boshlanadi? Bundan tashqari, bizda hali ham WAL zaxiralari bor edi.
Men Patroni-ni qayta ishga tushirdim, masterda bir nechta nazorat punktlarini, ochilganda nusxada bir nechta qayta boshlash nuqtalarini qildim. Va yordam berdi. Men uzoq vaqt davomida nima uchun yordam berganini va qanday ishlashini o'yladim. Va replikatsiya boshlandi. Va replikatsiya endi yirtilmadi.
Men uchun bunday muammo eng sirli muammolardan biri bo'lib, u erda nima sodir bo'lganligi haqida hanuzgacha bosh qotiraman.
Bu erda qanday ta'sirlar bor? Patroni maqsadga muvofiq va hech qanday xatosiz ishlashi mumkin. Ammo, shu bilan birga, bu bizda hamma narsa yaxshi ekanligiga 100% kafolat emas. Replika ishga tushishi mumkin, lekin u yarim ishchi holatda bo'lishi mumkin va dastur bunday replika bilan ishlay olmaydi, chunki eski ma'lumotlar bo'ladi.
Va fillerdan so'ng, siz har doim klaster bilan hamma narsa tartibda ekanligini tekshirishingiz kerak, ya'ni kerakli miqdordagi replikalar mavjud, replikatsiya kechikishi yo'q.
Va bu masalalarni ko'rib chiqsak, men tavsiyalar beraman. Men ularni ikkita slaydga birlashtirishga harakat qildim. Ehtimol, barcha hikoyalarni ikkita slaydga birlashtirib, faqat aytib berish mumkin.
Patroni-dan foydalanganda sizda monitoring bo'lishi kerak. Avtomatik fayl qachon sodir bo'lganligini har doim bilishingiz kerak, chunki agar sizda avtomatik fayl borligini bilmasangiz, klasterni nazorat qila olmaysiz. Va bu yomon.
Har bir fayldan so'ng biz har doim klasterni qo'lda tekshirishimiz kerak. Biz doimo yangilangan nusxalar soniga ega ekanligimizga ishonch hosil qilishimiz kerak, replikatsiya kechikishi yo'q, Patroni bilan, DCS tizimi bilan oqimli replikatsiya bilan bog'liq jurnallarda xatoliklar yo'q.
Avtomatlashtirish muvaffaqiyatli ishlashi mumkin, Patroni juda yaxshi vositadir. U ishlashi mumkin, ammo bu klasterni kerakli holatga keltirmaydi. Agar bu haqda bilib olmasak, boshimiz muammoga duch keladi.
Va Patroni kumush o'q emas. Biz hali ham Postgres qanday ishlashini, replikatsiya qanday ishlashini va Patronining Postgres bilan qanday ishlashini va tugunlar o'rtasidagi aloqa qanday ta'minlanishini tushunishimiz kerak. Bu sizning qo'llaringiz bilan muammolarni hal qilish uchun kerak.
Diagnostika masalasiga qanday yondashishim mumkin? Shunday bo'ldiki, biz turli xil mijozlar bilan ishlaymiz va hech kimda ELK to'plami yo'q va biz 6 ta konsol va 2 ta yorliqni ochib, jurnallarni saralashimiz kerak. Bir yorliqda bu har bir tugun uchun Patron jurnallari, boshqa yorliqda bular Konsul jurnallari yoki kerak bo'lsa Postgres. Buni tashxislash juda qiyin.
Men qanday yondashuvlarni ishlab chiqdim? Birinchidan, men har doim fayl qachon kelganiga qarayman. Va men uchun bu suv havzasi. Men to'ldiruvchidan oldin, to'ldiruvchi paytida va fayldan keyin nima sodir bo'lganiga qarayman. Fileover ikkita belgiga ega: bu boshlanish va tugash vaqti.
Keyinchalik, men to'ldiruvchidan oldin sodir bo'lgan voqealar uchun jurnallarni ko'rib chiqaman, ya'ni fayl nima uchun sodir bo'lganligini qidiraman.
Va bu nima sodir bo'lganligini va kelajakda bunday holatlar yuzaga kelmasligi uchun nima qilish mumkinligini tushunish rasmini beradi (va natijada hech qanday fayl yo'q).
Va biz odatda qayerga qaraymiz? Men tomosha qilyapman:
- Birinchidan, Patroni jurnallariga.
- Keyinchalik, Patroni jurnallarida topilgan narsalarga qarab, Postgres jurnallariga yoki DCS jurnallariga qarayman.
- Tizim jurnallari ham ba'zan faylga nima sabab bo'lganligi haqida tushuncha beradi.
Patroni haqida qanday fikrdaman? Men Patroni bilan juda yaxshi munosabatdaman. Menimcha, bu bugungi kunda eng yaxshisidir. Men boshqa ko'plab mahsulotlarni bilaman. Bular Stolon, Repmgr, Pg_auto_failover, PAF. 4 ta asbob. Men ularning barchasini sinab ko'rdim. Patroni mening sevimli.
Agar ular mendan so'rasalar: "Men Patronni tavsiya qilamanmi?". Men ha deb aytaman, chunki menga Patroni yoqadi. Va men uni qanday pishirishni o'rgandim deb o'ylayman.
Agar siz Patronida men aytib o'tgan muammolardan tashqari yana qanday muammolar borligini bilishni istasangiz, har doim sahifani ko'rishingiz mumkin. GitHub-da. U erda juda ko'p turli xil hikoyalar mavjud va ko'plab qiziqarli masalalar muhokama qilinadi. Va natijada ba'zi xatolar kiritildi va hal qilindi, ya'ni bu qiziqarli o'qish.
Odamlarning oyog'iga o'q uzishi haqida qiziqarli hikoyalar mavjud. Juda ma'lumotli. Siz o'qiysiz va buni qilish shart emasligini tushunasiz. Men o'zimni belgiladim.
Va bu loyihani ishlab chiqqani uchun Zalandoga, xususan Aleksandr Kukushkin va Aleksey Klyukinga katta rahmat aytmoqchiman. Aleksey Klyukin hammualliflardan biri, u endi Zalandoda ishlamaydi, ammo bular ushbu mahsulot bilan ishlashni boshlagan ikki kishi.
Va menimcha, Patroni juda ajoyib narsa. Men uning mavjudligidan xursandman, u bilan qiziq. Patroniga yamoqlar yozgan barcha ishtirokchilarga katta rahmat. Umid qilamanki, Patroni yoshi bilan yanada etuk, salqin va samaraliroq bo'ladi. U allaqachon ishlaydi, lekin umid qilamanki, u yanada yaxshilanadi. Shuning uchun, agar siz Patronidan foydalanishni rejalashtirmoqchi bo'lsangiz, qo'rqmang. Bu yaxshi yechim, uni amalga oshirish va ishlatish mumkin.
Ana xolos. Savollaringiz bo'lsa, so'rang.
Sizning savollaringiz
Hisobot uchun rahmat! Agar fillerdan keyin siz hali ham u erga juda ehtiyotkorlik bilan qarashingiz kerak bo'lsa, unda nima uchun bizga avtomatik to'ldiruvchi kerak?
Chunki bu yangi narsa. Biz u bilan atigi bir yil yashadik. Xavfsiz bo'lish yaxshiroqdir. Biz kirib, hamma narsa haqiqatan ham kerakli tarzda ishlaganini ko'rmoqchimiz. Bu kattalar ishonchsizlik darajasi - yana bir bor tekshirib ko'rish va ko'rish yaxshiroqdir.
Masalan, ertalab borib qaradik, to'g'rimi?
Ertalab emas, biz odatda avtomatik fayl haqida deyarli darhol bilib olamiz. Biz bildirishnomalarni olamiz, biz avtomatik fayl paydo bo'lganligini ko'ramiz. Biz deyarli darhol boramiz va qaraymiz. Ammo bu tekshiruvlarning barchasi monitoring darajasiga etkazilishi kerak. Agar siz Patroniga REST API orqali kirsangiz, tarix mavjud. Tarix bo'yicha siz faylning sodir bo'lgan vaqt belgilarini ko'rishingiz mumkin. Shunga asoslanib, monitoring o'tkazilishi mumkin. Tarixni, qancha voqealar bo'lganini ko'rishingiz mumkin. Agar bizda ko'proq voqealar bo'lsa, unda avtomatik fayl paydo bo'ldi. Siz borib ko'rishingiz mumkin. Yoki bizning monitoringimiz avtomatizatsiyasi bizda barcha nusxalar mavjudligini tekshirdi, hech qanday kechikish yo'q va hamma narsa yaxshi.
Rahmat!
Ajoyib hikoya uchun katta rahmat! Agar biz DCS klasterini Postgres klasteridan uzoqroq joyga ko'chirsak, bu klasterga ham vaqti-vaqti bilan xizmat ko'rsatish kerakmi? DCS klasterining ba'zi qismlari o'chirilishi kerak bo'lgan eng yaxshi amaliyotlar, ular bilan nima qilish kerak va hokazo? Bu butun tuzilma qanday omon qoladi? Va bu ishlarni qanday qilasiz?
Bitta kompaniya uchun muammolar matritsasini tuzish kerak edi, agar komponentlardan biri yoki bir nechta komponentlar ishlamay qolsa nima bo'ladi. Ushbu matritsaga ko'ra, biz ketma-ket barcha komponentlarni ko'rib chiqamiz va ushbu komponentlar ishlamay qolgan taqdirda stsenariylarni tuzamiz. Shunga ko'ra, har bir muvaffaqiyatsizlik stsenariysi uchun siz tiklash uchun harakat rejasiga ega bo'lishingiz mumkin. Va DCS holatida u standart infratuzilmaning bir qismi sifatida keladi. Va administrator uni boshqaradi va biz allaqachon uni boshqaradigan administratorlarga va baxtsiz hodisalar yuz berganda uni tuzatish qobiliyatiga ishonamiz. Agar umuman DCS bo'lmasa, biz uni joylashtiramiz, lekin shu bilan birga biz uni ayniqsa kuzatmaymiz, chunki biz infratuzilma uchun javobgar emasmiz, lekin biz qanday va nimani kuzatish bo'yicha tavsiyalar beramiz.
Ya'ni, xostlar bilan biror narsa qilishdan oldin Patroni o'chirish, faylni o'chirish, hamma narsani o'chirish kerakligini to'g'ri tushundimmi?
Bu DCS klasterida qancha tugunlar mavjudligiga bog'liq. Agar tugunlar ko'p bo'lsa va biz tugunlardan faqat bittasini (replika) o'chirib qo'ysak, klaster kvorumni saqlaydi. Patroni esa o'z faoliyatini davom ettiradi. Va hech narsa tetiklanmaydi. Agar bizda ko'proq tugunlarga ta'sir qiladigan murakkab operatsiyalar bo'lsa, ularning yo'qligi kvorumni buzishi mumkin bo'lsa, unda - ha, Patronni pauza qilish mantiqiy bo'lishi mumkin. Unda tegishli buyruq bor - patronictl pause, patronictl resume. Biz shunchaki pauza qilamiz va avtofiler o'sha paytda ishlamaydi. Biz DCS klasterida texnik xizmat ko'rsatamiz, keyin pauzani olib tashlab, yashashni davom ettiramiz.
Katta rahmat!
Hisobotingiz uchun katta rahmat! Mahsulot jamoasi ma'lumotlarning yo'qolishiga qanday munosabatda?
Mahsulot guruhlari g'amxo'rlik qilmaydi va jamoa rahbarlari xavotirda.
Qanday kafolatlar bor?
Kafolatlar juda qiyin. Aleksandr Kukushkinning "RPO va RTOni qanday hisoblash mumkin" hisoboti bor, ya'ni tiklash vaqti va qancha ma'lumotni yo'qotishimiz mumkin. Menimcha, biz bu slaydlarni topib, o'rganishimiz kerak. Esimda, bu narsalarni hisoblash bo'yicha aniq qadamlar mavjud. Biz qancha tranzaktsiyalarni yo'qotishimiz mumkin, qancha ma'lumotlarni yo'qotishimiz mumkin. Variant sifatida biz Patroni darajasida sinxron replikatsiyadan foydalanishimiz mumkin, ammo bu ikki qirrali qilich: bizda yoki ma'lumotlar ishonchliligi bor, yoki biz tezlikni yo'qotamiz. Sinxron replikatsiya mavjud, lekin u ham ma'lumotlarni yo'qotishdan 100% himoyani kafolatlamaydi.
Aleksey, ajoyib hisobot uchun rahmat! Nol darajadagi himoya uchun Patronidan foydalanish tajribasi bormi? Ya'ni, sinxron kutish bilan birga? Bu birinchi savol. Va ikkinchi savol. Siz turli xil echimlardan foydalangansiz. Biz Repmgr-dan foydalandik, lekin avtofilersiz va endi biz avtomatik faylni kiritishni rejalashtirmoqdamiz. Va biz Patroniyni muqobil yechim deb hisoblaymiz. Repmgr bilan solishtirganda qanday afzalliklarni ayta olasiz?
Birinchi savol sinxron replikalar haqida edi. Bu erda hech kim sinxron replikatsiyadan foydalanmaydi, chunki hamma qo'rqadi (bir nechta mijozlar undan allaqachon foydalanmoqda, printsipial jihatdan ular ishlash muammolarini sezmadilar - Spikerning eslatmasi). Ammo biz o'zimiz uchun sinxron replikatsiya klasterida kamida uchta tugun bo'lishi kerakligi haqida qoida ishlab chiqdik, chunki agar bizda ikkita tugun bo'lsa va agar master yoki replika muvaffaqiyatsiz bo'lsa, Patroni ushbu tugunni mustaqil rejimga o'tkazadi, shunda dastur davom etadi. ish. Bunday holda, ma'lumotlarni yo'qotish xavfi mavjud.
Ikkinchi savolga kelsak, biz Repmgr-dan foydalandik va tarixiy sabablarga ko'ra ba'zi mijozlar bilan ishlaymiz. Nima deyish mumkin? Patroni qutidan tashqarida avtofiler bilan birga keladi, Repmgr yoqilgan bo'lishi kerak bo'lgan qo'shimcha xususiyat sifatida autofiler bilan birga keladi. Biz har bir tugunda Repmgr demonini ishga tushirishimiz kerak va keyin avtofilerni sozlashimiz mumkin.
Repmgr Postgres tugunlari tirik yoki yo'qligini tekshiradi. Repmgr jarayonlari bir-birining mavjudligini tekshiradi, bu juda samarali yondashuv emas. tarmoq izolyatsiyasining murakkab holatlari bo'lishi mumkin, bunda katta Repmgr klasteri bir nechta kichikroqlarga bo'linib, ishlashni davom ettirishi mumkin. Men Repmgr-ni uzoq vaqtdan beri kuzatmadim, ehtimol u tuzatilgan ... yoki yo'q. Ammo Stolon, Patroni qilganidek, DCSdagi klaster holati haqidagi ma'lumotlarni olib tashlash eng maqbul variantdir.
Aleksey, menda bir savol bor, ehtimol, noaniq. Birinchi misollardan birida siz DCS-ni mahalliy kompyuterdan uzoqdagi xostga o'tkazdingiz. Biz tushunamizki, tarmoq o'ziga xos xususiyatlarga ega bo'lgan narsadir, u o'z-o'zidan yashaydi. Va agar biron sababga ko'ra DCS klasteri mavjud bo'lmasa nima bo'ladi? Sabablarini aytmayman, ularning ko'pi bo'lishi mumkin: tarmoqchilarning qiyshiq qo'llaridan tortib, haqiqiy muammolargacha.
Men buni baland ovozda aytmadim, lekin kvorumga erishish uchun DCS klasteri ham muvaffaqiyatsiz bo'lishi kerak, ya'ni tugunlarning toq soni. Agar DCS klasteri mavjud bo'lmasa yoki kvorum bajarilmasa, ya'ni tarmoqning qandaydir bo'linishi yoki tugunning ishdan chiqishi bo'lsa nima bo'ladi? Bunday holda, Patroni klasteri faqat o'qish rejimiga o'tadi. Patroni klasteri klaster holatini va nima qilish kerakligini aniqlay olmaydi. U DCS bilan bog'lana olmaydi va u erda yangi klaster holatini saqlay olmaydi, shuning uchun butun klaster faqat o'qish rejimiga o'tadi. Va operatorning qo'lda aralashuvini yoki DCS tiklanishini kutadi.
Taxminan aytganda, DCS biz uchun bazaning o'zi kabi muhim xizmatga aylanadi?
Ha ha. Ko'pgina zamonaviy kompaniyalarda Service Discovery infratuzilmaning ajralmas qismi hisoblanadi. U hatto infratuzilmada ma'lumotlar bazasi mavjud bo'lmasdan oldin ham amalga oshirilmoqda. Nisbatan aytganda, infratuzilma ishga tushirildi, DCda joylashtirildi va bizda darhol Service Discovery mavjud. Agar konsul bo'lsa, unda DNS-ni qurish mumkin. Agar bu Etcd bo'lsa, Kubernetes klasterining bir qismi bo'lishi mumkin, unda hamma narsa joylashtiriladi. Menimcha, Service Discovery allaqachon zamonaviy infratuzilmalarning ajralmas qismidir. Va ular bu haqda ma'lumotlar bazalariga qaraganda ancha oldin o'ylashadi.
Rahmat!
Manba: www.habr.com