MySQL uchun orkestrator: nima uchun busiz xatoga chidamli loyihani qura olmaysiz

Har qanday yirik loyiha bir nechta serverlar bilan boshlangan. Avvaliga bitta ma'lumotlar bazasi serveri mavjud edi, keyin o'qishni kengaytirish uchun unga qullar qo'shildi. Va keyin - to'xtang! Bir xo'jayin bor, lekin qullar ko'p; agar qullardan biri ketsa, hammasi yaxshi bo'ladi, lekin agar xo'jayin ketsa, yomon bo'ladi: ishlamay qolish vaqti, adminlar serverni ko'tarishga harakat qilmoqda. Nima qilish kerak? Magistrni bron qiling. Mening hamkasbim Pavel bu haqda allaqachon yozgan maqola, Men buni takrorlamayman. Buning o'rniga, men sizga MySQL uchun Orchestrator nima uchun kerakligini aytaman!

Asosiy savoldan boshlaylik: "Usta ketganda kodni yangi mashinaga qanday o'tkazamiz?"

  • Menga VIP (Virtual IP) bilan sxema eng yoqadi, biz bu haqda quyida gaplashamiz. Bu eng oddiy va eng ravshan, garchi u aniq cheklovga ega bo'lsa-da: biz zaxira qiladigan usta yangi mashina bilan L2 segmentida bo'lishi kerak, ya'ni biz ikkinchi DC haqida unutishimiz mumkin. Va do'stona tarzda, agar siz katta L2 yovuzlik qoidasiga amal qilsangiz, chunki L2 faqat bitta rafga, L3 esa raflar orasida va bunday sxema yanada ko'proq cheklovlarga ega.
  • Siz kodga DNS nomini yozishingiz va uni /etc/hosts orqali hal qilishingiz mumkin. Aslida, hech qanday qaror bo'lmaydi. Sxemaning afzalligi: birinchi usulning hech qanday cheklov xarakteristikasi yo'q, ya'ni o'zaro to'qnashuvni tashkil qilish mumkin. Ammo keyin aniq savol tug'iladi: o'zgartirishni Puppet-Ansible orqali /etc/hosts ga qanchalik tez yetkazib bera olamiz?
  • Siz ikkinchi usulni biroz o'zgartirishingiz mumkin: barcha veb-serverlarga keshlash DNS-ni o'rnating, bu orqali kod asosiy ma'lumotlar bazasiga o'tadi. DNS-da ushbu yozuv uchun TTL 60 ni o'rnatishingiz mumkin. Ko'rinishidan, agar to'g'ri amalga oshirilsa, usul yaxshi.
  • Konsul va boshqalardan foydalanishni nazarda tutuvchi xizmat kashfiyoti bilan sxema.
  • bilan qiziqarli variant ProxySQL. ProxySQL orqali barcha trafikni MySQL-ga yo'naltirishingiz kerak; ProxySQL-ning o'zi kim master ekanligini aniqlashi mumkin. Aytgancha, siz ushbu mahsulotni ishlatish variantlaridan biri haqida mening maqolamda o'qishingiz mumkin maqola.

Githubda ishlagan Orchestrator muallifi dastlab VIP bilan birinchi sxemani amalga oshirdi, keyin uni konsul bilan sxemaga aylantirdi.

Oddiy infratuzilma sxemasi:

MySQL uchun orkestrator: nima uchun busiz xatoga chidamli loyihani qura olmaysiz
Men darhol e'tiborga olinishi kerak bo'lgan aniq vaziyatlarni tasvirlab beraman:

  • VIP manzil hech bir serverdagi konfiguratsiyada ro'yxatdan o'tmasligi kerak. Keling, bir vaziyatni tasavvur qilaylik: usta qayta ishga tushdi va u yuklanayotganda, Orchestrator muvaffaqiyatsiz rejimiga o'tdi va qullardan birini usta qildi; keyin eski usta ko'tarildi va endi VIP ikkita mashinada. Bu yomon.
  • Orkestr uchun siz eski usta va yangi ustani chaqirish uchun skript yozishingiz kerak bo'ladi. Eski masterda siz ifdown, yangi masterda esa ifup vip-ni ishga tushirishingiz kerak. Shuningdek, ushbu skriptga uzilishlar sodir bo'lgan taqdirda, har qanday splitbrainni oldini olish uchun eski master kalitidagi port oddiygina o'chirilganligini kiritish yaxshi bo'lar edi.
  • Orchestrator avval VIP-ni olib tashlash va/yoki kalitdagi portni o'chirish uchun skriptingizga qo'ng'iroq qilgandan so'ng, so'ngra yangi masterda VIP ko'tarish skriptini chaqirgandan so'ng, barchaga yangi VIP hozir ekanligini aytish uchun arping buyrug'idan foydalanishni unutmang. Bu yerga.
  • Barcha qullar faqat read_on=1 bo'lishi kerak va siz qulni xo'jayinga ko'targaningizdan so'ng u faqat o'qish_o'qish=0 bo'lishi kerak.
  • Shuni unutmangki, biz tanlagan har qanday qul xo'jayin bo'lishi mumkin (Orkestratorda birinchi navbatda yangi xo'jayinga nomzod sifatida ko'rib chiqilishi kerak bo'lgan qulning afzal ko'rish mexanizmi mavjud, ikkinchisi va qaysi qul. hech qanday sharoitda usta tanlanmaydi). Agar qul xo'jayin bo'lsa, unda qulning yuki qoladi va xo'jayinning yuki qo'shiladi, buni hisobga olish kerak.

Agar sizda yo'q bo'lsa, orkestr nima uchun kerak?

  • Orchestrator butun topologiyani aks ettiruvchi juda qulay grafik interfeysga ega (quyida skrinshotga qarang).
  • Orchestrator qaysi qullar ortda qolayotganini va replikatsiya qayerda umuman buzilganligini kuzatishi mumkin (bizda SMS yuborish uchun Orchestratorga biriktirilgan skriptlar mavjud).
  • Orkestr sizga qaysi qullarda GTID xatosi borligini aytadi.

Orkestr interfeysi:

MySQL uchun orkestrator: nima uchun busiz xatoga chidamli loyihani qura olmaysiz
GTID xatosi nima?

Orkestrning ishlashi uchun ikkita asosiy talab mavjud:

  • Pseudo GTID MySQL klasteridagi barcha mashinalarda yoqilgan bo'lishi kerak; bizda GTID yoqilgan.
  • Hamma joyda bitta turdagi binloglar bo'lishi kerak, siz bayonotdan foydalanishingiz mumkin. Bizda konfiguratsiya bor edi, unda usta va ko'pchilik qullar qatorga ega bo'lgan va ikkitasi tarixan Aralash rejimda qolgan. Natijada, Orchestrator bu qullarni yangi xo'jayinga ulashni xohlamadi.

Esda tutingki, ishlab chiqarish qulidagi eng muhim narsa uning xo'jayin bilan muvofiqligidir! Agar sizda asosiy va tobeda Global tranzaksiya identifikatori (GTID) yoqilgan bo'lsa, gtid_subset funksiyasidan ma'lumotlarni o'zgartirish bo'yicha bir xil so'rovlar ushbu mashinalarda haqiqatda bajarilganligini bilish uchun foydalanishingiz mumkin. Bu haqda ko'proq o'qishingiz mumkin shu yerda.

