Migrace místního MySQL do služby Azure Database for MySQL: Standardní hodnoty výkonu
Vytvoření standardních hodnot výkonu je nezbytné pro migraci databází MySQL z místních prostředí do Služby Azure Database for MySQL. Tento článek se zabývá důležitostí standardních hodnot výkonu a poskytuje podrobný průvodce měřením a analýzou aktuálního výkonu databáze. Když pochopíte stávající metriky výkonu, můžete během procesu migrace nastavit realistická očekávání a identifikovat oblasti pro zlepšení. Tato příručka vám poskytne znalosti k vytvoření přesných standardních hodnot výkonu a zajištění toho, aby migrované databáze splňovaly nebo překročily jejich aktuální úrovně výkonu v prostředí Azure. Ať už se snažíte optimalizovat výkon dotazů, zlepšit škálovatelnost nebo zajistit konzistentní uživatelské prostředí, tento článek poskytuje přehledy potřebné k dosažení vašich cílů výkonu.
Požadavky
Migrace místního MySQL do služby Azure Database for MySQL: Testovací plány
Přehled
Pochopení stávající úlohy MySQL je jednou z nejlepších investic, které je možné provést, aby se zajistila úspěšná migrace. Vynikající výkon systému závisí na adekvátním hardwaru a skvělém návrhu aplikace. Položky, jako jsou procesor, paměť, disk a sítě, musí mít správnou velikost a konfiguraci pro očekávané zatížení. Hardware a konfigurace jsou součástí rovnice výkonu systému. Vývojář musí porozumět zatížení databázového dotazu a nejdražším dotazům, které se mají spustit. Zaměření na nejdražší dotazy může podstatně ovlivnit celkové metriky výkonu.
Vytvoření standardních hodnot výkonu dotazů je nezbytné pro projekt migrace. Standardní hodnoty výkonu je možné použít k ověření konfigurace cílové zóny Azure pro migrované datové úlohy. Většina systémů běží 24/7 a má různé doby načítání ve špičce. Je důležité zachytit úlohy ve špičce pro směrný plán. Metriky se zaznamenávají několikrát. Později v dokumentu prozkoumáme parametry zdrojového serveru a to, jak jsou nezbytné pro celkový obrázek standardních hodnot výkonu. Parametry serveru by se neměly během projektu migrace přehlédnout.
Nástroje
Níže jsou uvedené nástroje, které slouží ke shromažďování metrik serveru a informací o úlohách databáze. Zachycené metriky použijte k určení odpovídající úrovně Azure Database for MySQL a přidružených možností škálování.
Telemetrie MySQL Enterprise: Tento neblokovaný nástroj enterprise edition může poskytnout seřazený seznam nejnákladnějších dotazů, metrik serverů, vstupně-výstupních operací a informací o topologii souborů.
Percona Monitoring and Management (PMM) : nejlepší opensourcové řešení pro monitorování databází. Pomáhá snížit složitost, optimalizovat výkon a zlepšit zabezpečení důležitých podnikových databázových prostředí bez ohledu na nasazené umístění.
Parametry serveru
Výchozí konfigurace serveru MySQL nemusí adekvátně podporovat úlohu. MySQL má řadu parametrů serveru, ale ve většině případů by se migrační tým měl zaměřit na několik. Ve zdrojovém a cílovém prostředí by se měly vyhodnotit následující parametry. Nesprávné konfigurace můžou ovlivnit rychlost migrace. Až provedeme kroky migrace, znovu se k těmto parametrům vrátíme.
innodb_buffer_pool_size: Velká hodnota zajišťuje, aby se prostředky v paměti používaly jako první před použitím vstupně-výstupních operací disku. Typické hodnoty jsou v rozsahu od 80 % do 90 % dostupné paměti. Například systém s 8 GB paměti by měl přidělit velikost fondu 5 až 6 GB.
innodb_log_file_size: Protokoly opakování zajišťují rychlé a odolné zápisy. Toto transakční zálohování je užitečné během chybového ukončení systému. Počínaje innodb_log_file_size = 512M (což poskytuje 1 GB protokolů opakování) by mělo dát dostatek místa pro zápisy. Aplikace náročné na zápis používající MySQL 5.6 nebo vyšší by měly začínat innodb_log_file_size = 4G.
max_connections: Tento parametr může pomoct zmírnit
Too many connectionschybu. Výchozí hodnota je 151 připojení. Použití fondu připojení na úrovni aplikace je upřednostňované, ale konfigurace připojení k serveru může také vyžadovat zvýšení.innodb_file_per_table: Toto nastavení innoDB říká, jestli má ukládat data a indexy ve sdíleném tabulkovém prostoru nebo v samostatném souboru.ibd pro každou tabulku. Když máte soubor na tabulku, může server uvolnit místo, když se tabulky zahodí, zkrátí nebo znovu sestaví. Databáze obsahující mnoho tabulek by neměly používat tabulku pro každou konfiguraci souboru. Od MySQL 5.6 je výchozí hodnota ZAPNUTÁ. Starší verze databáze by měly před načtením dat nastavit konfiguraci na ZAPNUTO. Toto nastavení má vliv jenom na nově vytvořené tabulky.
innodb_flush_log_at_trx_commit: Výchozí nastavení jednoho znamená, že InnoDB je plně kompatibilní s acid. Tato konfigurace transakcí s nižším rizikem může mít značné režijní náklady na systémy s pomalými disky kvůli nadbytečné synchronizaci potřebné k vyprázdnění každé změny do protokolů opakování. Nastavení parametru na 2 je trochu méně spolehlivé, protože potvrzené transakce budou vyprázdněny do protokolů opakování pouze jednou za sekundu. Riziko může být v některých hlavních situacích přijatelné a je to dobrá hodnota pro repliku. Hodnota 0 umožňuje lepší výkon systému, ale databázový server je podobný ztrátě některých dat během selhání. Dolní řádek slouží pouze k použití hodnoty 0 pro repliku.
innodb_flush_method: Toto nastavení určuje, jak se data a protokoly vyprázdní na disk. Používá
O_DIRECTse, když je v přítomnosti hardwarového řadiče RAID s mezipamětí pro zpětný zápis chráněný baterií. Pro jiné scénáře použijtefdatasync(výchozí hodnota).innodb_log_buffer_size: Toto nastavení je velikost vyrovnávací paměti pro transakce, které se ještě mají potvrdit. Výchozí hodnota (1 MB) je přijatelná. Transakce s velkými poli blob/text můžou rychle vyplnit vyrovnávací paměť a aktivovat dodatečné vstupně-výstupní načtení. Podívejte se na
Innodb_log_waitsstavovou proměnnou a pokud není 0, zvyšteinnodb_log_buffer_sizehodnotu .query_cache_size: Mezipaměť dotazů je dobře známý kritický bod, který lze pozorovat během střední souběžnosti. Počáteční hodnota by měla být nastavena na hodnotu 0, aby se zakázala mezipaměť, například query_cache_size = 0. Toto je výchozí hodnota pro MySQL 5.6 a novější.
log_bin: Toto nastavení umožňuje binární protokolování. Povolení binárního protokolování je povinné, pokud má server fungovat jako hlavní server replikace.
server_id: Toto nastavení je jedinečné pro servery identit v topologiích replikace.
expire_logs_days: Toto nastavení určuje, kolik dní se binární protokoly automaticky vymažou.
skip_name_resolve: uživatel, který má provést překlad názvu hostitele klienta. Pokud je DNS pomalý, připojení je pomalé. Při zakazování překladu ip adres musí příkazy GRANT používat pouze IP adresy. Aby bylo možné použít IP adresu, je potřeba znovu provést všechny předchozí příkazy GRANT.
Spuštěním následujícího příkazu exportujte parametry serveru do souboru ke kontrole. Pomocí jednoduché analýzy může výstup po migraci znovu použít stejné parametry serveru, pokud je to vhodné, na server Azure Database for MySQL. Referenční informace o konfiguraci parametrů serveru ve službě Azure Database for MySQL pomocí webu Azure Portal
mysql -u root -p -A -e "SHOW GLOBAL VARIABLES;" > settings.txt
Výchozí parametry nainstalovaného serveru MySQL 5.5.60 najdete v dodatku.
Před zahájením migrace exportujte zdrojové nastavení konfigurace MySQL. Tyto hodnoty porovnejte s nastavením instance cílové zóny Azure po migraci. Pokud se některá nastavení změnila z výchozího nastavení v cílové instanci cílové zóny Azure, ujistěte se, že se po migraci nastaví zpátky. Uživatel migrace by také měl ověřit, že parametry serveru je možné nastavit před migrací.
Seznam parametrů serveru, které nelze konfigurovat, najdete v tématu Nekonfigurovatelné parametry serveru.
Výchozí přenos a Příchozí přenos
Parametry zdrojového a cílového serveru MySQL je nutné upravit pro každý příslušný nástroj pro migraci dat a cestu, aby podporovaly nejrychlejší možný výchozí a příchozí přenos dat. V závislosti na nástroji se parametry můžou lišit. Nástroj, který provádí migraci paralelně, může například potřebovat více připojení mezi zdrojem a cílem a nástrojem s jedním vláknem.
Zkontrolujte všechny parametry časového limitu, které můžou datové sady ovlivnit. Tady jsou některé z nich:
Kromě toho zkontrolujte všechny parametry, které mají vliv na maximum:
Poznámka:
Běžnou chybou migrace je MySQL server has gone away. Zde uvedené parametry jsou typickými viníky pro řešení této chyby.
Scénář WWI
WWI zkontrolovala svou úlohu databáze Konference a určila, že měla malé zatížení. I když by pro ně server úrovně Basic fungoval, nechtěli později provést práci s migrací na jinou vrstvu. Nasazený server bude nakonec hostovat ostatní datové úlohy MySQL, takže vybrala vrstvu General Performance .
Při kontrole databáze MySQL jsem zjistil, že server MySQL 5.5 běží s výchozími parametry serveru nastavenými během počáteční instalace.