Osvědčené postupy pro vytváření aplikací s využitím služby Azure Database for MySQL

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for MySQL – Jednoúčelový server Azure Database for MySQL

Důležité

Jednoúčelový server Azure Database for MySQL je na cestě vyřazení. Důrazně doporučujeme upgradovat na flexibilní server Azure Database for MySQL. Další informace o migraci na flexibilní server Azure Database for MySQL najdete v tématu Co se děje s jednoúčelovým serverem Azure Database for MySQL?

Tady je několik osvědčených postupů, které vám pomůžou vytvořit aplikaci připravenou pro cloud pomocí Služby Azure Database for MySQL. Tyto osvědčené postupy můžou zkrátit dobu vývoje vaší aplikace.

Konfigurace aplikačních a databázových prostředků

Zachování aplikace a databáze ve stejné oblasti

Při nasazování aplikace v Azure se ujistěte, že jsou všechny vaše závislosti ve stejné oblasti. Šíření instancí napříč oblastmi nebo zónami dostupnosti vytváří latenci sítě, což může ovlivnit celkový výkon vaší aplikace.

Zajištění zabezpečení serveru MySQL

Nakonfigurujte server MySQL tak, aby byl zabezpečený a veřejně nepřístupný. K zabezpečení serveru použijte jednu z těchto možností:

Kvůli zabezpečení se musíte vždy připojit k serveru MySQL přes PROTOKOL SSL a nakonfigurovat server MySQL a vaši aplikaci tak, aby používaly protokol TLS 1.2. Přečtěte si , jak nakonfigurovat protokol SSL/TLS.

Použití pokročilých sítí s AKS

Pokud jsou na virtuálním počítači povolené akcelerované síťové služby, dochází k nižší latenci, snížení zpoždění a snížení využití procesoru na virtuálním počítači. Další informace najdete v tématu Osvědčené postupy pro Azure Kubernetes Service a Azure Database for MySQL.

Ladění parametrů serveru

Pro ladění parametrů tmp_table_size serveru náročných na čtení a max_heap_table_size může vám pomoct optimalizovat výkon. Pokud chcete vypočítat hodnoty požadované pro tyto proměnné, podívejte se na celkové hodnoty připojení a základní paměti. Součet parametrů paměti pro připojení, s výjimkou tmp_table_size, v kombinaci se základními účty paměti pro celkovou paměť serveru.

K výpočtu největší možné velikosti tmp_table_size a max_heap_table_sizepoužijte následující vzorec:

