Migrace místního MySQL do služby Azure Database for MySQL: Posouzení
Posouzení migrace databází MySQL z místních prostředí do Služby Azure Database for MySQL je důležitým prvním krokem k zajištění hladkého a úspěšného přechodu. Tento článek důkladně prozkoumá klíčové faktory a aspekty, které jsou součástí fáze posouzení. Informovaná rozhodnutí, která odpovídají cílům vaší organizace, můžete provést vyhodnocením aktuální infrastruktury, identifikací potenciálních problémů a pochopením výhod spravovaných databázových služeb Azure. Ať už se snažíte zvýšit výkon, zlepšit škálovatelnost nebo snížit provozní náklady, tato příručka vám poskytne přehledy potřebné k efektivnímu plánování a provádění strategie migrace.
Požadavky
Migrace místního MySQL do služby Azure Database for MySQL: Případ reprezentativního použití
Přehled
Než se pustíte přímo do migrace úlohy MySQL, je potřeba provést poměrně velkou hloubkovou kontrolu. To zahrnuje analýzu dat, hostitelského prostředí a aplikačních úloh za účelem ověření správné konfigurace cílové zóny Azure a připravenosti na hostování brzy migrovaných úloh.
Omezení
Azure Database for MySQL je plně podporovaná verze komunitní edice MySQL, která běží jako platforma jako služba. Při počátečním posouzení se ale můžete seznámit s určitými omezeními .
Mezi nejdůležitější patří:
Podpora modulu úložiště pouze pro
InnoDBMemoryOmezená
Privilegepodpora (DBA,SUPER,DEFINER)Zakázané příkazy pro manipulaci s daty (
SELECT ... INTO OUTFILE,LOAD DATA INFILE)Automatická významná migrace databáze (5.6 až 5.7, 5.7 až 8.0)
Při použití uživatelem definovaných funkcí (UDF) serveru MySQL je jedinou možností hostování virtuální počítače hostované v Azure, protože neexistuje žádná možnost nahrání
sonebodllkomponenty do služby Azure Database for MySQL.
Mnohé z dalších položek jsou provozní aspekty, se kterými by se správci měli seznámit jako součást správy životního cyklu úloh provozních dat. Tato příručka zkoumá mnoho z těchto provozních aspektů v části Správa po migraci.
Verze MySQL
MySQL má bohatou historii od roku 1995. Od té doby se vyvinul do široce používaného systému pro správu databází. Služba Azure Database for MySQL začala s podporou MySQL verze 5.6 a pokračovala na verzi 5.7 a nedávno 8.0. Nejnovější informace o podpoře verzí služby Azure Database for MySQL najdete v referenčních informacích k podporovaným verzím serveru Azure Database for MySQL. V části Post Migration Management se podíváme, jak se upgrady (například 5.7.20 na 5.7.21) použijí na instance MySQL v Azure.
Poznámka:
Skok z 5.x na 8.0 byl z velké části způsoben získáním Oracle MySQL. Pokud si chcete přečíst další informace o historii MySQL, přejděte na stránku wikiwebu MySQL.
Znalost zdrojové verze MySQL je nezbytná. Aplikace používající systém můžou používat databázové objekty a funkce specifické pro danou verzi. Migrace databáze do nižší verze může způsobit problémy s kompatibilitou a ztrátu funkčnosti. Doporučuje se také, aby data a instance aplikace byly důkladně testovány před migrací na novější verzi, protože zavedené funkce by mohly narušit vaši aplikaci.
Příklady, které můžou ovlivnit cestu a verzi migrace:
5.6: Sloupec TIMESTAMP pro správné uložení milisekund a fulltextového vyhledávání
5.7: Podpora nativního datového typu JSON
8.0: Podpora úložiště dokumentů NoSQL, atomických a chybově bezpečných funkcí DDL a tabulek JSON
Poznámka:
MySQL 5.6 ztratí obecnou podporu v únoru 2021. Úlohy MySQL musí migrovat na mySQL verze 5.7 nebo vyšší.
Kontrola verze serveru MySQL:
SHOW VARIABLES LIKE "%version%";
Databázové úložné stroje
Azure Database for MySQL podporuje pouze databázové stroje InnoDB a Memory Database Storage. Jiné úložné moduly, jako je MyISAM, je potřeba migrovat do podporovaného úložného modulu. Rozdíly mezi MyISAM a InnoDB jsou provozní funkce a výstup výkonu. Tabulky vyšší úrovně a struktura schématu se obvykle mezi moduly nemění, ale typy sloupců indexu a tabulky se můžou měnit z důvodů úložiště a výkonu. I když je známo, že innoDB má velké velikosti datových souborů, tyto podrobnosti o úložišti spravuje služba Azure Database for MySQL.
Migrace z MyISAM na InnoDB
Databáze a tabulky MyISAM je potřeba převést na tabulky InnoDB. Po převodu by měly být aplikace testovány na kompatibilitu a výkon. Ve většině případů testování vyžaduje opětovné vytvoření tabulky a změnu cílového úložného modulu prostřednictvím příkazů DDL. Je nepravděpodobné, že by se tato změna během migrace prováděla, protože k ní dochází během vytváření schématu v cíli Azure. Další podrobnosti najdete v dokumentaci pro vývojáře převáděné tabulky na webu MySQL.
Pokud chcete najít užitečné informace o tabulce, použijte tento dotaz:
SELECT
tab.table_schema,
tab.table_name,
tab.engine as engine_type,
tab.auto_increment,
tab.table_rows,
tab.create_time,
tab.update_time,
tco.constraint_type
FROM information_schema.tables tab
LEFT JOIN information_schema.table_constraints tco
ON (tab.table_schema = tco.table_schema
AND tab.table_name = tco.table_name
)
WHERE
tab.table_schema NOT IN ('mysql', 'information_schema', 'performance_
schema', 'sys')
AND tab.table_type = 'BASE TABLE';
Poznámka:
Spuštění dotazu na INFORMATION_SCHEMA napříč více databázemi může ovlivnit výkon. Spusťte během období nízkého využití.
Pokud chcete převést tabulku z MyISAM na InnoDB, spusťte následující příkaz:
ALTER TABLE {table\_name} ENGINE=InnoDB;
Poznámka:
Tento přístup převodu způsobí uzamčení tabulky a všechny aplikace můžou čekat, až se operace dokončí. Uzamčení tabulky způsobí, že se databáze zobrazí po krátkou dobu offline.
Místo toho lze tabulku vytvořit se stejnou strukturou, ale s jiným modulem úložiště. Po vytvoření zkopírujte řádky do nové tabulky:
INSERT INTO {table\_name} SELECT * FROM {myisam\_table} ORDER BY {primary\_key\_columns}
Poznámka:
Aby byl tento přístup úspěšný, musí být původní tabulka odstraněna a pak přejmenována nová tabulka. Tato úloha způsobí krátkou dobu výpadku.
Data a objekty databáze
Data jsou jednou komponentou migrace databáze. Databáze podporující objekty musí být migrována a ověřena, aby aplikace nadále běžely spolehlivě.
Tady je seznam položek, které byste měli inventarizaci provést před migrací a po této migraci:
Tabulky (schéma)
Primární klíče, cizí klíče
Indexy
Funkce
Procedury
Aktivační události
Zobrazení
Uživatelem definované funkce
MySQL umožňuje používat funkce, které volají externí kód. Datové úlohy využívající uživatelem definované funkce (UDF) s externím kódem bohužel nejde migrovat do Služby Azure Database for MySQL. Důvodem je to, že backing požadované funkce MySQL, takže kód knihovny DLL nelze nahrát na server Azure.
Spuštěním následujícího dotazu vyhledejte všechny funkce definované uživatelem, které se můžou nainstalovat:
SELECT * FROM mysql.func;
Zdrojové systémy
Množství přípravy migrace se může lišit v závislosti na zdrojovém systému a jeho umístění. Kromě databázových objektů zvažte, jak získat data ze zdrojového systému do cílového systému. Migrace dat může být náročná, když jsou brány firewall a další síťové komponenty mezi zdrojem a cílem.
Přesun dat přes internet může být navíc pomalejší než použití vyhrazených okruhů do Azure. Proto při přesouvání mnoha gigabajtů, terabajtů a petabajtů dat zvažte nastavení připojení ExpressRoute mezi zdrojovou sítí a sítí Azure.
Pokud už expressRoute existuje, je pravděpodobné, že připojení používá jiné aplikace. Provedení migrace přes existující trasu může způsobit přetížení propustnosti sítě a potenciálně způsobit významné dosažení výkonu migrace i jiných aplikací používajících síť.
Nakonec musí být vyhodnoceno místo na disku. Při exportu velké databáze zvažte velikost dat. Ujistěte se, že systém, na kterém je nástroj spuštěný, a nakonec má umístění exportu dostatek místa na disku k provedení operace exportu.
Poskytovatelé cloudu
Migrace databází od poskytovatelů cloudových služeb, jako je Amazon Web Services (AWS), může vyžadovat další krok konfigurace sítě, aby bylo možné přistupovat k instancím MySQL hostovaným v cloudu. Nástroje pro migraci, jako je služba Data Migration Services, vyžadují přístup z vnějších rozsahů IP adres a můžou být jinak blokované.
Místní
Podobně jako poskytovatelé cloudu je potřeba vytvořit cestu mezi místní instancí a službou Azure Database for MySQL, pokud je úloha dat MySQL za branami firewall nebo jinými vrstvami zabezpečení sítě.
Nástroje
K posouzení datových úloh a prostředí MySQL je možné použít mnoho nástrojů a metod. Každý nástroj poskytuje jinou sadu funkcí a funkcí posouzení a migrace. V rámci této příručky si projdeme nejčastěji používané nástroje pro posuzování datových úloh MySQL.
Azure Migrates
Přestože Azure Migrate přímo nepodporuje migraci databázových úloh MySQL, je možné ji použít, když si správci nejsou jisti, kteří uživatelé a aplikace data využívají, ať už jsou hostované na virtuálním nebo hardwarovém počítači. Analýzu závislostí je možné provést instalací a spuštěním agenta monitorování na počítači, který je hostitelem úlohy MySQL. Agent shromažďuje informace za nastavené období, například měsíc. Data závislostí je možné analyzovat a najít neznámá připojení vytvářená k databázi. Data připojení můžou pomoct identifikovat vlastníky aplikací, kteří musí být upozorněni na čekající migraci.
Kromě analýzy závislostí aplikací a dat připojení uživatelů je možné službu Azure Migrate použít také k analýze hyper-V, VMware nebo fyzických serverů , které poskytují vzory využití databázových úloh, které vám pomůžou navrhnout správné cílové prostředí.
Telgraf pro Linux
Úlohy Linuxu můžou ke shromažďování dat na virtuálních a fyzických počítačích využívat agenta Microsoft Monitoring Agent (MMA ). Zvažte také použití agenta Telegrafu a široké škály modulů plug-in ke shromažďování metrik výkonu.
Úrovně služby
Další volbou uživatele migrace je rozhodnutí o tom, jakou cenovou úroveň Azure Database for MySQL začít používat, vybaveny informacemi o posouzení (procesor, paměť, úložiště atd.).
Aktuálně existují tři úrovně:
Základní: Úlohy vyžadující nízký výpočetní výkon a vstupně-výstupní výkon
Pro obecné účely: Většina obchodních úloh vyžadujících vyvážené výpočetní prostředky a paměť se škálovatelnou propustností vstupně-výstupních operací.
Optimalizováno pro paměť: Vysoce výkonné databázové úlohy vyžadující výkon v paměti pro rychlejší zpracování transakcí a vyšší souběžnost.
Rozhodnutí o úrovni může být ovlivněno požadavky RTO a cíle bodu obnovení úlohy dat. Pokud datová úloha vyžaduje více než 4 TB úložiště, je potřeba provést další krok. Zkontrolujte a vyberte oblast, která podporuje až 16 TB úložiště.
Rozhodování se obvykle zaměřuje na potřeby úložiště a vstupně-výstupních operací za sekundu nebo vstupně-výstupní operace. Cílový systém proto vždy potřebuje alespoň tolik úložiště jako ve zdrojovém systému. Vzhledem k tomu, že se IOPS přiděluje 3/GB, je navíc důležité shodovat vstupně-výstupní operace za sekundu s konečnou velikostí úložiště.
| Faktory | Úroveň |
|---|---|
| Basic | Vývojový počítač, který nevyžaduje vysoký výkon s úložištěm nižším než 1 TB. |
| Obecné použití | Potřebuje počet IOPS vyšší než úroveň Basic, ale pro úložiště menší než 16 TB a méně než 4 GB paměti. |
| Optimalizováno pro paměť | Datové úlohy, které využívají vysokou paměť nebo vysokou mezipaměť a konfiguraci serveru související s vyrovnávací pamětí, jako je vysoká souběžnost innodb_buffer_pool_instances, velké velikosti objektů blob, systémy s mnoha kopiemi replikace. |
Náklady
Po vyhodnocení celých datových úloh WWI MySQL se wwI zjistilo, že by potřebovaly alespoň 4 virtuální jádra a 20 GB paměti a alespoň 100 GB úložného prostoru s kapacitou IOP 450 IOPS. Kvůli 450 požadavkům na vstupně-výstupní operace za sekundu musí přidělit alespoň 150 GB úložiště kvůli metodě přidělování vstupně-výstupních operací za sekundu azure Database for MySQL. Kromě toho vyžadují alespoň 100 % zřízeného úložiště serveru jako úložiště záloh a jednu repliku pro čtení. Neočekává odchozí odchozí přenos dat o více než 5 GB.
Pomocí cenové kalkulačky Azure Database for MySQL dokázala WWI určit náklady na instanci Azure Database for MySQL. Od 9.2020 se celkové náklady na vlastnictví (TCO) zobrazují v následující tabulce pro databázi konference WWI.
| Resource | Popis | Množství | Náklady |
|---|---|---|---|
| Compute (pro obecné účely) | 4 virtuální jádra, 20 GB | 1 @ 0,351 USD za hodinu | 3074,76 Usd / yr |
| Úložiště | 5 GB | 12 x 150 @ $0,115 | $207 / yr |
| Backup | Až 100 % zřízeného úložiště | Bez dalších poplatků až 100 % zřízeného úložiště serveru | $0,00 / yr |
| Replika pro čtení | Replika 1sekundové oblasti | compute + storage | 3281,76 Usd / yr |
| Síť | < Výchozí přenos dat o 5 GB za měsíc | Bezplatný | |
| Celkem | $6563,52 / yr |
Po kontrole počátečních nákladů ředitelka IT wwI potvrdila, že jsou v Azure po dobu delší než tři roky. Rozhodli se použít 3leté rezervované instance k úspoře dalších ~$4K/yr.
| Resource | Popis | Množství | Náklady |
|---|---|---|---|
| Compute (pro obecné účely) | 4 virtuální jádra | 1 @ 0,1375 USD za hodinu | $1204,5 / yr |
| Úložiště | 5 GB | 12 x 150 @ $0,115 | $207 / yr |
| Backup | Až 100 % zřízeného úložiště | Bez dalších poplatků až 100 % zřízeného úložiště serveru | $0,00 / yr |
| Síť | < Výchozí přenos dat o 5 GB za měsíc | Bezplatný | |
| Replika pro čtení | Replika 1sekundové oblasti | compute + storage | $1411,5 / yr |
| Celkem | $2,823 / yr |
Jak ukazuje tabulka výše, zálohy, výchozí přenos dat sítě a všechny repliky pro čtení se musí brát v úvahu v celkových nákladech na vlastnictví (TCO). S tím, jak se přidávají další databáze, by vygenerovaný provoz úložiště a sítě byl jediným dalším faktorem založeným na nákladech, který je potřeba vzít v úvahu.
Poznámka:
Výše uvedené odhady nezahrnují žádné náklady na ExpressRoute, Aplikace Azure Gateway, Azure Load Balancer nebo App Service pro vrstvy aplikací.
Výše uvedené ceny se můžou kdykoli změnit a liší se v závislosti na oblasti.
Důsledky aplikace
Při přechodu na Azure Database for MySQL bude převod na zabezpečenou komunikaci založenou na soketech (SSL) pravděpodobně jedním z nejvýznamnějších změn pro vaše aplikace. Protokol SSL je ve výchozím nastavení povolený ve službě Azure Database for MySQL a je pravděpodobné, že místní aplikace a datové úlohy nejsou nastavené pro připojení k MySQL pomocí SSL. Pokud je tato možnost povolená, využití PROTOKOLU SSL přidává další režii na zpracování a mělo by se monitorovat.
Poznámka:
I když je protokol SSL ve výchozím nastavení povolený, máte možnost ho zakázat.
Postupujte podle aktivit konfigurace připojení SSL ve vaší aplikaci, abyste se mohli bezpečně připojit ke službě Azure Database for MySQL , abyste aplikaci překonfigurovali tak, aby podporovala tuto silnou cestu ověřování.
Nakonec upravte název serveru v aplikaci připojovací řetězec nebo přepněte DNS tak, aby odkazoval na nový server Azure Database for MySQL.
Scénář WWI
WWI zahájila posouzení shromažďováním informací o jejich datových aktivech MySQL, jak je znázorněno v následující tabulce.
| Název | Zdroj | Databázový stroj | Velikost | IOPS | Verze | Vlastník | Odstávka |
|---|---|---|---|---|---|---|---|
| WwwDB | AWS (PaaS) | InnoDB | 1 GB | 150 | 5.7 | Marketingové oddělení | 1 hodina |
| BlogDB | AWS (PaaS) | InnoDB | 1 GB | 100 | 5.7 | Marketingové oddělení | 4 hod. |
| ConferenceDB | Místní | InnoDB | 5 GB | 50 | 5.5 | Sales Dept | 4 hod. |
| CustomerDB | Místní | InnoDB | 10 GB | 75 | 5.5 | Sales Dept | 2 hodiny |
| SalesDB | Místní | InnoDB | 20 GB | 75 | 5.5 | Sales Dept | 1 hodina |
Každý vlastník databáze byl kontaktován, aby určil přijatelnou dobu výpadku. Vybraná metoda plánování a migrace byla založena na přijatelném výpadku databáze.
V první fázi se WWI zaměřila výhradně na databázi ConferenceDB. Tým potřeboval prostředí pro migraci, aby pomohl s migrací úloh dat. Databáze ConferenceDB byla vybrána z důvodu jednoduché struktury databáze a velkého přijatelného výpadku. Po migraci databáze se tým zaměřil na migraci aplikace do zabezpečené cílové zóny Azure.
Kontrolní seznam k posouzení
Otestujte úspěšné spuštění úlohy v cílovém systému.
Ujistěte se, že jsou pro migraci zavedeny správné síťové komponenty.
Seznamte se s požadavky na prostředky datové úlohy.
Odhad celkových nákladů
Seznamte se s požadavky na výpadky.
Připravte se na změny aplikace.