Ve společnosti Citymobil používáme databázi MySQL jako hlavní trvalé úložiště dat. Máme několik databázových clusterů pro různé služby a účely.

Neustálá dostupnost masteru je kritickým ukazatelem výkonu celého systému a jeho jednotlivých částí. Automatické obnovení clusteru v případě selhání hlavního serveru výrazně zkracuje dobu odezvy na incidenty a prostoje systému. V tomto článku se podívám na návrh vysoké dostupnosti (HA) pro cluster MySQL založený na MySQL Orchestrator a virtuální IP adresy (VIP).

HA řešení založené na VIP

Nejprve vám stručně řeknu, jaký je náš systém ukládání dat.

Používáme klasické schéma replikace s jedním masterem přístupným pro zápis a více replikami pouze pro čtení. Cluster může obsahovat mezilehlý master - uzel, který je pro ostatní replikou i masterem. Klienti přistupují k replikám prostřednictvím HAProxy, což umožňuje rovnoměrné rozložení zátěže a snadné škálování. Použití HAProxy je z historických důvodů a v současné době probíhá proces migrace na ProxySQL.

Replikace se provádí v semisynchronním režimu založeném na GTID. To znamená, že alespoň jedna replika musí zaprotokolovat transakci, než bude považována za úspěšnou. Tento režim replikace poskytuje optimální rovnováhu mezi výkonem a bezpečností dat v případě selhání hlavního uzlu. V podstatě všechny změny jsou přeneseny z masteru do replik pomocí Row Based Replication (RBR), ale některé uzly mohou mít mixed binlog format.

Orchestrátor pravidelně aktualizuje stav topologie clusteru, analyzuje přijaté informace a pokud nastanou problémy, může spustit proceduru automatické obnovy. Vývojář je odpovědný za samotný postup, protože jej lze implementovat různými způsoby: na základě VIP, DNS, pomocí služeb zjišťování služeb nebo vlastních mechanismů.

Jedním jednoduchým způsobem, jak obnovit master, pokud selže, je použít plovoucí VIP adresy.

Co potřebujete vědět o tomto řešení, než budete pokračovat:

VIP je IP adresa, která není spojena s konkrétním fyzickým síťovým rozhraním. Pokud některý uzel selže nebo během plánované údržby, můžeme VIP přepnout na jiný zdroj s minimálním prostojem.
Uvolnění a vydání virtuální IP adresy je levná a rychlá operace.
Pro práci s VIP potřebujete přístup k serveru přes SSH nebo použití speciálních utilit, např. keepalived.

Podívejme se na možné problémy s naším průvodcem a představme si, jak by měl mechanismus automatické obnovy fungovat.

Síťové připojení k masteru zmizelo nebo se vyskytl problém na úrovni hardwaru a server je nedostupný

Orchestrátor aktualizuje topologii clusteru, každá replika hlásí, že hlavní server je nedostupný. Orchestrátor zahájí proces výběru repliky vhodné pro roli nového mistra a zahájí obnovu.
Snažíme se odstranit VIP ze starého mistra - bez úspěchu.
Replika se přepne do role předlohy. Probíhá přestavba topologie.
Přidání nového síťového rozhraní s VIP. Vzhledem k tomu, že nebylo možné VIP odebrat, začneme na pozadí pravidelně odesílat žádost bezúplatná ARP. Tento typ požadavku/odpovědi vám umožňuje aktualizovat tabulku mapování IP a MAC adres na připojených přepínačích, čímž vás upozorní, že se náš VIP přesunul. Tím se minimalizuje pravděpodobnost split brain při návratu starého mistra.
Všechna nová připojení jsou okamžitě přesměrována na nový master. Stará připojení selžou a na úrovni aplikace jsou prováděna opakovaná volání do databáze.

Server pracuje v normálním režimu, došlo k chybě na úrovni DBMS

Algoritmus je podobný předchozímu případu: aktualizace topologie a zahájení procesu obnovy. Protože je server dostupný, úspěšně uvolníme VIP na starém masteru, přeneseme ho na nový a odešleme několik požadavků ARP. Případný návrat starého masteru by neměl mít vliv na přestavěný cluster a chod aplikace.

Další problémy

Selhání replik nebo přechodných masterů nevede na automatické akce a vyžaduje ruční zásah.

Rozhraní virtuální sítě je vždy přidáno dočasně, to znamená, že po restartu serveru není VIP přiřazen automaticky. Každá instance databáze se standardně spouští v režimu pouze pro čtení, orchestrátor automaticky přepne nový master na zápis a pokusí se jej nainstalovat read only na starého mistra. Tyto akce jsou zaměřeny na snížení pravděpodobnosti split brain.

Během procesu obnovy mohou nastat problémy, které by měly být kromě standardních monitorovacích nástrojů oznámeny také prostřednictvím uživatelského rozhraní orchestrátoru. Rozšířili jsme REST API přidáním této funkce (PR aktuálně přezkoumáváno).

Obecný diagram řešení HA je uveden níže.

Výběr nového mistra

Orchestr je dostatečně chytrý a snaží se vybírat nejvhodnější replika jako nový mistr podle následujících kritérií:

replika zaostává za předlohou;
MySQL verze předlohy a repliky;
typ replikace (RBR, SBR nebo smíšené);
umístění ve stejných nebo různých datových centrech;
dostupnost errant GTID — transakce, které byly provedeny na replice a nejsou na masteru;
jsou také zohledněna pravidla vlastního výběru.

Ne každé tágo je ideálním kandidátem na mistra. K zálohování dat lze například použít repliku nebo server má slabší hardwarovou konfiguraci. Orchestr podporuje manuální pravidla, pomocí kterých si můžete přizpůsobit své preference výběru kandidátů od nejpreferovanějších po ignorované.

