MySQL-Quelldatenbank für kontinuierliche Migrationen konfigurieren

Auf dieser Seite wird beschrieben, wie Sie die folgenden Quelldatenbankinstanzen für kontinuierliche homogene MySQL-Migrationen konfigurieren:

Cloud SQL for MySQL-Quelle konfigurieren

So konfigurieren Sie eine Cloud SQL for MySQL-Quellinstanz für den Migrationsprozess:

  1. Prüfen Sie, ob Ihre Quelldatenbank Metadaten enthält, die von Nutzern mit der DEFINER-Klausel definiert wurden. Weitere Informationen finden Sie unter Metadaten mit einer DEFINER-Klausel überprüfen.

    Mit Database Migration Service für homogene MySQL-Migrationen werden keine Nutzerkonten und Anmeldedaten migriert. Quellen, die Metadaten enthalten, die von Nutzerkonten mit der DEFINER-Klausel definiert wurden, können die Migration blockieren.

  2. Wenn Ihre Quelldatenbank Objekte enthält, die auf Tabellen in den Systemschemata mysql, performance_schema, information_schema, ndbinfo oder sys verweisen, müssen die Replikatdatenbanken auch diese Systemschematabellen enthalten.

    Wenn die Replikatdatenbanken diese Tabellen nicht enthalten, schlägt der Migrationsjob möglicherweise mit dem Fehler Unknown table in system schema fehl.

  3. Aktivieren und konfigurieren Sie Binärlogs in Ihrer Quelldatenbank.

    In Cloud SQL for MySQL wird das binäre Logging automatisch aktiviert, wenn Sie die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) verwenden. Sie können das Logformat und den Aufbewahrungszeitraum mit den in Cloud SQL verfügbaren System-Flags konfigurieren. Gehen Sie dazu so vor:

    1. Aktivieren Sie die Wiederherstellung zu einem bestimmten Zeitpunkt auf Ihrer Instanz. Mit diesem Feature wird das binäre Logging automatisch aktiviert. Es ist nicht möglich, binäres Logging ohne PITR in Cloud SQL zu aktivieren. Weitere Informationen finden Sie in der Cloud SQL-Dokumentation unter Wiederherstellung zu einem bestimmten Zeitpunkt.
    2. Verwenden Sie Cloud SQL-Flags, um die Logging-Konfiguration anzupassen. Weitere Informationen finden Sie in der Cloud SQL-Dokumentation unter Datenbank-Flags konfigurieren.
      1. Database Migration Service erfordert, dass binlog_format auf ROW gesetzt ist. Sie müssen diese Einstellung nicht anpassen, da Cloud SQL for MySQL das Flag binlog_format automatisch auf ROW festlegt.
      2. Legen Sie die Aufbewahrungsdauer für Logs auf einen ausreichend langen Zeitraum fest, um die Datenbankmigration zu ermöglichen. In der Regel ist eine Woche ausreichend. Verwenden Sie eines der folgenden Flags:
        • MySQL 5.6–5.7: expire_logs_days
        • MySQL 8.0 und höher: expire_logs_days, binlog_expire_logs_seconds

  4. Erstellen Sie in Ihrer Instanz ein dediziertes Nutzerkonto für die Migration. Weitere Informationen finden Sie in der Cloud SQL-Dokumentation unter Nutzer erstellen. Sie müssen Folgendes sicherstellen:

    • Sie erlauben dem dedizierten Nutzerkonto, von jedem Host (host=%) aus eine Verbindung herzustellen.
    • Das Passwort für das Konto darf nicht länger als 32 Zeichen sein. Weitere Informationen zu den Einschränkungen der MySQL-Nutzerpasswortlänge finden Sie unter MySQL Bug #43439.

  5. Weisen Sie dem dedizierten Migrationsnutzerkonto die erforderlichen Berechtigungen zu. Bei kontinuierlichen Migrationen hängt die vollständige Liste der erforderlichen Berechtigungen davon ab, ob Sie eigene Dump-Dateien bereitstellen oder die von Database Migration Service verwaltete Dump-Funktion verwenden:

    Verwalteter Dump

    Wenn Database Migration Service automatisch den vollständigen Dump Ihrer Quelldatenbank erstellen soll, weisen Sie dem Nutzerkonto die folgenden Berechtigungen zu:

    Manueller Dump

    Wenn Sie eigene Dumpdateien bereitstellen, die mit mysqldump erstellt wurden, müssen Sie die für die CDC-Phase erforderlichen Berechtigungen angeben:

