Orchestrator pro MySQL: proč bez něj nemůžete vytvořit projekt odolný proti chybám

Jakýkoli velký projekt začal s několika servery. Nejprve byl jeden DB server, pak k němu byly přidány slave pro škálování čtení. A pak - stop! Je jeden pán, ale je mnoho otroků; pokud jeden z otroků odejde, bude vše v pořádku, ale pokud odejde master, bude to špatné: výpadek, administrátoři se snaží zvýšit server. Co dělat? Rezervujte si mistra. O tom už psal kolega Pavel Článek, nebudu to opakovat. Místo toho vám řeknu, proč rozhodně potřebujete Orchestrator pro MySQL!

Začněme hlavní otázkou: "Jak přepneme kód na nový stroj, když master odejde?"

• Nejvíce se mi líbí schéma s VIP (Virtual IP), o tom si povíme níže. Je nejjednodušší a nejzřetelnější, i když má zjevné omezení: pán, kterého si vyhradíme, musí být s novým strojem v segmentu L2, čili na druhý DC můžeme zapomenout. A přátelsky, pokud se budete řídit pravidlem, že velká L2 je zlo, protože L2 je pouze na stojan a L3 je mezi stojany, má takové schéma ještě více omezení.
• Do kódu můžete napsat název DNS a vyřešit jej pomocí /etc/hosts. Ve skutečnosti nebude žádné řešení. Výhoda schématu: neexistuje žádné omezení charakteristické pro první metodu, to znamená, že je možné zorganizovat cross-DC. Ale pak vyvstává zřejmá otázka: jak rychle můžeme doručit změnu do /etc/hosts prostřednictvím Puppet-Ansible?
• Druhou metodu můžete trochu změnit: nainstalovat cachovací DNS na všechny webové servery, přes které půjde kód do hlavní databáze. V DNS můžete pro tento záznam nastavit TTL 60. Zdá se, že pokud je metoda správně implementována, je dobrá.
• Schéma s vyhledáváním služeb, což znamená použití Consul a etcd.
• Zajímavá možnost s ProxySQL. Musíte směrovat veškerý provoz do MySQL přes ProxySQL; ProxySQL sám může určit, kdo je master. Mimochodem, o jedné z možností použití tohoto produktu si můžete přečíst v mém článek.

Autor Orchestratoru, pracující v Githubu, nejprve implementoval první schéma s VIP a poté jej převedl na schéma s konzulem.

Typické uspořádání infrastruktury:

Okamžitě popíšu zřejmé situace, které je třeba vzít v úvahu:

• VIP adresa by neměla být registrována v konfiguraci na žádném ze serverů. Představme si situaci: master se restartoval a během načítání Orchestrator přešel do režimu failover a udělal z jednoho z otroků master; pak vstal starý mistr a teď je VIP na dvou autech. Je to špatné.
• Pro orchestrátora budete muset napsat skript pro volání starého a nového mistra. Na starém masteru musíte spustit ifdown a na novém masteru – ifup vip. Bylo by hezké zahrnout do tohoto skriptu také to, že v případě selhání se port na přepínači starého pána jednoduše vypne, aby se zabránilo rozdělení mozku.
• Poté, co Orchestrator zavolá váš skript, aby nejprve odstranil VIP a/nebo zhasl port na přepínači, a poté zavolal skript zvýšení VIP na novém masteru, nezapomeňte použít příkaz arping, abyste všem řekli, že nový VIP je nyní tady.
• Všichni slave by měli mít read_only=1, a jakmile slave povýšíte na master, měl by mít read_only=0.
• Nezapomeňte, že každý otrok, kterého jsme k tomu vybrali, se může stát pánem (Orchestrátor má celý preferenční mechanismus, kterého otroka považovat za kandidáta na nového pána na prvním místě, kterého na druhém místě a který otrok by měl nesmí být za žádných okolností vybrán jako hlavní). Pokud se slave stane masterem, tak na něm zůstane zátěž slave a bude přidána zátěž master, s tím je třeba počítat.

Proč potřebujete Orchestrator, když jej nemáte?

• Orchestrator má velmi uživatelsky přívětivé grafické rozhraní, které zobrazuje celou topologii (viz screenshot níže).
• Orchestrator může sledovat, kteří slave zaostávají a kde replikace obecně selhala (k Orchestratoru máme připojené skripty pro odesílání SMS).
• Orchestrator vám řekne, kteří otroci mají chybu GTID.

