Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Datamigrering är en central aspekt av övergången av MySQL-databaser från lokala miljöer till Azure-databaser för MySQL. Den här artikeln går in i invecklingarna i datamigreringen och erbjuder en omfattande guide om de olika teknikerna och metodtipsen för att säkerställa en sömlös dataöverföring. Du kan planera och köra migreringsstrategin effektivt genom att förstå de olika datamigreringsmetoderna, till exempel logisk och fysisk migrering, och hantera potentiella utmaningar som dataintegritet och stilleståndstid. Den här guiden ger dig kunskap om att hantera stora datamängder, minimera störningar och använda Azures robusta funktioner för att optimera databasens prestanda och tillförlitlighet. Oavsett om du vill modernisera infrastrukturen eller förbättra datahanteringsfunktionerna ger den här artikeln de insikter som behövs för en lyckad datamigrering.
Förutsättningar
Migrera MySQL lokalt till Azure Database for MySQL: Prestandabaslinjer
Säkerhetskopiera databasen
Som ett försiktigt steg före uppgradering eller migrering av data exporterar du databasen före uppgraderingen med MySQL Workbench eller manuellt via mysqldump kommandot .
Offline jämfört med online
Innan du väljer ett migreringsverktyg bör det fastställas om migreringen ska vara online eller offline.
Offlinemigreringar gör att systemet är nere medan migreringen sker. Det här alternativet säkerställer att inga transaktioner inträffar och att datastatusen är exakt vad som förväntas när de återställs i Azure.
Onlinemigreringar migrerar data i nära realtid. Det här alternativet är lämpligt när det finns lite stilleståndstid för användare eller program som använder dataarbetsbelastningen. Processen omfattar replikering av data med hjälp av en replikeringsmetod, till exempel
binlogeller liknande.
För WWI har deras miljö vissa komplexa nätverk och säkerhetskrav som inte tillåter att lämpliga ändringar tillämpas för inkommande och utgående anslutningar inom målmigreringstiden. Dessa komplexiteter och krav eliminerar i stort sett onlinemetoden från övervägande.
Kommentar
Mer information om offline- och onlinemigrering finns i avsnitten Planering och utvärdering.
Dataavvikelse
Strategier för offlinemigrering har potential för dataavvikelser. Dataavvikelse uppstår när nyligen ändrade källdata blir osynkroniserade med migrerade data. När detta händer krävs en fullständig export eller en deltaexport. Du kan åtgärda det här problemet genom att stoppa all trafik till databasen och sedan utföra exporten. Om det inte går att stoppa all dataändringstrafik måste du ta hänsyn till avvikelsen.
Det kan bli komplicerat att fastställa ändringarna om databastabellerna inte har kolumner, till exempel en numerisk baserad primärnyckel, eller någon typ av ändrings- och skapandedatum i varje tabell som behöver migreras.
Om till exempel en numerisk baserad primärnyckel finns och migreringen importeras i sorteringsordning är det relativt enkelt att avgöra var importen stoppades och starta om den från den positionen. Om det inte finns någon numerisk baserad nyckel kan det vara möjligt att använda ändra och skapa datum, och sedan importera på ett sorterat sätt så att du kan starta om migreringen från det senaste datumet som sågs i målet.
Prestandarekommendationer
Export
Använd ett exportverktyg som kan köras i ett flertrådat läge, till exempel mydumper
När du använder MySQL 8.0 använder du partitionerade tabeller när det är lämpligt för att öka exporthastigheten.
Importera
Skapa klustrade index och primära nycklar efter inläsning av data. Läs in data i primärnyckelordning, eller annan om primärnyckel, någon datumkolumn (till exempel ändra datum eller skapa datum) i sorterad ordning.
Fördröj skapandet av sekundära index tills data har lästs in. Skapa alla sekundära index efter inläsning.
Inaktivera begränsningar för sekundärnyckel innan du läser in. Om du inaktiverar sekundärnyckelkontroller får du betydande prestandavinster. Aktivera begränsningarna och verifiera data efter inläsningen för att säkerställa referensintegritet.
Läs in data parallellt. Undvik för mycket parallellitet som kan orsaka resurskonkurrering och övervaka resurser med hjälp av de mått som är tillgängliga i Azure Portal.
Utföra migreringen
Säkerhetskopiera databasen
Skapa och verifiera Azure Landing-zonen
Konfigurera källserverparametrar
Konfigurera målserverparametrar
Exportera databasobjekten (schema, användare osv.)
Exportera data
Importera databasobjekten
Importera data
Validering
Återställa målserverparametrar
Migrera ett eller flera program
Vanliga steg
Trots vilken väg som vidtas finns det vanliga steg som måste utföras:
Uppgradera till en Azure MySQL-version som stöds
Inventeringsdatabasobjekt
Exportera användare och behörigheter
Migrera till den senaste MySQL-versionen
Eftersom WWI-konferensdatabasen kör 5.5 är det nödvändigt att utföra en uppgradering. CIO:et har bett att de uppgraderar till den senaste versionen av MySQL (för närvarande 8.0).
Det finns två sätt att uppgradera till 8.0:
På plats
Exportera/importera
När du bestämmer dig för att göra en uppgradering är det viktigt att du kör uppgraderingskontrollverktyget för att avgöra om det finns några konflikter. När du till exempel uppgraderar till MySQL Server 8.0 söker verktyget efter följande konflikter:
Databasobjektnamn som är i konflikt med reserverade ord i MySQL 8.0
Användning av utf8mb3-teckenuppsättningen
Användning av attributen zerofill/display length type
Tabellnamn som är i konflikt med tabeller i 8.0
Användning av tidstyp
Villkorsnamn för sekundärnyckel som är längre än 64 tecken
Om uppgraderingskontrollen inte rapporterar några problem är det säkert att göra en uppgradering på plats genom att ersätta MySQL-binärfiler. Databaser med problem måste exporteras och de problem som åtgärdas.
WWI-scenario
Efter att ha migrerat MySQL-instansen till 8.0 insåg WWI-migreringsteamet att den ursprungliga migreringsvägen MySQL lokalt till Azure Database for MySQL inte längre kunde användas eftersom DMS-verktyget för närvarande endast stöder 5.6 och 5.7. DMS krävs nätverksåtkomst. WWI-migreringsteamet var inte redo att hantera sina komplexa nätverksproblem. Dessa miljöproblem begränsade valet av migreringsverktyg till MySQL Workbench.
Databasobjekt
Som beskrivs i avsnittet Testplaner bör en inventering av databasobjekt göras före och efter migreringen för att säkerställa att du har migrerat allt.
Om du vill köra en lagrad procedur för att generera den här informationen kan du använda något som liknar följande:
DELIMITER //
CREATE PROCEDURE `Migration_PerformInventory`(IN schemaName CHAR(64))
BEGIN
DECLARE finished INTEGER DEFAULT 0;
DECLARE tableName varchar(100) DEFAULT "";
#get all tables
DECLARE curTableNames
CURSOR FOR
SELECT TABLE_NAME FROM information_schema.tables where TABL
E_SCHEMA = schemaName;
-- declare NOT FOUND handler
DECLARE CONTINUE HANDLER
FOR NOT FOUND SET finished = 1;
DROP TABLE IF EXISTS MIG_INVENTORY;
CREATE TABLE MIG_INVENTORY
(
REPORT_TYPE VARCHAR(1000),
OBJECT_NAME VARCHAR(1000),
PARENT_OBJECT_NAME VARCHAR (1000),
OBJECT_TYPE VARCHAR(1000),
COUNT INT
)
ROW_FORMAT=DYNAMIC,
ENGINE='InnoDB';
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'TABLES', 'TABLES', COUNT(*)
FROM
information_schema.tables
where
TABLE_SCHEMA = schemaName;
#### Constraints
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'STATISTICS', 'STATISTICS', COUNT(*)
FROM
information_schema.STATISTICS
WHERE
TABLE_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'VIEWS', 'VIEWS', COUNT(*)
FROM
information_schema.VIEWS
WHERE
ROUTINE_TYPE = 'FUNCTION' and
ROUTINE_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'PROCEDURES', 'PROCEDURES', COUNT(*)
FROM
information_schema.ROUTINES
WHERE
ROUTINE_TYPE = 'PROCEDURE' and
ROUTINE_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'EVENTS', 'EVENTS', COUNT(*)
FROM
information_schema.EVENTS
WHERE
EVENT_SCHEMA = schemaName;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'USER DEFINED FUNCTIONS', 'USER DEFINED FUNCTIONS'
, COUNT(*)
FROM
mysql.func;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'OBJECTCOUNT', 'USERS', 'USERS', COUNT(*)
FROM
mysql.user
WHERE
user <> '' order by user;
OPEN curTableNames;
getTableName: LOOP
FETCH curTableNames INTO tableName;
IF finished = 1 THEN
LEAVE getTableName;
END IF;
SET @s = CONCAT('SELECT COUNT(*) into @TableCount FROM ', schemaName,
'.', tableName);
#SELECT @s;
PREPARE stmt FROM @s;
EXECUTE stmt;
INSERT INTO MIG_INVENTORY (REPORT_TYPE,OBJECT_NAME, OBJECT_TYPE, COUNT)
SELECT
'TABLECOUNT', tableName, 'TABLECOUNT', @TableCount;
DEALLOCATE PREPARE stmt;
END LOOP getTableName;
CLOSE curTableNames;
SELECT * FROM MIG_INVENTORY;
END //
DELIMITER ;
CALL Migration_PerformInventory('reg_app');
- När du anropar den här proceduren i källdatabasen visas följande (trunkerade utdata):
- Resultatet av måldatabasproceduren bör likna bilden nedan när migreringen har slutförts. Observera att det inte finns några funktioner i databasen. Funktioner eliminerades före migreringen.
Användare och behörigheter
En lyckad migrering kräver migrering av associerade användare och behörigheter till målmiljön.
Exportera alla användare och deras bidrag med hjälp av följande PowerShell-skript:
$username = "yourusername";
$password = "yourpassword";
mysql -u$username -p$password --skip-column-names -A -e"SELECT CONCAT('SHOW G
RANTS FOR ''',user,'''@''',host,''';') FROM mysql.user WHERE user<>''" > Show
Grants.sql;
$lines = get-content "ShowGrants.sql"
foreach ($line in $lines)
{
mysql -u$username -p$password --skip-column-names -A -e"$line" >> AllGrants.sql
}
Skapa ett nytt PowerShell-skript med PowerShell ISE (se installationsdokumentet)
Ange ditt användarnamn till rot och lösenordet till rotanvändarens lösenord
Du kan sedan köra skriptet AllGrants.sql för den nya Azure Database for MySQL:
$username = "yourusername";
$password = "yourpassword";
$server = "serverDNSname";
$lines = get-content "AllGrants.sql"
foreach ($line in $lines)
{
mysql -u$username -p$password -h$server --ssl-ca=c:\temp\BaltimoreCyberTrus
tRoot.crt.cer --skip-column-names -A -e"$line"
}
Du kan också skapa användare i Azure Database for MySQL med hjälp av PowerShell: /azure/mysql/howto-create-users
Köra migrering
Med de grundläggande migreringskomponenterna på plats går det nu att fortsätta med datamigreringen. Det fanns flera verktyg och metoder som introducerades tidigare. För WWI använder de sökvägen MySQL Workbench för att exportera data och sedan importera dem till Azure Database for MySQL.
Checklista för datamigrering
Förstå miljöns komplexitet och om en onlinemetod är möjlig.
Konto för dataavvikelse. Om databastjänsten stoppas kan potentiella dataavvikelser elimineras.
Konfigurera källparametrar för snabb export.
Konfigurera målparametrar för snabb import.
Testa alla migreringar som har en annan källversion jämfört med målet.
Migrera icke-databaserade objekt, till exempel användarnamn och behörigheter.
Kontrollera att alla uppgifter är dokumenterade och avcheckade när migreringen körs.