Migrace místního MySQL do služby Azure Database for MySQL: Testovací plány
Vývoj komplexních testovacích plánů je zásadní pro migraci databází MySQL z místních prostředí do Služby Azure Database for MySQL. Tento článek obsahuje podrobný přehled základních součástí efektivních testovacích plánů a zajištění hladkého a úspěšného procesu migrace. Rizika můžete zmírnit tak, že vystičíte klíčové strategie testování, identifikujete potenciální problémy, určíte jasná kritéria ověření a zajistíte optimální výkon migrovaných databází v prostředí Azure. Ať už se zaměřujete na funkční testování, testování výkonu nebo testování zabezpečení, tato příručka vám poskytne znalosti a osvědčené postupy potřebné k vytvoření robustních testovacích plánů, které podporují bezproblémovou migraci.
Požadavky
Migrace místního MySQL do služby Azure Database for MySQL: Metody migrace
Přehled
WWI vytvořil testovací plán, který zahrnoval sadu IT a obchodních úkolů. Úspěšné migrace vyžadují spuštění všech testů.
Testy:
Ujistěte se, že migrovaná databáze má konzistenci (stejný počet záznamů a výsledky dotazů) s místními tabulkami.
Ujistěte se, že je výkon přijatelný (měl by odpovídat stejnému výkonu, jako kdyby běžel místně).
Ujistěte se, že výkon cílových dotazů splňuje stanovené požadavky.
Zajistěte přijatelné síťové připojení mezi místním prostředím a sítí Azure.
Zajistěte, aby se všechny identifikované aplikace a uživatelé mohli připojit k migrované instanci dat.
WWI identifikovala víkend migrace a časové období, které začalo v 10 hodin a skončilo v 2: Tichomoří. Pokud se migrace nedokončila před cílem 2 hodin (cíl výpadku 4 hodin) se všemi testy, které prošly, spustily se postupy vrácení zpět. Problémy byly zdokumentovány pro budoucí pokusy o migraci. Všechna okna migrace se odeslala dopředu a přeplánovala na základě přijatelných obchodních časových os.
Vzorové dotazy
Ve zdroji a cíli se spustila řada dotazů, aby se ověřil úspěch migrace databáze. Následující dotazy a skripty pomáhají určit, jestli akce migrace přesunuly všechny požadované databázové objekty ze zdroje do cíle.
Řádky tabulky
Tento dotaz můžete použít k získání všech tabulek a odhadovaného počtu řádků:
SELECT SUM(TABLE_ROWS)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '{SchemaName}';
Poznámka:
Tabulka INFORMATION_SCHEMA poskytuje odhadovanou sadu hodnot v tabulkách. Pokud chcete získat přesnější zobrazení metrik, jako je velikost tabulky, zvyšte velikost vzorku stránky pomocí parametru innodb_stats_transient_sample_pages serveru. Zvýšení hodnoty serveru vynutí analýzu více stránek a poskytuje přesnější výsledky.
Spusťte příkaz count(*) SQL pro každou tabulku, abyste získali přesný počet řádků. Spuštění tohoto příkazu může u velkých tabulek trvat dlouhou dobu. Následující skript vygeneruje sadu příkazů SQL, které se dají spustit, aby získaly přesné počty:
SELECT CONCAT(
'SELECT "',
table_name,
'" AS table_name, COUNT(*) AS exact_row_count FROM `',
table_schema,
'`.`',
table_name,
'` UNION '
)
FROM INFORMATION_SCHEMA.TABLES
WHERE table_schema = '**my_schema**';
Fragmentace tabulek
Tabulky dat budou pravděpodobně i nadále růst s pokračujícím využitím aplikace. V některých případech nemusí data růst, ale neustále se mění prostřednictvím odstranění a aktualizací. Pokud ano, je možné, že v souborech databáze existuje mnoho fragmentací. Příkaz MySQL OPTIMIZE TABLE může snížit potřeby fyzického úložiště a zlepšit efektivitu vstupně-výstupních operací.
Tabulky MySQL můžete optimalizovat spuštěním následujících kroků :
optimize table TABLE_NAME
Databázové objekty
Pomocí následujícího dotazu se ujistěte, že jsou všechny ostatní databázové objekty započítány. I když tyto dotazy můžou počítat počty řádků tabulky, nemusí mít na výběr verzi konkrétního databázového objektu. I když například uložená procedura může existovat, mohla se mezi začátkem a koncem migrace změnit. Během migrace se doporučuje zamrznout vývoj databázových objektů.
Uživatelé
SELECT DISTINCT
USER
FROM
mysql.user
WHERE
user <> '' order by user
Indexy
SELECT DISTINCT
INDEX_NAME
FROM
information_schema.STATISTICS
WHERE
TABLE_SCHEMA = '{SchemaName}'
Omezení
SELECT DISTINCT
CONSTRAINT_NAME
FROM
information_schema.TABLE_CONSTRAINTS
WHERE
CONSTRAINT_SCHEMA = '{SchemaName}'
Zobrazení
SELECT
TABLE_NAME
FROM
information_schema.VIEWS
WHERE
TABLE_SCHEMA = '{SchemaName}'
Uložené procedury
SELECT
ROUTINE_NAME
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'FUNCTION' and
ROUTINE_SCHEMA = '{SchemaName}'
Functions
SELECT
ROUTINE_NAME
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'PROCEDURE' and
ROUTINE_SCHEMA = '{SchemaName}'
Události
SELECT
EVENT_NAME
FROM
INFORMATION_SCHEMA.EVENTS
WHERE
EVENT_SCHEMA = '{SchemaName}'
Strategie vrácení zpět
Výše uvedené dotazy poskytují seznam názvů a počtů objektů použitých při rozhodování o vrácení zpět. Uživatelé migrace můžou provést první krok ověření objektu kontrolou počtu zdrojových a cílových objektů. Nesrovnalosti v počtech objektů nemusí nutně znamenat, že je potřeba vrátit zpět. Provedení hloubkového vyhodnocení by mohlo upozornit na to, že rozdíl je mírný a snadno obnovitelný. Řešením může být ruční migrace několika neúspěšných objektů. Pokud se například migrovaly všechny tabulky a řádky dat, zmeškaly se jenom některé funkce, opravte tyto neúspěšné objekty a dokončete migraci. Pokud je databáze relativně malá, může být možné vymazat instanci Azure Database for MySQL a restartovat migraci. Velké databáze můžou k určení chybějících objektů potřebovat více času, než je k dispozici v okně migrace. Migrace se musí zastavit a vrátit zpět.
Identifikace chybějících databázových objektů musí během okna migrace rychle nastat. Každou minutu se počítá. Jednou z možností může být export názvů objektů prostředí do souboru a použití nástroje pro porovnání dat k rychlé identifikaci chybějících objektů. Další možností může být export názvů zdrojových databázových objektů a import dat do dočasné tabulky cílového prostředí databáze. Porovnejte data pomocí skriptu a otestovaného příkazu SQL. Rychlost a přesnost ověření dat jsou pro proces migrace zásadní. Během okna migrace nespoléhejte na ruční čtení a ověřování dlouhého seznamu databázových objektů. Možnost lidské chyby je příliš velká. Nejlepší by bylo, kdybyste je spravoval pomocí výjimek pomocí nástrojů.
Scénář WWI
ŘEDITELKA WWI obdržela potvrzovací zprávu, že všechny databázové objekty byly migrovány z místní databáze do instance Azure Database for MySQL. Databázový tým spustil výše uvedené dotazy na databázi před začátkem migrace a uložil všechny výsledky do tabulky.
Informace o schématu zdrojové databáze se použily k ověření věrnosti cílového objektu migrace.
Kontrolní seznam testovacích plánů
Nechte testovat, testovat a testovat dotazy, které jsou připravené ke spuštění.
Zjistěte, jak dlouho trvá spuštění testovacích dotazů, a nastavte je jako součást zdokumentované časové osy migrace.
Připravte strategii pro zmírnění rizik a vrácení zpět pro různé potenciální výsledky.
Máte dobře definovanou časovou osu událostí pro migraci.