Rozhraní orchestru:

Co je chyba GTID?

Aby Orchestrator fungoval, existují dva hlavní požadavky:

• Je nutné, aby bylo na všech strojích v clusteru MySQL povoleno pseudo GTID, my máme GTID povoleno.
• Je nutné, aby byl všude jeden typ binlogů, můžete použít výpis. Měli jsme konfiguraci, ve které měl master a většina otroků Row, a dva historicky zůstali ve smíšeném režimu. Výsledkem bylo, že Orchestrator jednoduše nechtěl tyto otroky připojit k novému masteru.

Pamatujte, že nejdůležitější věcí u produkčního otroka je jeho soulad s pánem! Pokud máte na svém hlavním i podřízeném zařízení povoleno Global Transaction ID (GTID), můžete pomocí funkce gtid_subset zjistit, zda byly na těchto počítačích skutečně provedeny stejné požadavky na změny dat. Můžete si o tom přečíst více zde.

Orchestrator vám tedy prostřednictvím chyby GTID ukáže, že na slave jsou transakce, které nejsou na masteru. Proč se tohle děje?

• Read_only=1 není povoleno na podřízeném zařízení, někdo se připojil a dokončil požadavek na změnu dat.
• Super_read_only=1 není povoleno na slave, pak administrátor, který zmátl server, vstoupil a provedl tam požadavek.
• Pokud jste vzali v úvahu oba předchozí body, pak je tu ještě jeden trik: v MySQL jde požadavek na vyprázdnění binlogů i do binlogu, takže při prvním vyprázdnění se na masteru a všech slave objeví GTID errant. Jak se tomu vyhnout? Perona-5.7.25-28 zavedla nastavení binlog_skip_flush_commands=1, které zakazuje zápis do binlogů. Na webu mysql.com je zavedený chyba.

Dovolte mi shrnout vše výše uvedené. Pokud ještě nechcete Orchestrator používat v režimu převzetí služeb při selhání, přepněte jej do režimu pozorování. Pak budete mít vždy před očima mapu interakce strojů MySQL a vizuální informace o tom, jaký typ replikace je na každém počítači, zda podřízené jednotky nezaostávají a hlavně, jak jsou konzistentní s masterem!

Zřejmá otázka zní: "Jak by měl Orchestrator fungovat?" Musí vybrat nového mastera ze současných slave a pak k němu znovu připojit všechny slave (k tomu je potřeba GTID; pokud použijete starý mechanismus s binlog_name a binlog_pos, pak přepnutí slave z aktuálního mastera na nového je prostě nemožné!). Než jsme měli Orchestrator, jednou jsem to všechno musel dělat ručně. Starý master visel kvůli zabugovanému ovladači Adaptec, měl asi 10 otroků. Potřeboval jsem přenést VIP z mastera na jednoho z otroků a znovu k němu připojit všechny ostatní slave. Kolik konzolí jsem musel otevřít, kolik současných příkazů jsem zadal... Musel jsem počkat do 3 hodin ráno, odstranit zátěž ze všech podřízených kromě dvou, udělat první stroj ze dvou master, okamžitě připojit druhý stroj k němu, takže všechny ostatní otroky připojte k novému masteru a vraťte náklad. Celkově strašné...

Jak Orchestrator funguje, když přejde do režimu převzetí služeb při selhání? Nejsnáze to ilustruje příklad situace, kdy chceme z mistra udělat výkonnější, modernější stroj, než máme nyní.

Obrázek ukazuje střed procesu. Co již bylo do tohoto bodu učiněno? Řekli jsme si, že chceme z nějakého otroka udělat nového pána, Orchestrator k němu začal jednoduše znovu připojovat všechny ostatní otroky, přičemž nový pán fungoval jako tranzitní stroj. S tímto schématem nedochází k žádným chybám, všichni slave fungují, Orchestrator odebere VIP ze starého mastera, přenese ho do nového, udělá read_only=0 a zapomene na starého mastera. Všechno! Výpadek naší služby je doba VIP transferu, která je 2-3 sekundy.

To je pro dnešek vše, děkuji všem. Brzy bude druhý článek o Orchestrator. Ve slavném sovětském filmu „Garáž“ jedna postava řekla: „Nešel bych s ním na průzkum! Takže, Orchestrátore, šel bych s vámi na průzkum!

Zdroj: www.habr.com