Osvědčené postupy pro optimální výkon flexibilního serveru Azure Database for MySQL
Zjistěte, jak dosáhnout nejlepšího výkonu při práci s flexibilním serverem Azure Database for MySQL. S tím, jak do platformy přidáváme nové funkce, budeme v této části dál upřesňovat naše doporučení.
Fyzická bezkontaktní komunikace
Ujistěte se, že nasazujete aplikaci a databázi ve stejné oblasti. Rychlá kontrola před zahájením jakéhokoli srovnávacího testu výkonu spočívá v určení latence sítě mezi klientem a databází pomocí jednoduchého dotazu SELECT 1.
Pokud jsou prostředky, jako je webová aplikace a přidružená databáze spuštěná v různých oblastech, může dojít ke zvýšení latence komunikace mezi těmito prostředky. Dalším vedlejším možným účinkem, který může mít aplikace a databáze v samostatných oblastech, souvisí s náklady na odchozí přenos dat.
Pokud chcete zvýšit výkon a spolehlivost aplikace v nasazení optimalizovaném podle nákladů, důrazně doporučujeme, aby se služba webových aplikací a prostředek flexibilního serveru Azure Database for MySQL nacházejí ve stejné oblasti a zóně dostupnosti. Tato kolokace je nejvhodnější pro aplikace citlivé na latenci a poskytuje také nejlepší propustnost, protože prostředky jsou úzce spárované.
Akcelerované síťové služby
Pokud používáte virtuální počítač Azure, Azure Kubernetes nebo App Services, použijte pro aplikační server akcelerované síťové služby. Akcelerované síťové služby umožňují virtuálnímu počítači virtualizaci rozhraní SR-IOV (Single Root I/O Virtualization), což výrazně zlepšuje výkon sítě. Tato cesta s vysokým výkonem obchází hostitele z cesty k datům, snižuje latenci, zpoždění a využití procesoru pro použití s nejnáročnějšími síťovými úlohami na podporovaných typech virtuálních počítačů.
Efektivita připojení
Vytvoření nového připojení je vždy nákladná a časově náročná úloha. Když aplikace požádá o připojení k databázi, upřednostňuje přidělení stávajících nečinných databázových připojení místo vytvoření nového připojení. Tady jsou některé možnosti osvědčených postupů připojení:
ProxySQL: Použijte ProxySQL, který poskytuje integrované sdružování připojení a vyrovnává zatížení úloh na několik replik pro čtení podle potřeby s případnými změnami v kódu aplikace.
Heimdall Data Proxy: Alternativně můžete také použít Heimdall Data Proxy, dodavatele-neutrální proprietární proxy řešení. Podporuje ukládání dotazů do mezipaměti a rozdělení čtení a zápisu s detekcí prodlevy replikace. Můžete se také podívat, jak zrychlit výkon MySQL pomocí proxy serveru Heimdall.
Trvalé nebo dlouhodobé připojení: Pokud má vaše aplikace krátké transakce nebo dotazy obvykle s dobou < provádění 5–10 ms, pak nahraďte krátká připojení trvalými připojeními. Nahrazení krátkých připojení trvalými připojeními vyžaduje pouze menší změny kódu, ale má velký vliv na zlepšení výkonu v mnoha typických scénářích aplikace. Po dokončení transakce nezapomeňte nastavit časový limit nebo zavřít připojení.
Replika: Pokud používáte repliku, použijte ProxySQL k vyrovnávání zatížení mezi primárním serverem a serverem sekundární repliky, který je čitelný. Zjistěte , jak nastavit ProxySQL.
Sdružování připojení
Sdružování připojení je mechanismus, který spravuje vytváření a přidělování databázových připojení a chrání databázi před nárůsty připojení. Zvažte sdružování připojení, pokud vaše aplikace otevře mnoho připojení v relativně krátkém čase a připojení jsou krátkodobá. K těmto typům připojení může dojít například v rozsahu stovek nebo tisíců za sekundu a doba potřebnou k jejich vytvoření a uzavření je v porovnání s celkovou životností připojení významná.
Pokud vývojová architektura vaší aplikace nepodporuje sdružování připojení, použijte místo toho proxy připojení, jako je ProxySQL nebo Heimdall proxy, mezi aplikací a databázovým serverem.
Zpracování škálování připojení
Běžným přístupem pro škálování webových aplikací tak, aby splňovaly proměnlivou poptávku, je přidat a odebrat aplikační servery. Každý aplikační server může používat fond připojení s databází. Tento přístup způsobí, že se celkový počet připojení na databázovém serveru zvýší vzhledem k počtu aplikačních serverů. Pokud má například databázový server 10 aplikačních serverů a každý je nakonfigurovaný pro 100 databázových připojení, které by poskytovalo 1 000 databázových připojení. Pokud se zatížení aplikace škáluje z důvodu vyšší aktivity uživatelů nebo během špičky a pokud se přidá dalších 50 aplikačních serverů, budou připojení k databázi celkem 6 000. Většina těchto připojení bude obvykle nečinná po spuštění aplikačními servery. Vzhledem k tomu, že nečinná připojení spotřebovávají prostředky (paměť a procesor), aby zůstala otevřená, může to mít vliv na škálovatelnost databáze.
Mezi další potenciální problémy patří zpracování celkového počtu připojení k databázovému serveru. To určuje počet aplikačních serverů připojených k databázovému serveru a každý vytváří vlastní sadu připojení. V těchto scénářích zvažte úpravu fondů připojení na aplikačních serverech. Pokuste se snížit počet připojení v jednotlivých fondech na přijatelné minimum, abyste zajistili, že na straně databázového serveru nejsou žádné blouchy. Zvažte to jako krátkodobé nápravy, abyste čítači účinků škálování aplikačního serveru místo trvalého řešení vyřešili růst aplikace.
Jako dlouhodobé řešení mezi databázovým serverem a aplikačním serverem zavést proxy připojení, jako je ProxySQL nebo Heimdall. To pomáhá, protože proxy bude:
- Vytvořte připojení k databázovému serveru s pevným počtem připojení.
- Přijměte připojení aplikací a chovejte se jako vyrovnávací paměť pro potenciální bouře připojení.
Proxy servery můžou poskytovat další funkce, jako je ukládání dotazů do mezipaměti, ukládání do vyrovnávací paměti připojení, přepisování dotazů nebo směrování a vyrovnávání zatížení. Pokud chcete ještě větší škálovatelnost, zvažte použití více instancí proxy serveru.
Zpracování připojení pro odolnost proti chybám a rychlejší obnovení
Při navrhování aplikací a prostředí pro odolnost proti chybám a rychlejší obnovení zvažte, že v databázovém prostředí pravděpodobně dojde k přerušení připojení nebo selhání hardwaru. Nezapomeňte také, že potřebujete provozní akce, jako je škálování velikostí instancí, opravy a ruční převzetí služeb při selhání.
Představte si například scénář, ve kterém databázový server dokončí převzetí služeb při selhání během jedné minuty, ale vaše aplikace je po dobu několika minut mimo provoz kvůli tomu, že hodnota TTL DNS je příliš dlouhá na straně aplikace. V těchto případech stačí jednoduše snížit hodnotu TTL, která zajistí rychlejší obnovení nebo integraci proxy připojení mezi aplikací a databázovým serverem může pomoct tyto chyby zvládnout.
Oddíl
Když vaše produkční úlohy používají extrémně velké tabulky, je dělení skvělou metodou pro zlepšení výkonu databáze a snadné údržby. Dělení usnadňuje správu velkých tabulek. Tento přístup umožňuje efektivně přidávat a odstraňovat oddíly pro správu velkých tabulek. Dělení může také pomoct škálovat modul tím, že zvětší kolize interní struktury, jako jsou vnitřní zámky na tabulku nebo index (např. zvažte btr_search_latch v InnoDB).
Přidáním pěti oddílů například v podstatě rozdělíte velkou tabulku s velkou aktivitou na pět menších, efektivnějších tabulek. To by primárně pomohlo v případech, kdy je hlavní operace vyhledáváním primárního klíče v tabulce, aby dotazy mohly využít "vyřezávání oddílů". Dělení ale může pomoct také z hlediska prohledávání tabulek.
Zatímco dělení má své výhody, má také určitá omezení, jako je nedostatek podpory cizích klíčů v dělených tabulkách, nedostatek mezipaměti dotazů atd. Úplný seznam těchto omezení najdete v referenční příručce k MySQL v kapitole Omezení a omezení dělení.
Oddělení čtení a zápisů
Většinaaplikacích Početaktivních Snižování zátěže co nejvíce dotazů na repliky pro čtení a úspora přístupu k primární zapisovatelné instanci zvyšuje množství celkové databázové aktivity prováděné aplikačními servery, aniž by se zvýšilo zatížení primární databáze. Pokud ještě nemáte přístup k replikám pro čtení alespoň u delších spuštěných dotazů, jako jsou sestavy, měli byste zvážit okamžité přesun sestavy nebo analýzy na repliky pro čtení.
Širší využití replik pro čtení může vyžadovat pečlivější zvážení, protože repliky se mírně za sebou zpožďují kvůli asynchronní povaze replikace. Najděte co nejvíce oblastí aplikace, které je možné obsluhovat se čtením z replik s menšími změnami kódu. Tuto metodu byste také měli použít na vyšších úrovních, pokud jde o ukládání do mezipaměti – slouží více obsahu jen pro čtení nebo pomalu se mění z vyhrazené úrovně ukládání do mezipaměti, jako je Azure Cache for Redis.
Zápis škálování a horizontálního dělení
V průběhu času se aplikace vyvíjejí a přidávají se nové funkce. Z pohodlí nebo obecné praxe se tabulky přidají do primární databáze. Pokud chcete zpracovávat rostoucí zatížení provozu v databázi, identifikujte oblasti aplikace, které je možné snadno přesunout do samostatných databází, a zvažte horizontální horizontální dělení nebo vertikální rozdělení databáze.
Horizontální horizontální dělení databáze funguje vytvořením více kopií schématu aplikace v samostatných databázích a oddělením zákazníků a všech přidružených dat na základě ID zákazníka, zeměpisné oblasti nebo jiného atributu pro jednotlivé zákazníky nebo tenanta. To funguje velmi dobře pro aplikace SaaS nebo B2C, ve kterých jsou jednotliví zákazníci malé a zatížení aplikace je z agregovaného využití milionů zákazníků. U aplikací B2B je ale obtížnější, když zákazníci mají různé velikosti a jednotliví velké zákazníky můžou dominovat zatížení provozu pro konkrétní horizontální oddíl.
Vertikální rozdělení zatížení funkčně horizontálním dělením databáze – přesunem samostatných domén aplikací (nebo mikroslužeb) do vlastních databází. Tím se distribuuje zatížení z primární databáze do samostatných databází pro jednotlivé služby. Mezi jednoduché příklady patří tabulka protokolování nebo informace o konfiguraci lokality, které nemusí být ve stejné databázi jako tabulka s silně načtenými objednávkami. Složitější příklady zahrnují přerušení domén zákazníků a účtů kromě objednávek nebo domén plnění. V některýchpřípadechch Přesunutí existujících tabulek a dat do nové primární databáze se dá provést pomocí replik pro čtení flexibilního serveru Azure Database for MySQL a zvýšení úrovně repliky a odkazování částí aplikace na nově vytvořenou zapisovatelnou databázi. Nově vytvořená databáze musí omezit přístup pomocí fondů připojení, ladit dotazy a rozložit zatížení s vlastními replikami stejně jako původní primární databáze.
Konfigurace importu dat
- Před zahájením operace importu dat můžete dočasně škálovat instanci na vyšší velikost skladové položky a po úspěšném importu ji vertikálně snížit.
- Data můžete importovat s minimálními výpadky pomocí místní migrace Migrate MySQL do služby Azure Database for MySQL pro online nebo offline migrace.
Doporučení k paměti flexibilního serveru Azure Database for MySQL
Osvědčeným postupem výkonu flexibilního serveru Azure Database for MySQL je přidělit dostatek paměti RAM, aby se vaše pracovní sada nachází téměř zcela v paměti.
- Pomocí metrik flexibilního serveru Azure Database for MySQL zkontrolujte, jestli se procento paměti používá při dosažení limitů.
- Nastavte upozornění na taková čísla, abyste zajistili, že jakmile server dosáhne limitů, můžete provést akce výzvy k jeho opravě. Na základě definovaných limitů zkontrolujte, jestli vertikálně navyšujete skladovou položku databáze – buď na vyšší velikost výpočetních prostředků, nebo na vyšší cenovou úroveň, což vede k výraznému zvýšení výkonu.
- Vertikálně navyšte kapacitu, dokud se čísla výkonu po operaci škálování výrazně nezhorší. Informace o monitorování metrik instance databáze najdete v tématu Metriky databáze flexibilního serveru Azure Database for MySQL.
Použití fondu vyrovnávací paměti InnoDB – teplo
Po restartování instance flexibilního serveru Azure Database for MySQL se datové stránky umístěné v úložišti načtou, protože se na tyto tabulky dotazují, což vede ke zvýšení latence a pomalejšímu výkonu při prvním spuštění dotazů. To nemusí být přijatelné pro úlohy citlivé na latenci.
Použití zahřátí fondu vyrovnávací paměti InnoDB zkracuje dobu zahřátí opětovným načtením stránek disku, které byly ve fondu vyrovnávací paměti před restartováním, a nečeká na operace DML nebo SELECT pro přístup k odpovídajícím řádkům.
Dobu zahřátí můžete snížit po restartování instance flexibilního serveru Azure Database for MySQL, což představuje výhodu výkonu konfigurací parametrů serveru fondu vyrovnávací paměti InnoDB. InnoDB ukládá procento naposledy použitých stránek pro každý fond vyrovnávací paměti při vypnutí serveru a obnoví tyto stránky při spuštění serveru.
Je také důležité si uvědomit, že vyšší výkon přináší náklady na delší dobu spuštění serveru. Pokud je tento parametr povolený, očekává se, že se zvýší čas spuštění a restartování serveru v závislosti na počtu IOPS zřízených na serveru.
Doporučujeme otestovat a monitorovat dobu restartování, abyste měli jistotu, že je výkon při spuštění nebo restartování přijatelný, protože server během této doby není dostupný. Tento parametr se nedoporučuje používat s méně než 1 000 zřízenými IOPS (nebo jinými slovy, pokud je zřízené úložiště menší než 335 GB).
Chcete-li uložit stav fondu vyrovnávací paměti při vypnutí serveru, nastavte parametr innodb_buffer_pool_dump_at_shutdown serveru na ON. Podobně nastavte parametr innodb_buffer_pool_load_at_startup serveru tak, aby ON se při spuštění serveru obnovil stav fondu vyrovnávací paměti. Účinek na spuštění/restartování můžete řídit snížením a vyladěním hodnoty parametru innodb_buffer_pool_dump_pctserveru . Ve výchozím nastavení je tento parametr nastaven na 25.
Poznámka:
Parametry zahřátí fondu vyrovnávací paměti InnoDB jsou podporovány pouze na serverech úložiště pro obecné účely s až 16TB úložištěm. Další informace najdete v tématu Možnosti úložiště flexibilního serveru Azure Database for MySQL.