Citymobil-da biz MySQL ma'lumotlar bazasidan asosiy doimiy ma'lumotlarni saqlashimiz sifatida foydalanamiz. Bizda turli xizmatlar va maqsadlar uchun bir nechta ma'lumotlar bazasi klasterlari mavjud.

Magistrning doimiy mavjudligi butun tizim va uning alohida qismlari ishlashining muhim ko'rsatkichidir. Asosiy ishlamay qolganda avtomatik klasterni tiklash hodisaga javob berish vaqtini va tizimning ishlamay qolish vaqtini sezilarli darajada kamaytiradi. Ushbu maqolada men MySQL klasteri uchun yuqori mavjudlik (HA) dizaynini ko'rib chiqaman. MySQL orchestrator va virtual IP manzillar (VIP).

VIP asosidagi HA yechimi

Birinchidan, men sizga ma'lumotlarni saqlash tizimi nima ekanligini qisqacha aytib beraman.

Biz klassik replikatsiya sxemasidan bitta yozish mumkin bo'lgan master va bir nechta faqat o'qish uchun replikalardan foydalanamiz. Klaster oraliq masterni o'z ichiga olishi mumkin - bu ham replika, ham boshqalar uchun master bo'lgan tugun. Mijozlar replikalarga HAProxy orqali kirishadi, bu esa yukni teng taqsimlash va oson masshtablash imkonini beradi. HAProxy-dan foydalanish tarixiy sabablarga ko'ra yuzaga kelgan va biz hozirda ProxySQL-ga o'tish jarayonidamiz.

Replikatsiya asosida yarim sinxron rejimda amalga oshiriladi GTID. Bu shuni anglatadiki, kamida bitta replika tranzaksiya muvaffaqiyatli deb hisoblanishidan oldin uni qayd etishi kerak. Ushbu replikatsiya rejimi asosiy tugun ishdan chiqqan taqdirda ishlash va ma'lumotlar xavfsizligi o'rtasidagi optimal muvozanatni ta'minlaydi. Asosan barcha o'zgarishlar masterdan replikalarga o'tkaziladi Row Based Replication (RBR), lekin ba'zi tugunlarda bo'lishi mumkin mixed binlog format.

Orkestr vaqti-vaqti bilan klaster topologiyasining holatini yangilaydi, olingan ma'lumotlarni tahlil qiladi va agar muammolar yuzaga kelsa, u avtomatik tiklash jarayonini boshlashi mumkin. Ishlab chiquvchi protseduraning o'zi uchun javobgardir, chunki u turli yo'llar bilan amalga oshirilishi mumkin: VIP, DNS asosida, xizmatlarni aniqlash xizmatlaridan yoki o'z-o'zidan yozilgan mexanizmlardan foydalanish.

Agar u muvaffaqiyatsiz bo'lsa, masterni tiklashning oddiy usullaridan biri suzuvchi VIP manzillardan foydalanishdir.

Oldinga borishdan oldin ushbu yechim haqida nimalarni bilishingiz kerak:

• VIP - bu ma'lum bir jismoniy tarmoq interfeysi bilan bog'liq bo'lmagan IP-manzil. Agar tugun ishlamay qolsa yoki rejalashtirilgan texnik xizmat ko'rsatish vaqtida biz VIP-ni boshqa resursga minimal uzilish bilan o'tkazishimiz mumkin.
• Virtual IP-manzilni bo'shatish va berish arzon va tezkor operatsiya hisoblanadi.
• VIP bilan ishlash uchun SSH orqali serverga kirishingiz yoki maxsus yordamchi dasturlardan foydalanishingiz kerak, masalan, keepalived.

Keling, sehrgarimiz bilan yuzaga kelishi mumkin bo'lgan muammolarni ko'rib chiqaylik va avtomatik tiklash mexanizmi qanday ishlashini tasavvur qilaylik.

Magistrga tarmoq ulanishi yo'qoldi yoki apparat darajasida muammo yuzaga keldi va server mavjud emas.

1. Orkestrator klaster topologiyasini yangilaydi, har bir replika master mavjud emasligi haqida xabar beradi. Orkestr yangi usta roliga mos nusxani tanlash jarayonini boshlaydi va tiklanishni boshlaydi.
2. Biz eski ustadan VIPni olib tashlashga harakat qilmoqdamiz - muvaffaqiyatsiz.
3. Replika usta roliga o'tadi. Topologiya qayta tiklanmoqda.
4. VIP bilan yangi tarmoq interfeysini qo'shish. VIP-ni olib tashlashning iloji bo'lmagani uchun biz vaqti-vaqti bilan fonda so'rov yuborishni boshlaymiz bepul ARP. Ushbu turdagi so'rov/javob sizga ulangan kalitlarda IP va MAC manzillarini xaritalash jadvalini yangilash imkonini beradi va shu bilan VIP ko'chirilganligi haqida sizni xabardor qiladi. Bu ehtimolini kamaytiradi split brain eski xo'jayinni qaytarishda.
5. Barcha yangi ulanishlar darhol yangi masterga yo'naltiriladi. Eski ulanishlar muvaffaqiyatsiz tugadi va ma'lumotlar bazasiga takroriy qo'ng'iroqlar dastur darajasida amalga oshiriladi.

