Schéma databáze není něco, co je vytesáno do kamene. Je určen pro danou aplikaci, ale pak se požadavky mohou změnit a většinou se i mění. Do aplikace jsou přidávány nové moduly a funkcionality, sbírá se více dat, provádí se refaktoring kódu a datového modelu. Z toho vyplývá potřeba upravit schéma databáze, aby se přizpůsobilo těmto změnám; přidávat nebo upravovat sloupce, vytvářet nové tabulky nebo rozdělovat velké tabulky. Dotazy se také mění, protože vývojáři přidávají nové způsoby, jak mohou uživatelé s daty interagovat – nové dotazy by mohly používat nové, efektivnější indexy, takže je spěcháme s jejich vytvářením, abychom aplikaci poskytli nejlepší databázový výkon.
Jak tedy nejlépe přistupovat ke změně schématu? Jaké nástroje jsou užitečné? Jak minimalizovat dopad na produkční databázi? Jaké jsou nejčastější problémy s návrhem schémat? Jaké nástroje vám mohou pomoci udržet si přehled o svém schématu? V tomto příspěvku na blogu vám poskytneme krátký přehled toho, jak provádět změny schématu v MySQL a MariaDB. Upozorňujeme, že nebudeme diskutovat o změnách schématu v kontextu Galera Cluster. Již jsme diskutovali o Total Order Isolation, Rolling Schema Upgradech a tipech, jak minimalizovat dopad RSU v předchozích příspěvcích na blogu. Probereme také tipy a triky týkající se návrhu schémat a toho, jak vám ClusterControl může pomoci udržet si přehled o všech změnách schématu.
Typy změn schématu
Pěkně popořádku. Než se pustíme do tématu, musíme pochopit, jak MySQL a MariaDB provádějí změny schématu. Víte, jedna změna schématu se nerovná jiné změně schématu.
Možná jste slyšeli o online úpravách, okamžitých úpravách nebo úpravách na místě. To vše je výsledkem práce, která probíhá s cílem minimalizovat dopad změn schématu na produkční databázi. Historicky byly téměř všechny změny schématu blokující. Pokud jste provedli změnu schématu, všechny dotazy se začnou hromadit a čekají na dokončení ALTER. To samozřejmě představovalo vážné problémy pro produkční nasazení. Jistě, lidé okamžitě začnou hledat náhradní řešení a budeme o nich diskutovat později v tomto blogu, protože i dnes jsou stále aktuální. Ale také se začalo pracovat na zlepšení schopnosti MySQL spouštět DDL (Data Definition Language) bez velkého dopadu na ostatní dotazy.
Okamžité změny
Někdy není potřeba dotýkat se žádných dat v tabulkovém prostoru, protože vše, co je třeba změnit, jsou metadata. Příkladem zde bude vypuštění indexu nebo přejmenování sloupce. Takové operace jsou rychlé a efektivní. Obvykle je jejich dopad omezený. Není to však bez dopadu. Někdy trvá provedení změny v metadatech několik sekund a taková změna vyžaduje získání zámku metadat. Tento zámek je na bázi jednotlivých tabulek a může blokovat další operace, které mají být na této tabulce provedeny. Uvidíte to jako položky „Čekání na zámek metadat tabulky“ v seznamu procesů.
Příkladem takové změny může být okamžitý ADD COLUMN, představený v MariaDB 10.3 a MySQL 8.0. Dává možnost provést tuto velmi populární změnu schématu bez jakéhokoli zpoždění. MariaDB i Oracle se rozhodly zahrnout kód z Tencent Game, který umožňuje okamžitě přidat nový sloupec do tabulky. To je za určitých specifických podmínek; sloupec musí být přidán jako poslední, v tabulce nemohou existovat fulltextové indexy, nelze komprimovat formát řádků - více informací o tom, jak funguje sloupec pro okamžité přidání, najdete v dokumentaci MariaDB. Pro MySQL lze jedinou oficiální referenci nalézt na blogu mysqlserverteam.com, i když existuje chyba v aktualizaci oficiální dokumentace.
Změny na místě
Některé změny vyžadují úpravu dat v tabulkovém prostoru. Takové úpravy lze provádět na samotných datech a není třeba vytvářet dočasnou tabulku s novou datovou strukturou. Takové změny obvykle (i když ne vždy) umožňují provádění dalších dotazů dotýkajících se tabulky, zatímco probíhá změna schématu. Příkladem takové operace je přidání nového sekundárního indexu do tabulky. Provedení této operace bude nějakou dobu trvat, ale umožní provedení DML.
Znovu sestavení tabulky
Pokud není možné provést změnu na místě, InnoDB vytvoří dočasnou tabulku s novou požadovanou strukturou. Poté zkopíruje existující data do nové tabulky. Tato operace je nejdražší a je pravděpodobné (i když ne vždy se to stane), že DML uzamkne. Výsledkem je, že taková změna schématu je velmi složitá na provádění na velké tabulce na samostatném serveru bez pomoci externích nástrojů - obvykle si nemůžete dovolit mít databázi uzamčenou na dlouhé minuty nebo dokonce hodiny. Příkladem takové operace může být změna datového typu sloupce, například z INT na VARCHAR.
Změny a replikace schématu
Dobře, takže víme, že InnoDB umožňuje online změny schématu a pokud se podíváme na dokumentaci MySQL, uvidíme, že většinu změn schématu (alespoň mezi těmi nejběžnějšími) lze provádět online. Jaký je důvod věnovat hodiny vývoje vytváření online nástrojů pro změnu schémat, jako je gh-ost? Můžeme přijmout, že pt-online-schema-change je pozůstatkem starých, špatných časů, ale gh-ost je nový software.
Odpověď je složitá. Existují dva hlavní problémy.
Pro začátek, jakmile spustíte změnu schématu, nemáte nad ní kontrolu. Můžete to přerušit, ale nemůžete to pozastavit. Nemůžete to přiškrtit. Jak si dokážete představit, přestavba tabulky je nákladná operace a i když InnoDB umožňuje spouštění DML, další I/O pracovní zátěž z DDL ovlivní všechny ostatní dotazy a neexistuje způsob, jak omezit tento dopad na úroveň, která je přijatelná pro aplikace.
Druhým, ještě závažnějším problémem, je replikace. Pokud provedete neblokující operaci, která vyžaduje opětovné sestavení tabulky, skutečně nezamkne DML, ale to platí pouze pro master. Předpokládejme, že dokončení takového DDL trvalo 30 minut – rychlost ALTER závisí na hardwaru, ale je poměrně běžné vidět takové doby provádění u tabulek o velikosti 20 GB. Poté se replikuje na všechny podřízené jednotky a od okamžiku spuštění DDL na těchto podřízených zařízeních bude replikace čekat na dokončení. Nezáleží na tom, zda používáte MySQL nebo MariaDB, nebo zda máte vícevláknovou replikaci. Slave se zpozdí – počkají těchto 30 minut na dokončení DDL, než začnou aplikovat zbývající události binlog. Jak si dokážete představit, 30 minut zpoždění (někdy nebude přijatelných ani 30 sekund - vše závisí na aplikaci) je něco, co znemožňuje použití těchto otroků pro škálování. Samozřejmě existují zástupná řešení – můžete provádět změny schématu od spodu až po vrchol replikačního řetězce, ale to vážně omezuje vaše možnosti. Zejména pokud používáte replikaci založenou na řádcích, můžete tímto způsobem provádět pouze kompatibilní změny schématu. Několik příkladů omezení řádkové replikace; nemůžete vypustit žádný sloupec, který není poslední, nemůžete přidat sloupec na jinou pozici, než je poslední. Nelze také změnit typ sloupce (například INT -> VARCHAR).
Jak můžete vidět, replikace zvyšuje složitost způsobu provádění změn schématu. Operace, které jsou neblokující na samostatném hostiteli, se při provádění na podřízených zařízeních stanou blokujícími. Pojďme se podívat na několik metod, které můžete použít k minimalizaci dopadu změn schématu.
Online nástroje pro změnu schématu
Jak jsme uvedli dříve, existují nástroje, které jsou určeny k provádění změn schématu. Nejoblíbenější z nich jsou pt-online-schema-change vytvořené Perconou a gh-ost, vytvořené GitHubem. V sérii blogových příspěvků jsme je porovnali a diskutovali o tom, jak lze gh-ost použít k provádění změn schématu a jak můžete omezit a překonfigurovat probíhající migraci. Zde nebudeme zacházet do podrobností, ale přesto bychom rádi zmínili některé z nejdůležitějších aspektů používání těchto nástrojů. Pro začátek, změna schématu provedená prostřednictvím pt-osc nebo gh-ost proběhne na všech databázových uzlech najednou. Neexistuje žádné zpoždění, pokud jde o to, kdy bude změna aplikována. To umožňuje používat tyto nástroje i pro změny schématu, které nejsou kompatibilní s replikací založenou na řádcích. Přesné mechanismy toho, jak tyto nástroje sledují změny v tabulce, se liší (spouštěče v pt-osc vs. analýza binlog v gh-ost), ale hlavní myšlenka je stejná - vytvoří se nová tabulka s požadovaným schématem a existující data se zkopírované ze staré tabulky. Mezitím jsou DML sledovány (tak či onak) a aplikovány na novou tabulku. Jakmile jsou všechna data migrována, tabulky se přejmenují a nová tabulka nahradí starou. Toto je atomická operace, takže není viditelná pro aplikaci. Oba nástroje mají možnost snížit zátěž a pozastavit operace. Gh-ost může zastavit veškerou aktivitu, pt-osc pouze může zastavit proces kopírování dat mezi starou a novou tabulkou - triggery zůstanou aktivní a budou pokračovat v duplikování dat, což přidává určitou režii. Kvůli tabulce přejmenování mají oba nástroje určitá omezení týkající se cizích klíčů - nejsou podporovány gh-ost, částečně podporovány pt-osc buď prostřednictvím běžného ALTER, což může způsobit zpoždění replikace (není možné, pokud je podřízená tabulka velká) nebo zrušení staré tabulky před přejmenováním nové – je to nebezpečné, protože neexistuje způsob, jak se vrátit zpět, pokud z nějakého důvodu nebyla data do nové tabulky zkopírována správně. Spouštěče je také obtížné podporovat.
Nejsou podporovány v gh-ost, pt-osc v MySQL 5.7 a novější má omezenou podporu pro tabulky s existujícími spouštěči. Dalším důležitým omezením online nástrojů pro změnu schématu je, že v tabulce musí existovat jedinečný nebo primární klíč. Používá se k identifikaci řádků ke kopírování mezi starými a novými tabulkami. Tyto nástroje jsou také mnohem pomalejší než přímé ALTER – změna, která při spuštění ALTER trvá hodiny, může při použití pt-osc nebo gh-ost trvat dny.
Na druhou stranu, jak jsme zmínili, pokud jsou požadavky splněny a omezení nevstoupí do hry, můžete všechny změny schématu spustit pomocí jednoho z nástrojů. Vše proběhne ve stejnou dobu na všech hostitelích, takže se nemusíte starat o kompatibilitu. Máte také určitou úroveň kontroly nad tím, jak se proces provádí (méně v pt-osc, mnohem více v gh-ost).
Můžete snížit dopad změny schématu, můžete je pozastavit a nechat běžet pouze pod dohledem, můžete změnu otestovat, než ji skutečně provedete. Můžete je nechat sledovat zpoždění replikace a pozastavit se v případě zjištění dopadu. Díky tomu jsou tyto nástroje opravdu skvělým doplňkem arzenálu DBA při práci s replikací MySQL.
Změny postupného schématu
DBA obvykle použije jeden z online nástrojů pro změnu schématu. Ale jak jsme diskutovali dříve, za určitých okolností je nelze použít a přímá změna je jedinou schůdnou možností. Pokud mluvíme o samostatném MySQL, nemáte na výběr – pokud je změna neblokující, je to dobré. Pokud tomu tak není, nedá se s tím nic dělat. Ale pak, ne tolik lidí provozuje MySQL jako jednotlivé instance, že? Co takhle replikace? Jak jsme diskutovali dříve, přímá změna na masteru není možná - ve většině případů to způsobí zpoždění na slave a to nemusí být přijatelné. Co však lze udělat, je provést změnu postupně. Můžete začít s otroky a jakmile je změna aplikována na všechny, povýšit jednoho z nich na nového pána, degradovat starého pána na otroka a provést na něm změnu. Jistě, změna musí být kompatibilní, ale popravdě řečeno, nejčastější případy, kdy nemůžete použít změny online schématu, je kvůli nedostatku primárního nebo jedinečného klíče. Pro všechny ostatní případy existuje nějaké řešení, zejména v pt-online-schema-change, protože gh-ost má přísnější omezení. Je to řešení, které byste nazvali „tak to“ nebo „daleko od ideálu“, ale bude fungovat, pokud nemáte jinou možnost na výběr. Co je také důležité, většině omezení se lze vyhnout, pokud budete sledovat své schéma a zachytit problémy dříve, než se tabulka rozroste. I když někdo vytvoří tabulku bez primárního klíče, není problém spustit přímý alter, který trvá půl sekundy nebo méně, protože tabulka je téměř prázdná.
Pokud bude růst, stane se to vážným problémem, ale je na DBA, aby tento druh problémů zachytil dříve, než začnou skutečně vytvářet problémy. Probereme několik tipů a triků, jak zajistit, že takové problémy zachytíte včas. Budeme také sdílet obecné tipy, jak navrhnout schémata.
Tipy a triky
Návrh schématu
Jak jsme ukázali v tomto příspěvku, online nástroje pro změnu schématu jsou při práci s nastavením replikace docela důležité, a proto je docela důležité zajistit, aby vaše schéma bylo navrženo tak, aby neomezovalo vaše možnosti provádění změn schématu. Jsou zde tři důležité aspekty. Nejprve musí existovat primární nebo jedinečný klíč – musíte se ujistit, že ve vaší databázi nejsou žádné tabulky bez primárního klíče. Měli byste to pravidelně sledovat, jinak se to může v budoucnu stát vážným problémem. Za druhé, měli byste vážně zvážit, zda je použití cizích klíčů dobrý nápad. Jistě, mají své využití, ale také zvyšují režii vaší databáze a mohou zkomplikovat používání online nástrojů pro změnu schématu. Vztahy lze vynutit aplikací. I když to znamená více práce, stále to může být lepší nápad, než začít používat cizí klíče a být přísně omezeni na typy změn schématu, které lze provést. Za třetí, spouštěče. Stejný příběh jako s cizími klíči. Jsou příjemnou funkcí, ale mohou se stát zátěží. Musíte vážně zvážit, zda zisky z jejich používání převažují nad omezeními, která představují.
Sledování změn schématu
Správa změn schématu není pouze o provádění změn schématu. Musíte také zůstat na vrcholu své struktury schématu, zvláště pokud nejste jediný, kdo provádí změny.
ClusterControl poskytuje uživatelům nástroje pro sledování některých nejběžnějších problémů s návrhem schémat. Může vám pomoci sledovat tabulky, které nemají primární klíče:
Jak jsme diskutovali dříve, včasné zachycení těchto tabulek je velmi důležité, protože primární klíče je třeba přidat pomocí přímé změny.
ClusterControl vám také může pomoci sledovat duplicitní indexy. Obvykle nechcete mít více indexů, které jsou nadbytečné. Ve výše uvedeném příkladu můžete vidět, že existuje index na (k, c) a je zde také index na (k). Jakýkoli dotaz, který může používat index vytvořený ve sloupci „k“, může také používat složený index vytvořený ve sloupcích (k, c). Existují případy, kdy je výhodné ponechat redundantní indexy, ale musíte k tomu přistupovat případ od případu. Počínaje MySQL 8.0 je možné rychle otestovat, zda je index skutečně potřeba nebo ne. Redundantní index můžete učinit „neviditelným“ spuštěním:
ALTER TABLE sbtest.sbtest1 ALTER INDEX k_1 INVISIBLE;To způsobí, že MySQL bude tento index ignorovat a prostřednictvím monitorování můžete zkontrolovat, zda nedošlo k nějakému negativnímu dopadu na výkon databáze. Pokud vše po nějakou dobu (několik dní nebo dokonce týdnů) funguje podle plánu, můžete naplánovat odstranění nadbytečného indexu. V případě, že zjistíte, že něco není v pořádku, můžete tento index kdykoli znovu povolit spuštěním:
ALTER TABLE sbtest.sbtest1 ALTER INDEX k_1 VISIBLE;Tyto operace jsou okamžité a index je tam po celou dobu a je stále udržován - pouze to nebude brát v úvahu optimalizátor. Díky této možnosti bude odstranění indexů v MySQL 8.0 mnohem bezpečnější operací. V předchozích verzích mohlo opětovné přidání nesprávně odstraněného indexu u velkých tabulek trvat hodiny, ne-li dny.
ClusterControl vás také může informovat o tabulkách MyISAM.
I když MyISAM stále může mít své využití, musíte mít na paměti, že se nejedná o transakční úložiště. Jako takový může snadno zavést nekonzistenci dat mezi uzly v nastavení replikace.
Další velmi užitečnou funkcí ClusterControl je jeden z provozních reportů – Schema Change Report.
V ideálním světě DBA kontroluje, schvaluje a implementuje všechny změny schématu. Bohužel ne vždy tomu tak je. Takový proces kontroly prostě nejde dobře s agilním vývojem. Kromě toho je poměr vývojářů k DBA obvykle poměrně vysoký, což může být také problém, protože DBA by se snažily nestát úzkým hrdlem. To je důvod, proč není neobvyklé vidět změny schématu prováděné mimo znalosti DBA. DBA je však obvykle odpovědný za výkon a stabilitu databáze. Díky zprávě o změnách schématu mohou nyní sledovat změny schématu.
Nejprve je potřeba nějaká konfigurace. V konfiguračním souboru pro daný cluster (/etc/cmon.d/cmon_X.cnf) musíte definovat, na kterém hostiteli má ClusterControl sledovat změny a která schémata by měla být kontrolována.
schema_change_detection_address=10.0.0.126
schema_change_detection_databases=sbtestJakmile to uděláte, můžete naplánovat pravidelné provádění sestavy. Příklad výstupu může být následující:
Jak vidíte, od předchozího spuštění přehledu se změnily dvě tabulky. V prvním z nich byl vytvořen nový složený index na sloupcích (k, c). Do druhé tabulky byl přidán sloupec.
V následném běhu jsme získali informaci o nové tabulce, která byla vytvořena bez indexu nebo primárního klíče. Pomocí tohoto druhu informací můžeme snadno jednat, když je to potřeba, a vyřešit problémy dříve, než se z nich skutečně začnou stát blokátory.