V této třídílné sérii blogů jsme v části I představili rámec vysoké dostupnosti (HA) pro hostování MySQL a v části II jsme probrali podrobnosti o semisynchronní replikaci MySQL. Nyní v části III přezkoumáme, jak framework zvládá některé z důležitých scénářů selhání MySQL a obnovuje se, aby byla zajištěna vysoká dostupnost.
Scénáře selhání MySQL
Scénář 1 – Mistrovské MySQL padá
- Rámec Corosync a Pacemaker detekuje, že hlavní MySQL již není k dispozici. Pacemaker sníží úroveň hlavního prostředku a pokusí se jej obnovit restartováním služby MySQL, je-li to možné.
- V tomto okamžiku byly vzhledem k semisynchronní povaze replikace všechny transakce provedené na hlavním serveru přijaty alespoň jedním z podřízených zařízení.
- Pacemaker čeká, dokud se všechny přijaté transakce neuplatní na otroky, a nechá je ohlásit skóre povýšení. Výpočet skóre se provádí tak, že skóre je ‚0‘, pokud je podřízená jednotka zcela synchronizována s hlavní jednotkou, a jinak je záporné číslo.
- Pacemaker vybere slave zařízení, které nahlásilo skóre 0, a povýší tohoto slave, který nyní převezme roli hlavního MySQL, na kterém je povolen zápis.
- Po povýšení slave agent zdroje spustí modul přesměrování DNS. Modul aktualizuje záznam DNS serveru proxy s IP adresou nového hlavního serveru, čímž usnadňuje přesměrování všech zápisů aplikací na nového hlavního serveru.
- Pacemaker také nastaví dostupné otroky, aby se mohli začít replikovat z tohoto nového hlavního serveru.
Tedy kdykoli dojde k výpadku hlavního MySQL (ať už kvůli havárii MySQL, havárii OS, restartu systému atd.), náš rámec HA to detekuje a povýší na vhodného slave převzít roli mistra. Tím je zajištěno, že systém bude aplikacím nadále dostupný.
#Vysvětlení rámce vysoké dostupnosti MySQL – Část III:Scénáře selhání Kliknutím na tweet
Scénář 2 – Slave MySQL padá
- Rámec Corosync a Pacemaker detekuje, že slave MySQL již není k dispozici.
- Pacemaker se pokusí obnovit zdroj pokusem o restartování MySQL na uzlu. Pokud se objeví, je přidán zpět k aktuálnímu masteru jako slave a replikace pokračuje.
- Pokud se obnovení nezdaří, kardiostimulátor ohlásí, že zdroj je nedostupný – na základě toho lze generovat výstrahy nebo upozornění. V případě potřeby se o obnovu tohoto uzlu postará tým podpory ScaleGrid.
- V tomto případě to nemá žádný dopad na dostupnost služeb MySQL.
Scénář 3 – Síťový oddíl – Přerušení síťové konektivity mezi hlavními a podřízenými uzly
Toto je klasický problém v jakémkoli distribuovaném systému, kde si každý uzel myslí, že ostatní uzly jsou mimo provoz, zatímco ve skutečnosti je přerušena pouze síťová komunikace mezi uzly. Tento scénář je běžněji známý jako scénář rozděleného mozku a pokud není správně zpracován, může vést k tomu, že se více než jeden uzel bude vydávat za hlavní MySQL, což zase vede k nekonzistentnosti dat a poškození.
Na příkladu si ukážeme, jak se náš rámec vypořádává se scénáři rozděleného mozku v clusteru. Předpokládáme, že kvůli problémům se sítí se cluster rozdělil do dvou skupin – master v jedné skupině a 2 slave ve druhé skupině, a budeme to označovat jako [(M), (S1,S2)].
- Corosync zjistí, že hlavní uzel není schopen komunikovat s podřízenými uzly a podřízené uzly mohou komunikovat mezi sebou, ale ne s nadřízeným .
- Hlavní uzel nebude schopen potvrdit žádné transakce, protože semisynchronní replikace očekává potvrzení od alespoň jednoho z podřízených, než se hlavní uzel může potvrdit. Současně Pacemaker vypne MySQL na hlavním uzlu kvůli nedostatku kvora na základě nastavení Pacemaker ‚no-quorum-policy =stop‘. Kvorum zde znamená většinu uzlů nebo dva ze tří v nastavení clusteru se 3 uzly. Vzhledem k tomu, že v tomto oddílu clusteru běží pouze jeden hlavní uzel, spustí se nastavení zásad bez kvora, což vede k vypnutí hlavního serveru MySQL.
- Pacemaker v oddílu [(S1), (S2)] nyní zjistí, že v clusteru není k dispozici žádný hlavní modul, a zahájí proces povýšení. Za předpokladu, že S1 je aktuální s hlavním serverem (jak je zaručeno semisynchronní replikací), je poté povýšen na nový hlavní server.
- Aplikační provoz bude přesměrován na tento nový hlavní uzel MySQL a podřízený S2 se začne replikovat z nového hlavního uzlu.
Vidíme tedy, že framework MySQL HA efektivně zpracovává scénáře rozděleného mozku a zajišťuje jak konzistenci dat, tak dostupnost v případě, že dojde k přerušení síťového připojení mezi master a slave uzly.
P>Toto uzavírá naše třídílná blogová série o rámci MySQL High Availability (HA) využívající semisynchronní replikaci a zásobník Corosync plus Pacemaker. Ve ScaleGrid nabízíme vysoce dostupný hosting pro MySQL na AWS a MySQL na Azure, který je implementován na základě konceptů vysvětlených v této sérii blogů. Navštivte prosím konzolu ScaleGrid pro bezplatnou zkušební verzi našich řešení.