(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections

Poznámka:

Celková paměť označuje celkovou velikost paměti, kterou má server napříč zřízenými virtuálními jádry. Například na serveru Azure Database for MySQL pro obecné účely bude celková paměť 5 GB × 2. Další podrobnosti o paměti pro každou úroveň najdete v dokumentaci k cenové úrovni .

Základní paměť označuje proměnné paměti, například query_cache_size a innodb_buffer_pool_size, že MySQL inicializuje a přidělí na začátku serveru. Paměť pro připojení, například sort_buffer_size a join_buffer_size, je paměť přidělena pouze v případě, že dotaz potřebuje.

Vytváření uživatelů bez oprávnění správce

Vytvořte uživatele bez oprávnění správce pro každou databázi. Uživatelská jména se obvykle označují jako názvy databází.

Resetování hesla

Heslo pro server MySQL můžete resetovat pomocí webu Azure Portal.

Resetováním hesla serveru pro produkční databázi můžete aplikaci snížit. Je vhodné resetovat heslo pro všechny produkční úlohy mimo špičku, abyste minimalizovali dopad na uživatele vaší aplikace.

Výkon a odolnost

Tady je několik nástrojů a postupů, které vám pomůžou ladit problémy s výkonem vaší aplikace.

Povolení protokolů pomalých dotazů k identifikaci problémů s výkonem

Protokoly pomalých dotazů a protokoly auditu můžete povolit na serveru. Analýza protokolů pomalých dotazů může pomoct identifikovat kritické body výkonu při řešení potíží.

Protokoly auditu jsou také dostupné prostřednictvím protokolů diagnostiky Azure v protokolech služby Azure Monitor, ve službě Azure Event Hubs a účtech úložiště. Podívejte se, jak řešit problémy s výkonem dotazů.

Použití sdružování připojení

Správa databázových připojení může mít významný vliv na výkon aplikace jako celku. Pokud chcete optimalizovat výkon, musíte snížit počet připojení a čas pro navázání připojení v klíčových cestách kódu. Pomocí sdružování připojení se připojte ke službě Azure Database for MySQL, abyste zlepšili odolnost a výkon.

K efektivní správě připojení můžete použít nástroj pro sdružování připojení ProxySQL . Použití nástroje pro sdružování připojení může snížit nečinná připojení a znovu použít existující připojení, což pomáhá vyhnout se problémům. Další informace najdete v tématu Jak nastavit ProxySQL .

Logika opakování pro ošetření přechodných chyb

U vaší aplikace může docházet k přechodným chybám , kdy se přerušovaně zahodí nebo ztratí připojení k databázi. V takových situacích je server spuštěný po jednom až dvou opakováních za 5 až 10 sekund.

Osvědčeným postupem je počkat před prvním opakováním 5 sekund. Potom postupujte podle jednotlivých opakování postupným zvýšením čekání až o 60 sekund. Omezte maximální počet opakovaných pokusů, ve kterých vaše aplikace považuje operaci za neúspěšnou, abyste ji mohli dále prozkoumat. Další informace najdete v tématu Řešení chyb připojení.

Povolení replikace pro čtení pro zmírnění převzetí služeb při selhání

Ve scénářích převzetí služeb při selhání můžete použít replikaci příchozích dat. Při použití replik pro čtení nedojde k žádnému automatizovanému převzetí služeb při selhání mezi zdrojovými servery a servery replik.

Všimněte si prodlevy mezi zdrojem a replikou, protože replikace je asynchronní. Prodleva sítě může být ovlivněna mnoha faktory, jako je velikost úlohy spuštěné na zdrojovém serveru a latence mezi datovými centry. Ve většině případů se prodleva repliky pohybuje od několika sekund po několik minut.

Nasazení databáze

Konfigurace úlohy Azure Database for MySQL v kanálu nasazení CI/CD

Občas je potřeba nasadit změny do databáze. V takových případech můžete použít kontinuální integraci (CI) a průběžné doručování (CD) prostřednictvím služby Azure Pipelines a použít úlohu pro server MySQL k aktualizaci databáze spuštěním vlastního skriptu.

Použití efektivního procesu pro ruční nasazení databáze

Během ručního nasazení databáze minimalizujte výpadky nebo snižte riziko neúspěšného nasazení:

  1. Vytvořte kopii produkční databáze v nové databázi pomocí aplikace mysqldump nebo MySQL Workbench.
  2. Aktualizujte novou databázi o nové změny schématu nebo aktualizace potřebné pro vaši databázi.
  3. Umístěte produkční databázi do stavu jen pro čtení. Nejlepší by bylo, kdybyste neměli operace zápisu do produkční databáze, dokud se nasazení nedokončí.
  4. Otestujte aplikaci pomocí nově aktualizované databáze z kroku 1.
  5. Nasaďte změny aplikace a ujistěte se, že aplikace teď používá novou databázi s nejnovějšími aktualizacemi.
  6. Ponechte starou produkční databázi, aby se změny vrátily zpět. Potom můžete vyhodnotit, jestli chcete odstranit starou produkční databázi, nebo ji v případě potřeby exportovat do služby Azure Storage.

Poznámka:

Pokud se aplikace podobá aplikaci elektronického obchodování a nemůžete ji umístit do stavu jen pro čtení, nasaďte změny přímo do produkční databáze po provedení zálohy. Tyto změny by se měly vyskytnout v době mimo špičku s nízkým provozem do aplikace, aby se minimalizoval dopad, protože někteří uživatelé můžou zaznamenat neúspěšné požadavky.

Ujistěte se, že kód aplikace zpracovává také všechny neúspěšné požadavky.

Pomocí nativních metrik MySQL zjistěte, jestli vaše úloha překračuje dočasné velikosti tabulek v paměti.

U úlohy náročné na čtení můžou dotazy na váš server MySQL překročit dočasné velikosti tabulek v paměti. Úloha náročné na čtení může způsobit, že server přepne na zápis dočasných tabulek na disk, což má vliv na výkon vaší aplikace. Pokud chcete zjistit, jestli server zapisuje na disk v důsledku překročení dočasné velikosti tabulky, podívejte se na následující metriky:

show global status like 'created_tmp_disk_tables';
show global status like 'created_tmp_tables';

Metrika created_tmp_disk_tables označuje, kolik tabulek bylo vytvořeno na disku. Vzhledem k úloze vám metrika říká, created_tmp_table kolik dočasných tabulek se musí vytvořit v paměti. Pokud chcete zjistit, jestli konkrétní dotaz používá dočasné tabulky, spusťte na dotazu příkaz EXPLAIN . Podrobnosti ve extra sloupci označují Using temporary , jestli se dotaz spouští pomocí dočasných tabulek.

Pokud chcete vypočítat procento úlohy s dotazy přetékajícími na disky, použijte hodnoty metrik v následujícím vzorci:

(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100

V ideálním případě by toto procento mělo být menší než 25 %. Pokud je procento 25 % nebo vyšší, doporučujeme upravit dva parametry serveru, tmp_table_size a max_heap_table_size.

Schéma databáze a dotazy

Tady je několik tipů, které byste si při vytváření schématu databáze a dotazů pamatovat.

Použití správného datového typu pro sloupce tabulky

Použití správného datového typu založeného na typu dat, která chcete uložit, může optimalizovat úložiště a omezit chyby způsobené nesprávnými datovými typy.

Použití indexů

Abyste se vyhnuli pomalým dotazům, můžete použít indexy. Indexy můžou pomoct rychle najít řádky s konkrétními sloupci. Podívejte se, jak používat indexy v MySQL.

Použití funkce EXPLAIN pro dotazy SELECT

Pomocí příkazu EXPLAIN získáte přehled o tom, co MySQL dělá pro spuštění dotazu. Může vám pomoct při zjišťování kritických bodů nebo problémů s dotazem. Viz Postup použití funkce EXPLAIN k profilování výkonu dotazů.