Doba odezvy a zotavení

V případě incidentu je důležité minimalizovat prostoje systému, proto se podívejme na parametry MySQL, které ovlivňují vytváření a aktualizaci topologie clusteru orchestrátorem:

slave_net_timeout — počet sekund, během kterých replika čeká na nová data nebo signál srdečního tepu od mastera, než je spojení rozpoznáno jako ztracené a znovu navázáno. Čím nižší je hodnota, tím rychleji může replika určit, že komunikace s masterem je přerušena. Tuto hodnotu nastavíme na 5 sekund.
MASTER_CONNECT_RETRY — počet sekund mezi pokusy o opětovné připojení. V případě problémů se sítí nízká hodnota tohoto parametru umožní rychlé opětovné připojení a zabrání spuštění procesu obnovy clusteru. Doporučená hodnota je 1 sekunda.
MASTER_RETRY_COUNT — maximální počet pokusů o opětovné připojení.
MASTER_HEARTBEAT_PERIOD — interval v sekundách, po kterém master vyšle signál srdečního tepu. Výchozí hodnota je poloviční slave_net_timeout.

Parametry orchestru:

DelayMasterPromotionIfSQLThreadNotUpToDate - pokud se rovná true, pak hlavní role nebude použita na kandidátskou repliku, dokud vlákno SQL repliky nedokončí všechny neaplikované transakce z protokolu přenosu. Tuto možnost používáme, abychom zabránili ztrátě transakcí, když všechny kandidátské repliky zaostávají.
InstancePollSeconds — četnost budování a aktualizace topologie.
RecoveryPollSeconds — četnost topologické analýzy. Pokud je zjištěn problém, je zahájena obnova topologie. Tento konstantní, rovnající se 1 sekundě.

Každý uzel clusteru je jednou za každý dotazován orchestrátorem InstancePollSeconds sekundy Když je zjištěn problém, je vynucený stav clusteru aktualizovánoa poté je učiněno konečné rozhodnutí o provedení obnovy. Experimentováním s různými parametry databáze a orchestrátoru jsme byli schopni zkrátit dobu odezvy a zotavení na 30 sekund.

Zkušební stojan

Začali jsme testovat schéma HA s vývojem lokálu zkušební stolice a další implementace v testovacím a produkčním prostředí. Místní stojan je plně automatizovaný na základě Dockeru a umožňuje vám experimentovat s konfigurací orchestrátoru a sítě, škálovat cluster ze 2–3 serverů na několik desítek a provádět cvičení v bezpečném prostředí.

Během cvičení volíme jednu z metod emulace problému: okamžitě zastřelit mistra pomocí kill -9, jemně ukončete proces a zastavte server (docker-compose stop), simulovat problémy se sítí pomocí iptables -j REJECT nebo iptables -j DROP. Očekáváme následující výsledky:

orchestrátor zjistí problémy s masterem a aktualizuje topologii do 10 sekund;
automaticky se spustí procedura obnovy: změní se konfigurace sítě, role master přejde na repliku, topologie bude přestavěna;
nový master se stane zapisovatelným, živé repliky se během procesu přestavby neztratí;
data se začnou zapisovat do nového masteru a replikovat;
Celková doba zotavení nebude delší než 30 sekund.

Jak víte, systém se může chovat odlišně v testovacím a produkčním prostředí kvůli různým hardwarovým a síťovým konfiguracím, rozdílům v syntetickém a reálném zatížení atd. Proto pravidelně provádíme cvičení v reálných podmínkách, kde kontrolujeme, jak se systém chová při ztrátě síťové konektivity nebo degradaci jeho jednotlivých částí. Do budoucna chceme vybudovat zcela identickou infrastrukturu pro obě prostředí a automatizovat její testování.

Závěry

Stav hlavního uzlu úložného systému je jedním z hlavních úkolů SRE a provozního týmu. Implementace řešení orchestrátoru a HA na bázi VIP nám umožnila dosáhnout následujících výsledků:

spolehlivá detekce problémů s topologií databázového clusteru;
automatická a rychlá reakce na incidenty související s masterem, což snižuje prostoje systému.

Řešení má však svá omezení a nevýhody:

škálování schématu HA na několik datových center bude vyžadovat jednu síť L2 mezi nimi;
Před přiřazením VIP na novém masteru jej musíme uvolnit na starém. Proces je sekvenční, což zvyšuje dobu zotavení;
uvolnění VIP vyžaduje SSH přístup k serveru nebo jakýkoli jiný způsob volání vzdálených procedur. Protože na serveru nebo databázi dochází k problémům, které způsobily proces obnovy, nemůžeme si být jisti, že odstranění VIP bude úspěšně dokončeno. A to může vést ke vzniku dvou serverů se stejnou virtuální IP adresou a k problému split brain.

Vyhnout se split brain, můžete použít metodu STONITH („Shoot The Other Node In The Head“), která zcela izoluje nebo deaktivuje problémový uzel. Existují další způsoby, jak implementovat vysokou dostupnost clusteru: kombinace VIP a DNS, služby zjišťování služeb a proxy, synchronní replikace a další metody, které mají své nevýhody a výhody.

Mluvil jsem o našem přístupu k vytvoření clusteru s podporou převzetí služeb při selhání MySQL. Snadno se implementuje a poskytuje přijatelnou úroveň spolehlivosti za současných podmínek. Jak se bude vyvíjet celý systém obecně a infrastruktura zvláště, bude se tento přístup nepochybně vyvíjet.

Zdroj: www.habr.com

Orchestrator a VIP jako řešení HA pro cluster MySQL