Selbst gehostete MySQL-Quelle konfigurieren

So konfigurieren Sie eine selbst gehostete MySQL-Quellinstanz für den Migrationsprozess:

  1. Achten Sie darauf, dass alle Tabellen (außer Tabellen in Systemdatenbanken) die InnoDB-Speicher-Engine verwenden. Wenn Sie eine andere Speichereinheit verwenden, müssen Sie Ihre Tabellen möglicherweise konvertieren. Weitere Informationen finden Sie unter Tabellen von MyISAM zu InnoDB konvertieren.
  2. Prüfen Sie, ob Ihre Quelldatenbank Metadaten enthält, die von Nutzern mit der DEFINER-Klausel definiert wurden. Weitere Informationen finden Sie unter Metadaten mit einer DEFINER-Klausel prüfen.

    Mit Database Migration Service für homogene MySQL-Migrationen werden keine Nutzerkonten und Anmeldedaten migriert. Quellen, die Metadaten enthalten, die von Nutzerkonten mit der DEFINER-Klausel definiert wurden, können Ihre Migration blockieren.

  3. Wenn Ihre Quelldatenbank Objekte enthält, die auf Tabellen in den Systemschemas mysql, performance_schema, information_schema, ndbinfo oder sys verweisen, müssen die Replikatdatenbanken diese Systemschematabellen ebenfalls enthalten.

    Wenn die Replikatdatenbanken diese Tabellen nicht enthalten, schlägt der Migrationsjob möglicherweise mit dem Fehler Unknown table in system schema fehl.

  4. Konfigurieren Sie die Einstellung server-id auf einen Wert von 1 oder höher. Weitere Informationen finden Sie unter Optionen und Variablen für Replikation und binäres Logging.

  5. Achten Sie darauf, dass GTID_MODE auf ON oder OFF festgelegt ist. Andere Werte werden nicht unterstützt.

    Database Migration Service erfordert, dass GTID_MODE in den folgenden Szenarien auf ON festgelegt ist:

    Weitere Informationen zu GTID_MODE finden Sie unter Systemvariable für globale Transaktions-ID.

  6. Aktivieren und konfigurieren Sie Binärlogs in Ihrer Quelldatenbank. Gehen Sie dazu so vor:

      • Aktivieren Sie Binärlogs in der Quelldatenbank.
      • Setzen Sie binlog_format auf 'ROW'. Weitere Informationen finden Sie unter Zeilenbasiertes Binär-Logging.
      • Legen Sie die Aufbewahrungsdauer für Logs auf einen ausreichend langen Zeitraum fest, um die Datenbankmigration zu ermöglichen. In der Regel ist eine Woche ausreichend. Verwenden Sie eines der folgenden Flags:
        • MySQL 5.5–5.7: expire_logs_days
        • MySQL 8.0: expire_logs_days, binlog_expire_logs_seconds

  7. Erstellen Sie in Ihrer Instanz ein dediziertes Nutzerkonto für die Migration. Weitere Informationen finden Sie unter Account management statements. Sie müssen Folgendes sicherstellen:

    • Sie erlauben dem dedizierten Nutzerkonto, von jedem Host (host=%) aus eine Verbindung herzustellen.
    • Das Passwort für das Konto darf nicht länger als 32 Zeichen sein. Weitere Informationen zu den Einschränkungen der Passwortlänge für MySQL-Nutzer finden Sie unter MySQL-Fehler Nr. 43439.

  8. Weisen Sie dem dedizierten Migrationsnutzerkonto die erforderlichen Berechtigungen zu. Bei kontinuierlichen Migrationen hängt die vollständige Liste der erforderlichen Berechtigungen davon ab, ob Sie Ihre eigenen Dumpdateien bereitstellen oder die von Database Migration Service verwaltete Dumpfunktion verwenden:

    Verwalteter Dump

    Wenn Database Migration Service automatisch den vollständigen Dump Ihrer Quelldatenbank erstellen soll, weisen Sie dem Nutzerkonto die folgenden Berechtigungen zu:

    Manueller Dump

    Wenn Sie eigene mit mysqldump erstellte Dumpdateien bereitstellen, müssen Sie die für die CDC-Phase erforderlichen Berechtigungen angeben:

