Osvědčené postupy pro provoz serverů na flexibilním serveru Azure Database for MySQL
Seznamte se s osvědčenými postupy pro práci s flexibilním serverem Azure Database for MySQL. S tím, jak do platformy přidáváme nové funkce, se budeme dále soustředit na upřesnění osvědčených postupů popsaných v této části.
Provozní pokyny pro flexibilní server Azure Database for MySQL
Následují provozní pokyny, které byste měli dodržovat při práci s flexibilním serverem Azure Database for MySQL, aby se zlepšil výkon vaší databáze:
Společné umístění: Pokud chcete snížit latenci sítě, umístěte klienta a databázový server do stejné oblasti Azure.
Monitorování využití paměti, procesoru a úložiště: Můžete nastavit upozornění , která vás upozorní, když se změní vzory využití nebo když přiblížíte kapacitu nasazení, abyste mohli udržovat výkon a dostupnost systému.
Akcelerované protokoly pro vylepšený výkon: Povolení akcelerovaných protokolů optimalizuje operace související s transakčními protokoly, zvyšuje propustnost serveru a výkon. Tato funkce, která je k dispozici bez dalších poplatků, je významným doplňkem provozních osvědčených postupů pro uživatele úrovně služby Pro důležité obchodní informace.
Vertikální navýšení kapacity instance databáze: Vertikální navýšení kapacity můžete vertikálně navýšit , když se blížíte limitům kapacity úložiště. Měli byste mít určitou vyrovnávací paměť v úložišti a paměti, aby vyhovovala nepředvídanému nárůstu poptávky od vašich aplikací. Můžete také povolit funkci automatického zvětšování úložiště "ZAPNUTO", abyste zajistili, že služba automaticky škáluje úložiště, protože se blíží limitům úložiště.
Konfigurace záloh: Povolte místní nebo geograficky redundantní zálohy na základě požadavku firmy. Také upravíte dobu uchovávání informací o tom, jak dlouho jsou zálohy k dispozici pro provozní kontinuitu.
Optimalizace vstupně-výstupní kapacity s využitím IOPS automatického škálování: Pokud vaše úloha databáze vyžaduje více vstupně-výstupních operací, než je zřízeno, obnovení nebo jiné transakční operace pro vaši databázi budou pomalé. Pokud chcete zvýšit kapacitu vstupně-výstupních operací instance serveru, proveďte některou z následujících věcí:
Použití IOPS automatického škálování: Automatické škálování IOPS eliminuje nutnost předběžného zřízení konkrétního počtu vstupně-výstupních operací za sekundu. Místo toho umožňuje serveru automaticky upravit IOPS na základě požadavků na úlohy1. To znamená, že váš server může vertikálně navýšit nebo snížit kapacitu IOPS automaticky v závislosti na potřebách úloh.
Flexibilní server Azure Database for MySQL poskytuje škálování IOPS rychlostí tří IOPS na zřízené úložiště v GB. Zvyšte zřízené úložiště , abyste škálovali IOPS, aby se zlepšil výkon.
Pokud už používáte zřízené úložiště IOPS, zřiďte další kapacitu propustnosti.
Škálování výpočetních prostředků: Databázové úlohy můžou být také omezené z důvodu procesoru nebo paměti a to může mít závažný dopad na zpracování transakcí. Výpočetní prostředky (cenová úroveň) je možné vertikálně navýšit nebo snížit mezi úrovněmi Pro obecné účely nebo Optimalizováno pro paměť.
Test převzetí služeb při selhání: Ruční testování převzetí služeb při selhání instance serveru, abyste pochopili, jak dlouho proces trvá pro váš případ použití, a zajistěte, aby se aplikace, která přistupuje k vaší instanci serveru, po převzetí služeb při selhání automaticky připojila k nové instanci serveru.
Použití primárního klíče: Ujistěte se, že vaše tabulky mají primární nebo jedinečný klíč při práci s instancí flexibilního serveru Azure Database for MySQL. To pomáhá při mnoha zálohováních, replikách atd. a zvyšuje výkon.
Nakonfigurujte hodnotu TTL: Pokud vaše klientská aplikace do mezipaměti ukládají data DNS (Domain Name Service) instancí serveru, nastavte hodnotu TTL (Time to Live) kratší než 30 sekund. Vzhledem k tomu, že se základní IP adresa instance serveru může po převzetí služeb při selhání změnit, může ukládání dat DNS do mezipaměti po delší dobu vést k selháním připojení, pokud se vaše aplikace pokusí připojit k IP adrese, která už není ve službě.
Pomocí sdružování připojení se vyhněte dosažení maximálních limitůpřipojení a použijte logiku opakování, abyste se vyhnuli přerušovaným problémům s připojením.
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ý. Postup nastavení najdete tady.
Při zřizování prostředku se ujistěte, že jste pro instanci flexibilního serveru Azure Database for MySQL povolili automatické zvětšování . Nepřidá se žádné další náklady a chrání databázi před kritickými body úložiště, na které byste mohli narazit.
Použití InnoDB s flexibilním serverem Azure Database for MySQL
Pokud používáte
ibdata1
funkci, což je datový soubor systémového tabulkového prostoru, nelze zmenšit nebo ho vyprázdnit přetažením dat z tabulky nebo přesunutím tabulky do souboru na tabulkutablespaces
.Pro databázi větší než 1 TB byste měli vytvořit tabulku v innodb_file_per_table
tablespace
. Pro jednu tabulku, která je větší než 1 TB, byste měli tabulku oddílů .Pro server, který má velký počet
tablespace
, spuštění motoru je velmi pomalé kvůli sekvenční prohledávání tabulkového prostoru během spouštění nebo převzetí služeb při selhání flexibilního serveru Azure Database for MySQL.Před vytvořením tabulky nastavte innodb_file_per_table = ZAPNUTO, pokud je celkové číslo tabulky menší než 500.
Pokud máte v databázi více než 500 tabulek, zkontrolujte velikost tabulky pro každou jednotlivou tabulku. U velké tabulky byste stále měli zvážit použití tabulkového prostoru pro jednotlivé soubory, abyste se vyhnuli dosažení maximálního limitu úložiště v systémovém tabulkovém prostoru.
Poznámka:
U tabulek s velikostí menší než 5 GB zvažte použití systémového prostoru tabulek.
CREATE TABLE tbl_name ... *TABLESPACE* = *innodb_system*;
Rozdělte tabulku při vytváření tabulky, pokud máte velkou tabulku potenciálně větší než 1 TB.
Použijte několik instancí flexibilního serveru Azure Database for MySQL a rozprostřete tabulky mezi tyto servery. Pokud máte přibližně 10 000 tabulek nebo více, nepoužívejte příliš mnoho tabulek na jeden server.