Server normal rejimda ishlamoqda, DBMS darajasida xatolik yuz berdi

Algoritm avvalgi holatga o'xshaydi: topologiyani yangilash va tiklash jarayonini boshlash. Server mavjud bo'lganligi sababli, biz eski masterda VIP-ni muvaffaqiyatli chiqaramiz, uni yangisiga o'tkazamiz va bir nechta ARP so'rovlarini yuboramiz. Eski ustaning mumkin bo'lgan qaytishi qayta qurilgan klasterga va dasturning ishlashiga ta'sir qilmasligi kerak.

Boshqa muammolar

Replikalar yoki oraliq ustalarning ishlamay qolishi olib kelmaydi avtomatik harakatlarga va qo'lda aralashuvni talab qiladi.

Virtual tarmoq interfeysi har doim vaqtinchalik qo'shiladi, ya'ni server qayta ishga tushirilgandan so'ng, VIP avtomatik ravishda tayinlanmaydi. Har bir ma'lumotlar bazasi namunasi sukut bo'yicha faqat o'qish rejimida boshlanadi, orkestrator avtomatik ravishda yangi masterni yozishga o'tkazadi va o'rnatishga harakat qiladi. read only eski usta ustida. Ushbu harakatlar ehtimolini kamaytirishga qaratilgan split brain.

Qayta tiklash jarayonida muammolar paydo bo'lishi mumkin, bu standart monitoring vositalariga qo'shimcha ravishda orkestr UI orqali ham xabardor qilinishi kerak. Ushbu xususiyatni qo'shish orqali REST API-ni kengaytirdik (PR hozir ko'rib chiqilmoqda).

HA eritmasining umumiy diagrammasi quyida keltirilgan.

Yangi usta tanlash

Orkestr yetarlicha aqlli va tanlashga harakat qiladi eng mos nusxa quyidagi mezonlarga muvofiq yangi usta sifatida:

• replika ustadan orqada qoladi;
• Master va replikaning MySQL versiyasi;
• replikatsiya turi (RBR, SBR yoki aralash);
• bir xil yoki turli ma'lumotlar markazlarida joylashganligi;
• mavjudligi errant GTID — replikatsiyada bajarilgan va masterda bo'lmagan operatsiyalar;
• maxsus tanlash qoidalari ham hisobga olinadi.

Har bir belgi usta uchun ideal nomzod emas. Misol uchun, replika ma'lumotlarni zaxiralash uchun ishlatilishi mumkin yoki server zaifroq apparat konfiguratsiyasiga ega. Orkestrchi qo'llab-quvvatlash qo'lda qoidalar bo'lib, ular yordamida siz o'zingizning nomzodlarni tanlash afzalliklarini eng ko'p afzal qilinganidan e'tiborga olinmagangacha sozlashingiz mumkin.

Javob va tiklanish vaqti

Voqea sodir bo'lgan taqdirda, tizimning ishlamay qolish vaqtini minimallashtirish juda muhim, shuning uchun orkestr tomonidan klaster topologiyasini yaratish va yangilashga ta'sir qiluvchi MySQL parametrlarini ko'rib chiqaylik:

• slave_net_timeout — ulanish uzilgan va qayta ulangan deb tan olingunga qadar replika ustadan yangi maʼlumotlar yoki yurak urishi signali kelishini kutadigan soniyalar soni. Qiymat qanchalik past bo'lsa, replika usta bilan aloqa buzilganligini tezroq aniqlashi mumkin. Biz bu qiymatni 5 soniyaga o'rnatdik.
• MASTER_CONNECT_RETRY — qayta ulanishga urinishlar orasidagi soniyalar soni. Tarmoq bilan bog'liq muammolar yuzaga kelgan taqdirda, ushbu parametrning past qiymati tezda qayta ulanishga imkon beradi va klasterni tiklash jarayonini boshlashni oldini oladi. Tavsiya etilgan qiymat 1 soniya.
• MASTER_RETRY_COUNT — qayta ulanishga urinishlarning maksimal soni.
• MASTER_HEARTBEAT_PERIOD — soniyalar oralig'i, shundan so'ng usta yurak urishi signalini yuboradi. Standart qiymatning yarmiga teng slave_net_timeout.

Orkestr variantlari:

• DelayMasterPromotionIfSQLThreadNotUpToDate - teng bo'lsa true, keyin replikaning SQL oqimi Relay jurnalidan barcha qo'llanilmagan tranzaksiyalarni tugatmaguncha, asosiy rol nomzod replikada qo'llanilmaydi. Biz ushbu parametrdan barcha nomzod nusxalari ortda qolganda tranzaktsiyalarni yo'qotmaslik uchun foydalanamiz.
• InstancePollSeconds — topologiyani qurish va yangilash chastotasi.
• RecoveryPollSeconds — topologiyani tahlil qilish chastotasi. Agar muammo aniqlansa, topologiyani tiklash boshlanadi. Bu doimiy, 1 soniyaga teng.