Shunday qilib, Orchestrator sizga GTID xatosi orqali qulda ustada bo'lmagan tranzaktsiyalar mavjudligini ko'rsatadi. Nima uchun bu sodir bo'lmoqda?

  • Faqat o'qish uchun=1 qulda yoqilmagan, kimdir ulangan va ma'lumotlarni o'zgartirish so'rovini bajargan.
  • Super_read_only=1 qulda yoqilmagan, keyin administrator serverni chalkashtirib yubordi va u erda so'rovni bajardi.
  • Agar siz oldingi ikkala nuqtani ham hisobga olgan bo'lsangiz, unda yana bitta hiyla bor: MySQL-da binloglarni tozalash so'rovi ham binlogga o'tadi, shuning uchun birinchi tozalashda master va barcha tobelarda GTID xatosi paydo bo'ladi. Bundan qanday qochish kerak? Perona-5.7.25-28 binlog_skip_flush_commands=1 sozlamasini kiritdi, bu binloglarga flush yozishni taqiqlaydi. Mysql.com veb-saytida o'rnatilgani mavjud xato.

Yuqorida aytilganlarning barchasini umumlashtiraman. Agar siz hali Orchestrator-dan uzilish rejimida foydalanishni xohlamasangiz, uni kuzatish rejimiga qo'ying. Shunda siz doimo ko'z o'ngingizda MySQL mashinalarining o'zaro ta'siri xaritasi va har bir mashinada qanday replikatsiya turi borligi, qullar ortda qolayotganligi va eng muhimi, ular usta bilan qanchalik mos kelishi haqida vizual ma'lumotlarga ega bo'lasiz!

Aniq savol: "Orkestr qanday ishlashi kerak?" U joriy qullardan yangi masterni tanlashi va keyin unga barcha tobelarni qayta ulashi kerak (buning uchun GTID kerak; agar siz binlog_name va binlog_pos bilan eski mexanizmdan foydalansangiz, u holda qulni joriy masterdan yangisiga almashtiring. shunchaki imkonsiz!). Orkestrimiz bo'lishidan oldin, men bularning barchasini qo'lda qilishim kerak edi. Qadimgi xo'jayin Adaptec boshqaruv moslamasi tufayli osilgan edi, unda 10 ga yaqin qul bor edi. Men VIP-ni xo'jayindan qullardan biriga o'tkazishim va boshqa barcha qullarni unga qayta ulashim kerak edi. Qancha konsolni ochishim kerak edi, bir vaqtning o'zida qancha buyruqlar kiritdim... Ertalab soat 3 gacha kutishim kerak edi, ikkitadan boshqa barcha qullardan yukni olib tashlashim kerak edi, ikkita masterdan birinchi mashinani yasashim kerak edi, darhol ikkinchi mashinani biriktirishim kerak edi. unga, shuning uchun boshqa barcha qullarni yangi xo'jayinga ulang va yukni qaytaring. Umuman olganda, dahshatli ...

Orchestrator uzilish rejimiga o'tganda qanday ishlaydi? Buni biz ustani hozirgidan ko'ra kuchliroq va zamonaviyroq mashinaga aylantirmoqchi bo'lgan vaziyat misolida ko'rsatish oson.

MySQL uchun orkestrator: nima uchun busiz xatoga chidamli loyihani qura olmaysiz
Rasmda jarayonning o'rtasi ko'rsatilgan. Hozirgacha nima qilingan? Biz ba'zi bir qulni yangi xo'jayin qilmoqchi ekanligimizni aytdik, Orchestrator unga boshqa barcha qullarni qayta ulashni boshladi, yangi xo'jayin esa tranzit mashinasi vazifasini bajardi. Ushbu sxema bilan hech qanday xatolik yuz bermaydi, barcha qullar ishlaydi, Orchestrator VIP-ni eski ustadan olib tashlaydi, uni yangisiga o'tkazadi, faqat read_only=0 qiladi va eski masterni unutadi. Hammasi! Xizmatimizning uzilish vaqti VIP uzatish vaqti bo'lib, u 2-3 soniyani tashkil qiladi.

Bugun hammasi shu, hammaga rahmat. Tez orada Orchestrator haqida ikkinchi maqola bo'ladi. Mashhur sovet filmi "Garaj"da bir qahramon: "Men u bilan razvedkaga bormayman!" Xo'sh, orkestr, men siz bilan razvedkaga borardim!

Manba: www.habr.com

a Izoh qo'shish