Amazon RDS for MySQL-Quelle konfigurieren

So konfigurieren Sie eine Amazon RDS for MySQL-Quellinstanz für den Migrationsprozess:

  1. Amazon RDS for MySQL verwendet standardmäßig die InnoDB-Speicher-Engine, ermöglicht aber die Verwendung anderer Speicher-Engines. Achten Sie darauf, dass alle Ihre Tabellen (mit Ausnahme von Tabellen in Systemdatenbanken) die InnoDB-Speicher-Engine verwenden. Wenn Sie eine andere Speichereinheit verwenden, müssen Sie Ihre Tabellen möglicherweise konvertieren. Weitere Informationen finden Sie unter Tabellen von MyISAM zu InnoDB konvertieren.
  2. Prüfen Sie, ob Ihre Quelldatenbank Metadaten enthält, die von Nutzern mit der Klausel DEFINER definiert wurden. Weitere Informationen finden Sie unter Metadaten mit einer DEFINER-Klausel prüfen.

    Der Database Migration Service für homogene MySQL-Migrationen migriert keine Nutzerkonten und Anmeldedaten. Quellen, die Metadaten enthalten, die von Nutzerkonten mit der DEFINER-Klausel definiert wurden, können die Migration blockieren.

  3. Wenn Ihre Quelldatenbank Objekte enthält, die auf Tabellen in den Systemschemas mysql, performance_schema, information_schema, ndbinfo oder sys verweisen, müssen die Replikatdatenbanken diese Systemschematabellen ebenfalls enthalten.

    Wenn die Replikatdatenbanken diese Tabellen nicht enthalten, schlägt der Migrationsjob möglicherweise mit dem Fehler Unknown table in system schema fehl.

  4. Achten Sie darauf, dass GTID_MODE auf ON oder OFF festgelegt ist. Andere Werte werden nicht unterstützt. Amazon RDS for MySQL verwendet standardmäßig GTID_MODE = OFF.

    In den folgenden Szenarien muss GTID_MODE in Database Migration Service auf ON gesetzt sein:

    Weitere Informationen zu GTID_MODE finden Sie unter Systemvariable für globale Transaktions-ID.

  5. Prüfen und konfigurieren Sie Binärlogs in Ihrer Quelldatenbank. Gehen Sie dazu so vor:

    1. Achten Sie darauf, dass Ihre Instanz automatische Sicherungen verwendet. Amazon RDS generiert Binärlogs nur, wenn automatische Backups aktiviert sind. Weitere Informationen finden Sie in der Amazon RDS-Dokumentation unter Automatische Sicherungen aktivieren.

    2. Legen Sie die Aufbewahrungsdauer für Logs auf einen ausreichend langen Zeitraum fest, um die Datenbankmigration zu ermöglichen. In der Regel ist eine Woche ausreichend. Weitere Informationen finden Sie in der Amazon RDS-Dokumentation unter Binärlogkonfiguration festlegen und anzeigen.

    3. Starten Sie den Server neu, damit die vorgenommenen Änderungen wirksam werden.

  6. Erstellen Sie in Ihrer Instanz ein dediziertes Nutzerkonto für die Migration. Weitere Informationen finden Sie unter Account management statements. Sie müssen Folgendes sicherstellen:

    • Sie erlauben dem dedizierten Nutzerkonto, von jedem Host (host=%) aus eine Verbindung herzustellen.
    • Das Passwort für das Konto darf nicht länger als 32 Zeichen sein. Weitere Informationen zu den Einschränkungen der Passwortlänge für MySQL-Nutzer finden Sie unter MySQL-Fehler Nr. 43439.

  7. Weisen Sie dem dedizierten Migrationsnutzerkonto die erforderlichen Berechtigungen zu. Bei kontinuierlichen Migrationen hängt die vollständige Liste der erforderlichen Berechtigungen davon ab, ob Sie Ihre eigenen Dumpdateien bereitstellen oder die von Database Migration Service verwaltete Dumpfunktion verwenden:

    Verwalteter Dump

    Wenn Sie möchten, dass Database Migration Service automatisch den vollständigen Dump Ihrer Quelldatenbank erstellt, weisen Sie dem Nutzerkonto die folgenden Berechtigungen zu:

    Manueller Dump

    Wenn Sie eigene mit mysqldump erstellte Dumpdateien bereitstellen, müssen Sie die für die CDC-Phase erforderlichen Berechtigungen angeben:

