Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die Datenmigration ist ein entscheidender Aspekt beim Verschieben von MySQL-Datenbanken von lokalen Umgebungen in Azure Database for MySQL. In diesem Artikel werden Schwierigkeiten bei der Datenmigration beschrieben und ein umfassender Leitfaden für die verschiedenen Techniken und bewährten Methoden gegeben, um eine nahtlose Datenübertragung zu gewährleisten. Sie können Ihre Migrationsstrategie effektiv planen und ausführen, indem Sie die verschiedenen Datenmigrationsmethoden wie die logische und physische Migration verstehen und potenzielle Herausforderungen wie Datenintegrität und Downtime bewältigen. In diesem Leitfaden erhalten Sie das erforderliche Wissen, um große Datasets zu verarbeiten, Unterbrechungen zu minimieren und die robusten Features von Azure zu verwenden, um die Leistung und Zuverlässigkeit Ihrer Datenbank zu optimieren. Unabhängig davon, ob Sie Ihre Infrastruktur modernisieren oder Ihre Datenverwaltungsfunktionen verbessern möchten, bietet dieser Artikel die für eine erfolgreiche Datenmigration erforderlichen Erkenntnisse.
Voraussetzungen
Migrieren einer lokalen MySQL-Instanz zur Azure Database for MySQL: Leistungsbaselines
Sichern der Datenbank
Vor dem Upgrade oder der Migration von Daten ist es sinnvoll, die Datenbank mithilfe von MySQL Workbench oder manuell über den Befehl mysqldump zu exportieren.
Offline im Vergleich zu Online
Vor der Auswahl eines Migrationstools sollte bestimmt werden, ob die Migration online oder offline erfolgen soll.
Bei Offlinemigrationen ist das System während der Migration nicht verfügbar. Bei dieser Option wird sichergestellt, dass keine Transaktionen ausgeführt werden und der Zustand der Daten genau dem entspricht, der bei der Wiederherstellung in Azure zu erwarten ist.
Bei Onlinemigrationen werden die Daten nahezu in Echtzeit migriert. Diese Option ist geeignet, wenn es für die Benutzer oder Anwendungen, die die Datenworkload nutzen, nur zu kurzen Ausfallzeiten kommen darf. Der Prozess umfasst die Replikation der Daten mit einer Replikationsmethode wie
binlogo. ä.
Die Umgebung von WWI weist einige komplexe Netzwerk- und Sicherheitsanforderungen auf, die nicht zulassen, dass die entsprechenden Änderungen für eingehende und ausgehende Verbindungen im gewünschten Migrationszeitrahmen übernommen werden. Aufgrund dieser Komplexitäten und Anforderungen kommt eine Onlinemigration nicht in Betracht.
Hinweis
Weitere Informationen zur Offline- und Onlinemigration finden Sie in den Abschnitten zu Planung und Bewertung.
Datendrift
In Offlinemigrationsstrategien kann es potenziell zu einer Datendrift kommen. Datendrift tritt auf, wenn neu geänderte Quelldaten nicht mehr mit migrierten Daten synchron sind. In diesem Fall ist ein vollständiger Export oder Deltaexport erforderlich. Sie können dieses Problem mildern, indem Sie den gesamten Datenverkehr an die Datenbank beenden und dann den Export durchführen. Wenn das Beenden des gesamten Datenänderungsverkehrs nicht möglich ist, müssen Sie die Drift berücksichtigen.
Die Ermittlung der Änderungen kann kompliziert werden, wenn die Datenbanktabellen keine Spalten wie numerische Primärschlüssel aufweisen oder in jeder Tabelle, die migriert werden muss, keinerlei Änderungs- und Erstellungsdatum vorhanden ist.
Wenn beispielsweise ein numerischer Primärschlüssel vorhanden ist und der Import der Migration in der Sortierreihenfolge erfolgt, ist es relativ einfach, zu ermitteln, wo der Import beendet wurde, und den Import von dieser Stelle aus neu zu starten. Wenn kein numerischer Schlüssel vorhanden ist, besteht die Möglichkeit, ein Änderungs- und Erstellungsdatum zu verwenden und den Import wiederum in der Sortierreihenfolge durchzuführen, sodass die Migration ab dem letzten im Ziel vorhandenen Datum neu gestartet werden kann.
Empfehlungen zur Leistung
Exportieren
Verwenden Sie ein Exporttool, das in einem Multithreadmodus ausgeführt werden kann, z. B. mydumper.
Verwenden Sie bei Verwendung von MySQL 8.0 ggf. partitionierte Tabellen, um die Geschwindigkeit von Exporten zu erhöhen.
Importieren
Erstellen Sie nach dem Laden der Daten gruppierte Indizes und Primärschlüssel. Laden Sie Daten in Primärschlüsselreihenfolge oder in einer anderen Sortierreihenfolge, wenn der Primärschlüssel eine Datumsspalte ist (z. B. Änderungsdatum oder Erstellungsdatum).
Warten Sie mit der Erstellung sekundärer Indizes, bis die Daten vollständig geladen wurden. Erstellen Sie alle sekundären Indizes nach dem Laden.
Deaktivieren Sie vor dem Laden Fremdschlüsseleinschränkungen. Das Deaktivieren von Fremdschlüsselüberprüfungen führt zu erheblichen Leistungssteigerungen. Aktivieren Sie die Einschränkungen, und überprüfen Sie die Daten nach dem Laden, um die referentielle Integrität sicherzustellen.
Laden Sie Daten parallel. Vermeiden Sie zu viel Parallelität, da dies zu Ressourcenkonflikten führen kann, und überwachen Sie die Ressourcen mit den Metriken, die im Azure-Portal verfügbar sind.
Durchführen der Migration
Sichern der Datenbank
Erstellen und Überprüfen der Azure-Zielzone
Konfigurieren der Quellserverparameter
Konfigurieren der Zielserverparameter
Exportieren der Datenbankobjekte (Schema, Benutzer usw.)
Exportieren der Daten
Importieren der Datenbankobjekte
Importieren der Daten
Überprüfen
Zurücksetzen der Zielserverparameter
Migrieren einzelner oder mehrerer Anwendungen
Allgemeine Schritte
Unabhängig von jeweils verwendeten Pfads gibt es allgemeine Schritte, die durchgeführt werden müssen:
Durchführen eines Upgrades auf eine unterstützte Azure MySQL-Version
Inventarisieren von Datenbankobjekten
Exportieren von Benutzern und Berechtigungen
Migrieren zur neuesten MySQL-Version
Da die WWI Conference-Datenbank Version 5.5 verwendet, muss ein Upgrade durchgeführt werden. Der CIO hat gefordert, ein Upgrade auf die neueste Version von MySQL (derzeit 8.0) durchzuführen.
Es gibt zwei Upgrademöglichkeiten auf Version 8.0:
Direkt
Exportieren/Importieren
Bei der Entscheidung, ein Upgrade durchzuführen, muss unbedingt das Tool zur Upgradeprüfung (upgrade checker) ausgeführt werden, um festzustellen, ob Konflikte vorliegen. Beim Upgrade auf MySQL Server 8.0 überprüft das Tool beispielsweise, ob folgende Konflikte vorhanden sind:
Datenbankobjektnamen, die mit reservierten Wörtern in MySQL 8.0 in Konflikt stehen
Verwendung des utf8mb3-Zeichensatzes
Verwendung der ZEROFILL-/Anzeigelängentypattribute
Tabellennamen, die mit Tabellen in 8.0 in Konflikt stehen
Verwendung temporaler Typen
Namen von Fremdschlüsseleinschränkungen, die länger als 64 Zeichen sind
Wenn die Upgradeprüfung keine Probleme meldet, kann problemlos ein direktes Upgrade durchgeführt werden, indem MySQL-Binärdateien ersetzt werden. Datenbanken mit Problemen müssen exportiert, und die Probleme müssen behoben werden.
WWI-Szenario
Nach der erfolgreichen Migration der MySQL-Instanz zu 8.0 hat das WWI-Migrationsteam festgestellt, dass der ursprüngliche Migrationspfad aus Migrieren von lokalen MySQL-Instanzen zu Azure Database for MySQL nicht mehr verwendet werden konnte, da das DMS-Tool derzeit nur die Version 5.6 und 5.7 unterstützt. Für DMS ist Netzwerkzugriff erforderlich. Das WWI-Migrationsteam war noch nicht in der Lage, die komplexen Netzwerkprobleme zu beheben. Aufgrund dieser Umgebungsprobleme wurde die möglichen Migrationstools auf MySQL Workbench eingeschränkt.
Datenbankobjekte
Wie im Abschnitt zu Testplänen beschrieben, sollte vor und nach der Migration ein Inventar der Datenbankobjekte erstellt werden, um sicherzustellen, dass alles migriert wurde.
Wenn Sie eine gespeicherte Prozedur ausführen möchten, um diese Informationen zu generieren, können Sie eine ähnliche gespeicherte Prozedur wie folgende verwenden:
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');
- Wenn Sie diese Prozedur für die Quelldatenbank aufrufen, wird die folgende (gekürzte) Ausgabe angezeigt:
- Das Ergebnis der Prozedur für die Zieldatenbank sollte nach Durchführung der Migration ähnlich wie folgt aussehen. Beachten Sie, dass in der Datenbank keine Funktionen vorhanden sind. Funktionen wurden vor der Migration entfernt.
Benutzer und Berechtigungen
Für eine erfolgreiche Migration müssen die zugehörigen Benutzer und Berechtigungen in die Zielumgebung migriert werden.
Exportieren Sie alle Benutzer mit den jeweils zugewiesenen Berechtigungen mithilfe des folgenden PowerShell-Skripts:
$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
}
Erstellen Sie ein neues PowerShell-Skript mithilfe der PowerShell ISE (siehe Setupdokument).
Legen Sie Ihren Benutzernamen auf „root“ und Ihr Kennwort auf das Kennwort des root-Benutzers fest.
Anschließend können Sie das Skript AllGrants.sql für die neue Azure Database for MySQL-Instanz ausführen:
$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"
}
Sie können benutzer auch in der Azure-Datenbank für MySQL mithilfe von PowerShell erstellen: /azure/mysql/howto-create-users
Ausführen der Migration
Wenn die grundlegenden Migrationskomponenten vorhanden sind, ist es jetzt möglich, mit der Datenmigration fortzufahren. Zuvor wurden mehrere Tools und Methoden vorgestellt. Für WWI verwendet es den MySQL Workbench-Pfad, um die Daten zu exportieren und dann in Azure Database for MySQL zu importieren.
Checkliste für die Datenmigration
Ermitteln Sie die Komplexität der Umgebung und die Möglichkeit einer Onlinemigration.
Berücksichtigen Sie die Datendrift. Das Beenden des Datenbankdiensts kann eine mögliche Datendrift beseitigen.
Konfigurieren Sie die Quellparameter für schnellen Export.
Konfigurieren Sie die Zielparameter für schnellen Import.
Testen Sie Migrationen, die eine andere Quellversion als das Ziel aufweisen.
Migrieren Sie alle nicht datenbasierten Objekte wie Benutzernamen und Berechtigungen.
Achten Sie darauf, dass alle Aufgaben dokumentiert und abgehakt werden, während die Migration ausgeführt wird.