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

  • Článek
  • 6 min ke čtení

platí pro: Azure Database for MySQL – jeden server Azure Database for MySQL – flexibilní Server

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

Konfigurace prostředků aplikace a databáze

Udržujte aplikaci a databázi ve stejné oblasti.

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

Zabezpečení serveru MySQL

Nakonfigurujte server MySQL tak, aby byl zabezpečený a nebyl veřejně pří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 aplikaci tak, aby protokol TLS 1.2. Viz Konfigurace SSL/TLS.

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

Když se na virtuálním počítači povolí akcelerované síťové služby, dojde 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 úlohy náročné na čtení vyladění parametrů serveru a tmp_table_size může pomoct optimalizovat pro lepší max_heap_table_size výkon. Pokud chcete vypočítat hodnoty požadované pro tyto proměnné, podívejte se na celkové hodnoty paměti pro připojení a základní paměť. Součet parametrů paměti pro připojení s výjimkou v kombinaci se základními účty paměti tmp_table_size pro celkovou paměť serveru.

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

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

Poznámka

Celková paměť udává celkovou velikost paměti, kterou má server napříč zřk funkcemi vCores. Například v případě virtuálního Pro obecné účely se dvěma virtuálními Azure Database for MySQL bude celková paměť 5 GB * 2. Další podrobnosti o paměti pro jednotlivé úrovně najdete v dokumentaci k cenové úrovni.

Základní paměť označuje proměnné paměti, jako jsou a , které MySQL inicializuje a query_cache_size innodb_buffer_pool_size přidělí při spuštění serveru. Paměť pro připojení, jako je a , je paměť, která se přiděluje sort_buffer_size join_buffer_size pouze v případě, že ji dotaz potřebuje.

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

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

Resetování hesla

Heslo k serveru MySQL můžete resetovat pomocí Azure Portal.

Resetování hesla serveru pro produkční databázi může vaši aplikaci zrušovat. 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é můžete použít k ladění problémů s výkonem vaší aplikace.

Povolení protokolů pomalých dotazů za účelem identifikace 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 Azure Diagnostics protokolů v Azure Monitor, Azure Event Hubs a účtech úložiště. Viz Řešení potíží s výkonem dotazů.

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

Správa databázových připojení může mít významný dopad na výkon aplikace jako celku. Pokud chcete optimalizovat výkon, musíte snížit počet navazování připojení a čas navazování připojení v klíčových cestách kódu. Pomocí sdružování připojení se připojte Azure Database for MySQL ke zvýšení odolnosti a výkonu.

Nástroj pro sdružování připojení ProxySQL můžete použít k efektivní správě připojení. Použití nástroje pro sdružování připojení může snížit počet nečinných připojení a opakovaně používat stávající připojení, což pomůže zabránit problémům. Další informace najdete v tématu Nastavení ProxySQL.

Logika opakování pro zpracování přechodných chyb

Ve vaší aplikaci můžou docházet k přechodným chybám, kdy se připojení k databázi přerušovaně 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 5 sekund před prvním opakováním. Potom sledujte každý pokus tak, že postupně zvýšíte čekání až na 60 sekund. Omezte maximální počet opakování, kdy 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í za účelem zmírnění převzetí služeb při selhání

Pro scénáře převzetí služeb při Replikace vstupních dat můžete použít následující možnosti. Pokud používáte repliky pro čtení, mezi zdrojovým a replikačním serverem nenástane žádné automatické převzetí služeb při selhání.

Všimněte si prodlevy mezi zdrojem a replikou, protože replikace je asynchronní. Na prodlevu sítě může mít vliv řada faktorů, například velikost úlohy běžící na zdrojovém serveru a latence mezi datacentra. Ve většině případů se prodleva repliky pohybuje od několika sekund až 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 pomocí úlohy pro server MySQL aktualizovat databázi spuštěním vlastního skriptu.

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

Během ručního nasazení databáze postupujte podle těchto kroků, abyste minimalizovali prostoje nebo snížili riziko selhání nasazení:

  1. Vytvořte kopii produkční databáze v nové databázi pomocí nástroje mysqldump nebo MySQL Workbench.
  2. Aktualizujte novou databázi novými změnami nebo aktualizacemi schématu, které jsou potřeba pro vaši databázi.
  3. Produkční databázi umístěte do stavu jen pro čtení. Dokud se nasazení nedokončí, neměli byste mít v produkční databázi operace zápisu.
  4. Otestujte aplikaci s nově aktualizovanou databází z kroku 1.
  5. Nasaďte změny aplikace a ujistěte se, že teď aplikace používá novou databázi s nejnovějšími aktualizacemi.
  6. Starou produkční databázi si nechte, abyste mohli vrátit změny zpět. Pak můžete vyhodnotit, jestli chcete odstranit starou produkční databázi, nebo ji v případě potřeby Azure Storage exportovat.

Poznámka

Pokud je aplikace podobná aplikaci pro elektronické 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 vytvoření zálohy. Tyto změny by se měly vyskytnout 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 vaší aplikace zpracovává také všechny neúspěšné požadavky.

Pomocí nativních metrik MySQL můžete zobrazit, jestli vaše úloha nepřekračuje velikost dočasné tabulky v paměti.

Při zatížení náročném na čtení můžou dotazy spuštěné na vašem serveru MySQL překročit velikost dočasných tabulek v paměti. Úloha náročná na čtení může způsobit, že váš server přepne na zápis dočasných tabulek na disk, což má vliv na výkon vaší aplikace. Pokud chcete zjistit, jestli váš server zapisuje na disk v důsledku překročení dočasné velikosti tabulky, prohlédněte si následující metriky:

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

Metrika created_tmp_disk_tables udává, kolik tabulek se na disku vytvořilo. Metrika vám říká, kolik dočasných tabulek musí být vzhledem k created_tmp_table vaší úlohu vytvořeno v paměti. Pokud chcete zjistit, jestli spuštění konkrétního dotazu bude používat dočasné tabulky, spusťte v dotazu příkaz EXPLAIN. Podrobnosti ve sloupci extra indikuje, Using temporary jestli se dotaz spustí pomocí dočasných tabulek.

Pokud chcete vypočítat procento úloh s dotazy přelití na disky, použijte hodnoty metriky 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 vidíte, že procento je 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ů, na které byste měli při vytváření schématu databáze a dotazů mít na paměti.

Použití správných datových typů pro sloupce tabulky

Použitím správných datových typů založených na typu dat, která chcete uložit, můžete optimalizovat úložiště a omezit chyby, ke kterým může dojít kvůli nesprávným datovým typům.

Použití indexů

Pokud se chcete vyhnout pomalým dotazům, můžete použít indexy. Indexy můžou pomoct rychle najít řádky s konkrétními sloupci. Viz Použití indexů v MySQL.

Vysvětlete pro vaše dotazy SELECT.

Pomocí EXPLAIN příkazu můžete získat přehled o tom, co MySQL dělá ke spuštění dotazu. Může vám to usnadnit detekci kritických bodů nebo problémů s vaším dotazem. Podívejte se, jak používat vysvětlení k profilování výkonu dotazů.