Akýkoľvek veľký projekt začal s niekoľkými servermi. Najprv tu bol jeden DB server, potom sa k nemu pridali slave na škálovanie čítania. A potom - stop! Je jeden pán, ale je veľa otrokov; ak jeden z otrokov odíde, všetko bude v poriadku, ale ak odíde pán, bude to zlé: prestoje, správcovia sa snažia zvýšiť server. Čo robiť? Rezervujte si majstra. Kolega Pavel o tom už písal , nebudem to opakovať. Namiesto toho vám poviem, prečo určite potrebujete Orchestrator pre MySQL!
Začnime hlavnou otázkou: "Ako prepneme kód na nový stroj, keď pán odíde?"
- Najviac sa mi páči schéma s VIP (Virtual IP), o nej si povieme nižšie. Je to najjednoduchšie a najzreteľnejšie, aj keď má zjavné obmedzenie: pán, ktorého si vyhradíme, musí byť s novým strojom v segmente L2, čiže na druhý DC môžeme zabudnúť. A priateľsky, ak sa budete riadiť pravidlom, že veľká L2 je zlo, pretože L2 je len na stojan a L3 je medzi stojanmi, takáto schéma má ešte viac obmedzení.
- Do kódu môžete napísať názov DNS a vyriešiť ho cez /etc/hosts. V skutočnosti nebude žiadne rozuzlenie. Výhoda schémy: neexistuje žiadne obmedzenie charakteristické pre prvú metódu, to znamená, že je možné zorganizovať cross-DC. Potom však vyvstáva jasná otázka: ako rýchlo môžeme doručiť zmenu do /etc/hosts cez Puppet-Ansible?
- Druhú metódu môžete trochu zmeniť: nainštalujte caching DNS na všetky webové servery, cez ktoré pôjde kód do hlavnej databázy. V DNS môžete pre tento záznam nastaviť TTL 60. Zdá sa, že ak je implementovaná správne, metóda je dobrá.
- Schéma s vyhľadávaním služieb, čo znamená použitie konzula atď.
- Zaujímavá možnosť s . Musíte smerovať všetku komunikáciu do MySQL cez ProxySQL; ProxySQL sám môže určiť, kto je master. Mimochodom, o jednej z možností použitia tohto produktu si môžete prečítať v mojom .
Autor Orchestrator, pracujúci v Githube, najprv implementoval prvú schému s VIP a potom ju previedol na schému s konzulom.
Typické usporiadanie infraštruktúry:
Okamžite popíšem zrejmé situácie, ktoré je potrebné vziať do úvahy:
- VIP adresa by nemala byť zaregistrovaná v konfigurácii na žiadnom zo serverov. Predstavme si situáciu: master sa rebootoval a kým sa načítal, Orchestrator prešiel do režimu núdzového prepnutia a z jedného z otrokov urobil master; potom starý majster vstal a teraz je VIP na dvoch autách. Je to zlé.
- Pre orchestrátora budete musieť napísať skript na volanie starého a nového majstra. Na starom masteri musíte spustiť ifdown a na novom master – ifup vip. Bolo by pekné do tohto skriptu zahrnúť aj to, že v prípade zlyhania sa port na prepínači starého majstra jednoducho vypne, aby sa predišlo rozdeleniu mozgu.
- Potom, čo Orchestrator zavolá váš skript, aby najprv odstránil VIP a/alebo vypol port na prepínači, a potom zavolal skript zvýšenia VIP na novom masteri, nezabudnite použiť príkaz arping, aby ste všetkým povedali, že nový VIP je teraz tu.
- Všetci podriadení by mali mať read_only=1 a akonáhle povýšite podriadenú jednotku na master, mala by mať read_only=0.
- Nezabudnite, že každý otrok, ktorého sme na to vybrali, sa môže stať pánom (Orchestrator má celý mechanizmus preferencií, ktorého otroka v prvom rade považovať za kandidáta na nového pána, ktorý v druhom rade a ktorý otrok by mal za žiadnych okolností nevyberať majstra). Ak sa slave stane masterom, tak na ňom ostane záťaž slave a pripočíta sa zaťaženie mastera, s tým treba počítať.
Prečo potrebujete Orchestrator, ak ho nemáte?
- Orchestrator má veľmi užívateľsky prívetivé grafické rozhranie, ktoré zobrazuje celú topológiu (pozri snímku obrazovky nižšie).
- Orchestrator môže sledovať, ktorí slave zaostávajú a kde sa replikácia vo všeobecnosti pokazila (k Orchestratoru máme pripojené skripty na odosielanie SMS).
- Orchestrator vám povie, ktorí otroci majú chybu GTID.
Rozhranie orchestra:
Čo je chyba GTID?
Na prácu Orchestrator existujú dve hlavné požiadavky:
- Je potrebné, aby bolo na všetkých strojoch v MySQL klastri povolené pseudo GTID, my máme GTID povolené.
- Je potrebné, aby bol všade jeden typ binlogov, môžete použiť výpis. Mali sme konfiguráciu, v ktorej mal master a väčšina otrokov Row a dvaja historicky zostali v zmiešanom režime. Výsledkom bolo, že Orchestrator jednoducho nechcel pripojiť týchto otrokov k novému pánovi.
Pamätajte, že najdôležitejšou vecou pri výrobe otroka je jeho súlad s pánom! Ak máte zapnuté globálne ID transakcie (GTID) na hlavnom aj podriadenom zariadení, môžete pomocou funkcie gtid_subset zistiť, či sa na týchto počítačoch skutočne vykonali rovnaké požiadavky na zmeny údajov. Môžete si o tom prečítať viac .
Orchestrator vám teda prostredníctvom chyby GTID ukáže, že na podriadenom zariadení sú transakcie, ktoré nie sú na nadradenom zariadení. Prečo sa to deje?
- Read_only=1 nie je povolené na podriadenom zariadení, niekto sa pripojil a dokončil požiadavku na zmenu údajov.
- Super_read_only=1 nie je povolená na podriadenom zariadení, potom administrátor, ktorý si poplietol server, vstúpil a vykonal požiadavku tam.
- Ak ste vzali do úvahy oba predchádzajúce body, tak je tu ešte jeden trik: v MySQL ide požiadavka na vyprázdnenie binlogov aj do binlogu, takže pri prvom spláchnutí sa na masteri a všetkých slave objaví GTID errant. Ako sa tomu vyhnúť? Perona-5.7.25-28 zaviedla nastavenie binlog_skip_flush_commands=1, ktoré zakazuje zapisovanie vyprázdnenia do binlogov. Na webe mysql.com je zavedený .
Dovoľte mi zhrnúť všetko vyššie uvedené. Ak ešte nechcete používať Orchestrator v núdzovom režime, prepnite ho do pozorovacieho režimu. Potom budete mať vždy pred očami mapu interakcie počítačov MySQL a vizuálne informácie o tom, aký typ replikácie je na každom počítači, či podriadení zaostávajú a čo je najdôležitejšie, ako sú konzistentní s hlavným!
Zjavná otázka znie: „Ako by mal fungovať Orchestrator? Musí vybrať nového mastera zo súčasných slave a potom k nemu znova pripojiť všetkých slave (na to je potrebné GTID; ak použijete starý mechanizmus s binlog_name a binlog_pos, potom prepnete slave z aktuálneho mastera na nový je jednoducho nemožné!). Predtým, ako sme mali Orchestrator, som to všetko raz musel robiť ručne. Starý pán visel kvôli zabugovanému ovládaču Adaptec, mal asi 10 otrokov. Potreboval som preniesť VIP z pána na jedného z otrokov a znova k nemu pripojiť všetkých ostatných otrokov. Koľko konzol som musel otvoriť, koľko simultánnych príkazov som zadal... Musel som počkať do 3:XNUMX, odstrániť záťaž zo všetkých otrokov okrem dvoch, urobiť prvý stroj z dvoch master, okamžite pripojiť druhý stroj k nemu, tak pripojte všetkých ostatných otrokov k novému pánovi a vráťte náklad. Celkovo strašné...
Ako funguje Orchestrator, keď prejde do núdzového režimu? Najľahšie to ilustruje príklad situácie, keď chceme z majstra urobiť výkonnejší, modernejší stroj, ako máme teraz.
Obrázok ukazuje stred procesu. Čo sa už do tohto bodu urobilo? Povedali sme si, že chceme z nejakého otroka urobiť nového pána, Orchestrator k nemu začal jednoducho pripájať všetkých ostatných otrokov, pričom nový pán funguje ako tranzitný stroj. S touto schémou sa nevyskytujú žiadne chyby, všetci slave fungujú, Orchestrator odoberie VIP zo starého majstra, prenesie ho do nového, urobí read_only=0 a zabudne na starého majstra. Všetky! Výpadok našej služby je čas VIP transferu, ktorý je 2-3 sekundy.
To je na dnes všetko, ďakujem všetkým. Čoskoro bude druhý článok o Orchestratorovi. V slávnom sovietskom filme „Garáž“ jedna postava povedala: „Nešiel by som s ním na prieskum! Takže, orchester, išiel by som s vami na prieskum!
Zdroj: hab.com