Amazon Aurora for MySQL-Quelle konfigurieren

So konfigurieren Sie eine Amazon Aurora for MySQL-Quellinstanz für den Migrationsprozess:

  1. Prüfen Sie, ob Ihre Quelldatenbank Metadaten enthält, die von Nutzern mit der DEFINER-Klausel definiert wurden. Weitere Informationen finden Sie unter Metadaten mit einer DEFINER-Klausel prüfen.

    Mit Database Migration Service für homogene MySQL-Migrationen werden keine Nutzerkonten und Anmeldedaten migriert. Quellen, die Metadaten enthalten, die von Nutzerkonten mit der DEFINER-Klausel definiert wurden, können Ihre Migration blockieren.

  2. Wenn Ihre Quelldatenbank Objekte enthält, die auf Tabellen in den Systemschemas mysql, performance_schema, information_schema, ndbinfo oder sys verweisen, müssen die Replikatdatenbanken diese Systemschematabellen ebenfalls enthalten.

    Wenn die Replikatdatenbanken diese Tabellen nicht enthalten, schlägt der Migrationsjob möglicherweise mit dem Fehler Unknown table in system schema fehl.

  3. Achten Sie darauf, dass GTID_MODE auf ON oder OFF festgelegt ist. Andere Werte werden nicht unterstützt. Amazon Aurora for MySQL verwendet standardmäßig GTID_MODE = OFF.

    In den folgenden Szenarien muss GTID_MODE in Database Migration Service auf ON gesetzt sein:

    Weitere Informationen zu GTID_MODE finden Sie unter Systemvariable für globale Transaktions-ID.

  4. Aktivieren und konfigurieren Sie Binärlogs in Ihrer Quelldatenbank. Gehen Sie dazu so vor:

    1. Binäres Logging für Ihre MySQL-Datenbank aktivieren.

    2. Legen Sie die Aufbewahrungsdauer für Logs auf einen ausreichend langen Zeitraum fest, um die Datenbankmigration zu ermöglichen. In der Regel ist eine Woche ausreichend. Weitere Informationen finden Sie unter Konfiguration des binären Logs festlegen und anzeigen.

    3. Starten Sie den Server neu, damit die vorgenommenen Änderungen wirksam werden.

  5. Erstellen Sie in Ihrer Instanz ein dediziertes Nutzerkonto für die Migration. Weitere Informationen finden Sie unter Account Management Statements. Sie müssen Folgendes sicherstellen:

    • Sie erlauben dem dedizierten Nutzerkonto, von jedem Host (host=%) aus eine Verbindung herzustellen.
    • Das Passwort für das Konto darf nicht länger als 32 Zeichen sein. Weitere Informationen zu den Einschränkungen der Passwortlänge für MySQL-Nutzer finden Sie unter MySQL-Fehler Nr. 43439.

  6. Weisen Sie dem dedizierten Migrationsnutzerkonto die erforderlichen Berechtigungen zu. Bei kontinuierlichen Migrationen hängt die vollständige Liste der erforderlichen Berechtigungen davon ab, ob Sie eigene Dump-Dateien bereitstellen oder die von Database Migration Service verwaltete Dump-Funktion verwenden:

    Verwalteter Dump

    Wenn Sie möchten, dass Database Migration Service automatisch den vollständigen Dump Ihrer Quelldatenbank erstellt, weisen Sie dem Nutzerkonto die folgenden Berechtigungen zu:

    Manueller Dump

    Wenn Sie eigene mysqldump-Dumpdateien bereitstellen, müssen Sie die für die CDC-Phase erforderlichen Berechtigungen angeben:

Microsoft Azure Database for MySQL-Quelle konfigurieren