Har bir klaster tuguni orkestr tomonidan bir marta so'ralgan InstancePollSeconds soniya Muammo aniqlanganda, klaster holati majburlanadi yangilangan, va keyin tiklanishni amalga oshirish uchun yakuniy qaror qabul qilinadi. Turli ma'lumotlar bazasi va orkestr parametrlari bilan tajriba o'tkazish orqali biz javob berish va tiklash vaqtini 30 soniyagacha qisqartira oldik.

Sinov stend

Biz mahalliy ishlab chiqish bilan HA sxemasini sinab ko'rishni boshladik sinov dastgohi sinov va ishlab chiqarish muhitida keyingi joriy etish. Mahalliy stend Docker asosida to‘liq avtomatlashtirilgan bo‘lib, orkestr va tarmoq konfiguratsiyasi bilan tajriba o‘tkazish, klasterni 2-3 serverdan bir necha o‘nlab serverlarga o‘tkazish va xavfsiz muhitda mashqlarni bajarish imkonini beradi.

Mashqlar davomida biz muammoli emulyatsiya usullaridan birini tanlaymiz: usta yordamida darhol otib tashlang kill -9, jarayonni yumshoq tarzda tugating va serverni to'xtating (docker-compose stop), tarmoq muammolarini simulyatsiya qilish iptables -j REJECT yoki iptables -j DROP. Biz quyidagi natijalarni kutamiz:

• orkestr usta bilan bog'liq muammolarni aniqlaydi va topologiyani 10 soniyadan ko'p bo'lmagan vaqt ichida yangilaydi;
• tiklash jarayoni avtomatik ravishda boshlanadi: tarmoq konfiguratsiyasi o'zgaradi, masterning roli replikaga o'tadi, topologiya qayta tiklanadi;
• yangi usta yoziladigan bo'ladi, qayta tiklash jarayonida jonli nusxalar yo'qolmaydi;
• ma'lumotlar yangi masterga yozila boshlaydi va takrorlanadi;
• Umumiy tiklanish vaqti 30 soniyadan oshmaydi.

Ma'lumki, tizim sinov va ishlab chiqarish muhitida turli xil apparat va tarmoq konfiguratsiyasi, sintetik va haqiqiy yuklanishdagi farqlar va boshqalar tufayli boshqacha harakat qilishi mumkin. Shu sababli, biz vaqti-vaqti bilan real sharoitlarda mashqlar o'tkazamiz, tarmoq ulanishi yo'qolganda yoki uning alohida qismlari buzilganda tizim qanday harakat qilishini tekshiramiz. Kelajakda biz ikkala muhit uchun mutlaqo bir xil infratuzilmani qurmoqchimiz va uni sinovdan o'tkazishni avtomatlashtirmoqchimiz.

topilmalar

Asosiy saqlash tizimi tugunining sog'lig'i SRE va operatsion guruhning asosiy vazifalaridan biridir. VIP asosidagi orkestr va HA yechimini amalga oshirish bizga quyidagi natijalarga erishishga imkon berdi:

• ma'lumotlar bazasi klasteri topologiyasi bilan bog'liq muammolarni ishonchli aniqlash;
• usta bilan bog'liq hodisalarga avtomatik va tezkor javob berish, tizimning ishlamay qolish vaqtini qisqartirish.

Biroq, yechim o'zining cheklovlari va kamchiliklariga ega:

• HA sxemasini bir nechta ma'lumotlar markazlariga o'tkazish uchun ular orasida bitta L2 tarmog'i kerak bo'ladi;
• Yangi masterga VIP belgilashdan oldin uni eskisiga chiqarishimiz kerak. Jarayon ketma-ket, bu esa tiklanish vaqtini oshiradi;
• VIP-ni chiqarish uchun serverga SSH kirish yoki masofaviy protseduralarni chaqirishning boshqa har qanday usuli talab qilinadi. Server yoki ma'lumotlar bazasi tiklash jarayoniga sabab bo'lgan muammolarga duch kelganligi sababli, VIPni olib tashlash muvaffaqiyatli yakunlanishiga ishonchimiz komil emas. Va bu bir xil virtual IP-manzilga ega ikkita serverning paydo bo'lishiga va muammoga olib kelishi mumkin split brain.

Qochish uchun split brain, usuldan foydalanishingiz mumkin STONIT (“Boshdagi boshqa tugunni otib tashlang”), bu muammoli tugunni butunlay izolyatsiya qiladi yoki o'chiradi. Klasterning yuqori mavjudligini amalga oshirishning boshqa usullari mavjud: VIP va DNS kombinatsiyasi, xizmatlarni aniqlash va proksi-serverlar, sinxron replikatsiya va o'zlarining kamchiliklari va afzalliklariga ega bo'lgan boshqa usullar.

Men MySQL klasterini yaratishga yondashuvimiz haqida gapirdim. Amalga oshirish oson va hozirgi sharoitda maqbul darajadagi ishonchlilikni ta'minlaydi. Umuman butun tizim va xususan infratuzilma rivojlanib borar ekan, bu yondashuv, shubhasiz, rivojlanadi.

Manba: www.habr.com