Migrera MySQL lokalt till Azure Database for MySQL: Testplaner
Det är viktigt att utveckla omfattande testplaner vid migrering av MySQL-databaser från lokala miljöer till Azure Database for MySQL. Den här artikeln innehåller en djupgående titt på de viktigaste komponenterna i effektiva testplaner, vilket säkerställer att migreringsprocessen är smidig och framgångsrik. Du kan minska riskerna genom att beskriva viktiga teststrategier, identifiera potentiella problem, upprätta tydliga valideringskriterier och se till att dina migrerade databaser fungerar optimalt i Azure-miljön. Oavsett om du fokuserar på funktionell testning, prestandatestning eller säkerhetstestning, ger den här guiden dig de kunskaper och bästa praxis som krävs för att skapa robusta testplaner som stöder en sömlös migrering.
Förutsättningar
Migrera MySQL lokalt till Azure Database for MySQL: Migreringsmetoder
Översikt
WWI skapade en testplan som innehöll en uppsättning IT- och affärsuppgifter. Lyckade migreringar kräver att alla tester körs.
Tester:
Kontrollera att den migrerade databasen har konsekvens (samma antal poster och frågeresultat) med lokala tabeller.
Se till att prestandan är acceptabel (den bör matcha samma prestanda som om den kördes lokalt).
Se till att prestanda för målfrågor uppfyller angivna krav.
Se till att nätverksanslutningen mellan det lokala nätverket och Azure-nätverket är acceptabel.
Se till att alla identifierade program och användare kan ansluta till den migrerade datainstansen.
WWI har identifierat ett migreringsweekend och tidsfönster som startade klockan 22.00 och slutade klockan 02.00 Pacific Time. Om migreringen inte slutfördes före 02:00-målet (4-timmars stilleståndstidsmålet) med alla tester som skickades, startades återställningsprocedurerna. Problem har dokumenterats för framtida migreringsförsök. Alla migreringsfönster flyttades framåt och schemalades om baserat på acceptabla affärstidslinjeer.
Exempelfrågor
En serie frågor kördes på källan och målet för att verifiera att databasmigreringen lyckades. Följande frågor och skript hjälper dig att avgöra om migreringsåtgärderna flyttade alla nödvändiga databasobjekt från källan till målet.
Tabellrader
Du kan använda den här frågan för att hämta alla tabeller och ett uppskattat radantal:
SELECT SUM(TABLE_ROWS)
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = '{SchemaName}';
Kommentar
Tabellen INFORMATION_SCHEMA innehåller en uppskattad uppsättning värden i tabellerna. Om du vill få en mer exakt vy över mått som tabellstorlek ökar du sidexemplets storlek med innodb_stats_transient_sample_pages serverparametern. Att öka det här servervärdet tvingar fler sidor att analyseras och ge mer exakta resultat.
Kör SQL-instruktionen count(*) mot varje tabell för att få ett korrekt antal rader. Det kan ta lång tid att köra det här kommandot i stora tabeller. Följande skript genererar en uppsättning SQL-instruktioner som kan köras för att få exakta antal:
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**';
Tabellfragmentering
Datatabellerna kommer sannolikt att fortsätta att växa sig större med fortsatt programanvändning. I vissa fall kanske inte data växer, men de ändras ständigt genom borttagningar och uppdateringar. I så fall är det möjligt att det finns många fragmentering i databasfilerna. MySQL OPTIMIZE TABLE-instruktionen kan minska behovet av fysiskt lagringsutrymme och förbättra I/O-effektiviteten.
Du kan optimera MySQL-tabellerna genom att köra följande:
optimize table TABLE_NAME
Databasobjekt
Använd följande fråga för att se till att alla andra databasobjekt redovisas. Även om dessa frågor kan beräkna antalet tabellrader kanske de inte står för versionen av det specifika databasobjektet. Även om det till exempel kan finnas en lagrad procedur kan den ha ändrats mellan början och slutet av migreringen. Vi rekommenderar att du fryser utvecklingen av databasobjekt under migreringen.
Användare
SELECT DISTINCT
USER
FROM
mysql.user
WHERE
user <> '' order by user
Index
SELECT DISTINCT
INDEX_NAME
FROM
information_schema.STATISTICS
WHERE
TABLE_SCHEMA = '{SchemaName}'
Restriktioner
SELECT DISTINCT
CONSTRAINT_NAME
FROM
information_schema.TABLE_CONSTRAINTS
WHERE
CONSTRAINT_SCHEMA = '{SchemaName}'
Vyer
SELECT
TABLE_NAME
FROM
information_schema.VIEWS
WHERE
TABLE_SCHEMA = '{SchemaName}'
Lagrade procedurer
SELECT
ROUTINE_NAME
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'FUNCTION' and
ROUTINE_SCHEMA = '{SchemaName}'
Funktioner
SELECT
ROUTINE_NAME
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'PROCEDURE' and
ROUTINE_SCHEMA = '{SchemaName}'
Händelser
SELECT
EVENT_NAME
FROM
INFORMATION_SCHEMA.EVENTS
WHERE
EVENT_SCHEMA = '{SchemaName}'
Återställningsstrategier
Frågorna ovan innehåller en lista över objektnamn och antal som används i ett återställningsbeslut. Migreringsanvändare kan ta det första steget för objektverifiering genom att kontrollera antalet käll- och målobjekt. En avvikelse i antalet objekt kanske inte nödvändigtvis innebär att en återställning behövs. Att utföra en djupgående utvärdering kan påpeka att skillnaden är liten och lätt att återställa. Manuell migrering av några misslyckade objekt kan vara lösningen. Om till exempel alla tabeller och datarader migrerades missades bara några av funktionerna, reparerar de misslyckade objekten och slutför migreringen. Om databasen är relativt liten kan det vara möjligt att rensa Azure Database for MySQL-instansen och starta om migreringen. Stora databaser kan behöva mer tid än vad som är tillgängligt i migreringsfönstret för att fastställa saknade objekt. Migreringen måste stoppas och återställas.
Identifiering av saknade databasobjekt måste ske snabbt under ett migreringsfönster. Varje minut räknas. Ett alternativ kan vara att exportera miljöobjektnamnen till en fil och använda ett datajämförelseverktyg för att snabbt identifiera saknade objekt. Ett annat alternativ kan vara att exportera källdatabasobjektnamnen och importera data till en temp-tabell för måldatabasmiljön. Jämför data med hjälp av en skriptad och testad SQL-instruktion. Dataverifieringshastighet och noggrannhet är avgörande för migreringsprocessen. Förlitar du dig inte på att manuellt läsa och verifiera en lång lista med databasobjekt under ett migreringsfönster. Risken för mänskliga fel är för stor. Det vore bäst om du hanterade med undantag med hjälp av verktyg.
WWI-scenario
WWI-CIO:n fick en bekräftelserapport om att alla databasobjekt migrerades från den lokala databasen till Azure Database for MySQL-instansen. Databasteamet körde ovanstående frågor mot databasen före migreringens början och sparade alla resultat i ett kalkylblad.
Schemainformationen för källdatabasen användes för att verifiera målmigreringsobjektets återgivning.
Checklista för testplaner
Ha testfrågor skriptade, testade och redo att köras.
Ta reda på hur lång tid det tar att köra testfrågor och gör det till en del av den dokumenterade tidslinjen för migrering.
Ha en strategi för minskning och återställning redo för olika potentiella resultat.
Ha en väldefinierad tidslinje med händelser för migreringen.