So konfigurieren Sie eine Microsoft Azure Database for MySQL-Quellinstanz für den Migrationsprozess:

  1. Prüfen Sie, ob Ihre Quelldatenbank Metadaten enthält, die von Nutzern mit der Klausel DEFINER definiert wurden. Weitere Informationen finden Sie unter Metadaten mit einer DEFINER-Klausel prüfen.

    Der Database Migration Service für homogene MySQL-Migrationen migriert keine Nutzerkonten und Anmeldedaten. Quellen, die Metadaten enthalten, die von Nutzerkonten mit der DEFINER-Klausel definiert wurden, können die Migration blockieren.

  2. Wenn Ihre Quelldatenbank Objekte enthält, die auf Tabellen in den Systemschemas mysql, performance_schema, information_schema, ndbinfo oder sys verweisen, müssen die Replikatdatenbanken diese Systemschematabellen ebenfalls enthalten.

    Wenn die Replikatdatenbanken diese Tabellen nicht enthalten, schlägt Ihr Migrationsjob möglicherweise mit dem Fehler Unknown table in system schema fehl.

  3. Achten Sie darauf, dass GTID_MODE auf ON oder OFF festgelegt ist. Andere Werte werden nicht unterstützt. Microsoft Azure Database for MySQL verwendet standardmäßig GTID_MODE = OFF.

    Database Migration Service erfordert, dass GTID_MODE in den folgenden Szenarien auf ON festgelegt ist:

    Weitere Informationen zu GTID_MODE finden Sie unter Systemvariable für globale Transaktions-ID.

  4. Überprüfen und konfigurieren Sie die Einstellungen für das binäre Logging in Ihrer Quelldatenbank. Gehen Sie dazu so vor:

    1. Das binäre Logging ist in Microsoft Azure Database for MySQL standardmäßig aktiviert. Sie müssen es nicht aktivieren, aber prüfen Sie, ob das Feature aktiviert ist. Weitere Informationen finden Sie in der Microsoft-Dokumentation.

    2. Legen Sie binlog_expire_logs_seconds auf einen ausreichend langen Zeitraum fest, um die Datenbankmigration zu ermöglichen. In der Regel reicht eine Woche aus.

      Weitere Informationen finden Sie unter Serverparameter in Azure Database for MySQL konfigurieren und zum Parameter binlog_expire_logs_seconds in der Microsoft-Dokumentation.

    3. Starten Sie den Server neu, damit die vorgenommenen Änderungen wirksam werden.

  5. Prüfen Sie den Wert Ihrer Einstellung require_secure_transport.

    Standardmäßig ist für alle eingehenden Verbindungen zu Microsoft Azure-Datenbanken eine SSL/TLS-Verschlüsselung erforderlich. Verwenden Sie je nach require_secure_transport-Wert eine der folgenden Verschlüsselungseinstellungen, wenn Sie das Quellverbindungsprofil erstellen:

    • Wenn require_secure_transport auf on gesetzt ist, wählen Sie Basic, TLS oder mTLS aus.
    • Wenn require_secure_transport auf off gesetzt ist, wählen Sie Keine aus.

  6. Erstellen Sie in Ihrer Instanz ein dediziertes Nutzerkonto für die Migration. Weitere Informationen finden Sie unter Account management statements. Sie müssen Folgendes sicherstellen:

    • Sie erlauben dem dedizierten Nutzerkonto, von jedem Host (host=%) aus eine Verbindung herzustellen.
    • Das Passwort für das Konto darf nicht länger als 32 Zeichen sein. Weitere Informationen zu den Einschränkungen der Passwortlänge für MySQL-Nutzer finden Sie unter MySQL-Fehler Nr. 43439.

  7. Weisen Sie dem dedizierten Migrationsnutzerkonto die erforderlichen Berechtigungen zu. Bei kontinuierlichen Migrationen hängt die vollständige Liste der erforderlichen Berechtigungen davon ab, ob Sie eigene Dump-Dateien bereitstellen oder die von Database Migration Service verwaltete Dump-Funktion verwenden:

    Verwalteter Dump

    Wenn Database Migration Service automatisch den vollständigen Dump Ihrer Quelldatenbank erstellen soll, weisen Sie dem Nutzerkonto die folgenden Berechtigungen zu:

    Manueller Dump

    Wenn Sie eigene mit mysqldump erstellte Dumpdateien bereitstellen, müssen Sie die für die CDC-Phase erforderlichen Berechtigungen angeben:

Nächste Schritte

Eine vollständige, detaillierte Migrationsanleitung für homogene Cloud SQL for MySQL-Migrationen finden Sie unter Erste Schritte mit Cloud SQL for MySQL-Migrationen.