Quelle konfigurieren

MySQL   |  PostgreSQL   |  PostgreSQL zu AlloyDB

Übersicht

Database Migration Service unterstützt einmalige und kontinuierliche Migrationen von Quelldatenbanken zu Cloud SQL-Zieldatenbanken.

Zu den unterstützten Quelldatenbanken für MySQL gehören:

• Amazon RDS 5.6, 5.7, 8.0, 8.4
• Selbstverwaltetes MySQL 5.5, 5.6, 5.7, 8.0, 8.4 (lokal oder auf einer vollständig von Ihnen verwalteten Cloud-VM)
• Cloud SQL for MySQL 5.6, 5.7, 8.0, 8.4
• Amazon Aurora 5.6, 5.7, 8.0, 8.4
• Microsoft Azure Database for MySQL 5.7, 8.0, 8.4

Für MySQL 8.0-Quellen unterstützt Database Migration Service auch die folgenden Nebenversionen: 8.0.18, 8.0.26, 8.0.27, 8.0.28, 8.0.30, 8.0.31, 8.0.32, 8.0.33, 8.0.34, 8.0.35, 8.0.36, 8.0.37, 8.0.39, 8.0.40, 8.0.41, 8.0.42, 8.0.43.

Führen Sie die folgenden Schritte aus, um eine Quelldatenbank zu konfigurieren:

1. Für Cloud SQL-Quellen:Wenn Sie von einer Cloud SQL-Instanz migrieren, die eine private IP-Verbindung verwendet, zu einer Cloud SQL-Instanz, die einen IP-Bereich außerhalb des RFC 1918-Bereichs verwendet, fügen Sie den Bereich außerhalb des RFC 1918-Bereichs der Netzwerkkonfiguration Ihrer Cloud SQL-Quellinstanz hinzu. Weitere Informationen finden Sie in der Cloud SQL-Dokumentation unter Autorisierte Netzwerke konfigurieren.
2. Bevor Sie Daten aus der Quelldatenbank in die Zieldatenbank migrieren, müssen Sie alle DDL-Schreibvorgänge (Data Definition Language, Datendefinitionssprache) während der vollständigen Dump-Phase beenden. Sie können ein Skript verwenden, um zu prüfen, ob DDL-Vorgänge beendet wurden. Nachdem die Migration in die CDC-Phase eingetreten ist, können Sie DDL-Vorgänge fortsetzen.
3. Achten Sie darauf, dass Ihre Quelldatenbank keine Metadaten enthält, die von Nutzern mit der DEFINER-Klausel definiert wurden. Weitere Informationen finden Sie unter MySQL-Migrationsjob mit Metadaten mit DEFINER-Klausel erstellen und ausführen.
4. 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 Ihr Migrationsjob möglicherweise mit dem Fehler Unknown table in system schema fehl.

5. Sie müssen die Option server-id auf einen Wert von mindestens 1 festlegen. Weitere Informationen finden Sie unter Optionen und Variablen für Replikation und binäres Logging.
6. Konfigurieren Sie das Logging von globalen Transaktions-IDs (GTIDs), indem Sie GTID_MODE auf ON oder OFF festlegen. Der GTID_MODE-Wert ON_PERMISSIVE wird nicht unterstützt.

   Welchen Wert Sie verwenden sollten, hängt von den Migrationsanforderungen ab:

   • Wenn Sie zu einer vorhandenen Zielinstanz migrieren, für die Lesereplikate aktiviert sind, legen Sie GTID_MODE auf ON fest.
   • Wenn Sie Ihre Daten mit einem manuellen Dump migrieren, legen Sie GTID_MODE auf ON fest.
   Weitere Informationen zu GTID_MODE finden Sie unter Globale Transaktions-ID-Systemvariable.

7. Sie müssen das Nutzerkonto, das für die Verbindung zur Quelldatenbank verwendet wird, so konfigurieren, dass Verbindungen von einem beliebigen Ort (Host = %) akzeptiert werden. Der Zugriff kann in einem späteren Schritt auf diesen Nutzer beschränkt werden.

   Es empfiehlt sich, ein separates Konto zu erstellen, um das Risiko der Manipulation anderer Aspekte der Datenbank zu reduzieren.

   Es gibt vier Arten von Kombinationen aus Migrationen und Dumps:

   • Typ 1: Kontinuierliche Migration und verwalteter Dump
   • Typ 2: Kontinuierliche Migration und manueller Dump
   • Typ 3: Einmalige Migration und verwalteter Dump
   • Typ 4: Einmalige Migration und manueller Dump

   Die Berechtigungen für die einzelnen Migrations- und Dump-Kombinationen sind auf den folgenden Tabs aufgeführt.

   Typ 1

   Das von Ihnen konfigurierte Nutzerkonto benötigt folgende Berechtigungen:

   • REPLICATION SLAVE
   • EXECUTE
   • SELECT
   • SHOW VIEW
   • REPLICATION CLIENT
   • RELOAD
   • TRIGGER
   • (Nur für die Migration von Amazon RDS und Amazon Aurora) LOCK TABLES

   MySQL-Version 8.0 oder höher:Achten Sie für eine optimale Leistung darauf, dass Sie diesem Konto nicht die Berechtigung BACKUP_ADMIN gewähren.

   Weitere Informationen zu Berechtigungen finden Sie unter Von MySQL gewährte Berechtigungen. Weitere Informationen zu Nutzerkonten finden Sie unter MySQL-Nutzerkontoformat.

   Typ 2

   Das von Ihnen konfigurierte Nutzerkonto benötigt folgende Berechtigungen:

   • REPLICATION SLAVE
   • EXECUTE

   Weitere Informationen zu Berechtigungen finden Sie unter Von MySQL gewährte Berechtigungen. Weitere Informationen zu Nutzerkonten finden Sie unter MySQL-Nutzerkontoformat.

   Typ 3

   Das von Ihnen konfigurierte Nutzerkonto benötigt folgende Berechtigungen:

   • SELECT
   • SHOW VIEW
   • TRIGGER
   • (Nur für die Migration von Amazon RDS und Amazon Aurora) LOCK TABLES
   • (Nur für die Migration von Quellen mit der Einstellung GTID_MODE = ON)RELOAD

   MySQL-Version 8.0 oder höher:Achten Sie für eine optimale Leistung darauf, dass Sie diesem Konto nicht die Berechtigung BACKUP_ADMIN gewähren.

   Weitere Informationen zu Berechtigungen finden Sie unter Von MySQL gewährte Berechtigungen. Weitere Informationen zu Nutzerkonten finden Sie unter MySQL-Nutzerkontoformat.

   Typ 4

   Es sind keine Berechtigungen erforderlich.

   Weitere Informationen zu Berechtigungen finden Sie unter Von MySQL gewährte Berechtigungen. Weitere Informationen zu Nutzerkonten finden Sie unter MySQL-Nutzerkontoformat.

8. Bevor Sie Binärlogs konfigurieren, müssen Sie Folgendes sicherstellen:
   • Aktivieren Sie binäre Logs in Ihrer Quelldatenbank.
   • Verwenden Sie zeilenbasiertes binäres Logging.
   • Bewahren Sie binäre Logs für einen ausreichend langen Zeitraum auf, wie er für die Datenbankmigration erforderlich ist. In der Regel ist eine Woche ausreichend.

   Erweitern Sie den Abschnitt für Ihre Quelle, um Binärlogs zu konfigurieren:

   Selbst gehostetes MySQL

   Geben Sie je nach MySQL-Version einen Zeitraum an, der ausreichend Zeit für die Replikation bietet:

   • MySQL 5.5 – 5.7: expire_logs_days
   • MySQL 8.0: expire_logs_days, binlog_expire_logs_seconds

   Microsoft Azure Database for MySQL

   Das binäre Logging ist in Microsoft Azure Database for MySQL standardmäßig aktiviert. Sie müssen es nicht aktivieren. Weitere Informationen finden Sie in der Microsoft-Dokumentation.

   Konfigurieren Sie die folgenden erforderlichen Parameter:

   1. Legen Sie binlog_expire_logs_seconds auf einen Zeitraum fest, der für die Datenbankmigration lang genug ist.

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

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

   Amazon RDS

   Bei Amazon RDS legen Sie die zeilenbasierte Konfiguration in der Parametergruppe fest, indem Sie den Parameter binlog retention hours konfigurieren. Mit diesem Parameter wird angegeben, wie viele Stunden Amazon RDS Binärlogdateien aufbewahren soll.

   Wenn Sie den Aufbewahrungszeitraum für binäre Logs in Amazon RDS festlegen möchten, verwenden Sie die gespeicherte Prozedur mysql.rds_set_configuration und geben Sie einen Zeitraum an, der für die Replikation ausreicht. Beispiel:

   call mysql.rds_set_configuration('binlog retention hours',168);

   Der Höchstwert, den Sie für diesen Parameter festlegen können, beträgt 168 Stunden (oder 7 Tage).

   Amazon Aurora

   Für Amazon Aurora führen Sie die folgenden Schritte aus:

   1. Binäres Logging für Ihre MySQL-Datenbank aktivieren
   2. Aufbewahrungsdauer für binäre Logs festlegen:

      mysql> call mysql.rds_set_configuration('binlog retention hours', 168);

      Sie geben diesen Befehl ein, um für eine ordnungsgemäße Replikation zu sorgen. Dazu konfigurieren Sie das System so, dass binäre Logs mindestens 7 Tage (oder 168 Stunden) aufbewahrt werden.
   3. Starten Sie den Server neu, damit die vorgenommenen Änderungen wirksam werden.
9. Alle Tabellen (außer Tabellen in Systemdatenbanken) verwenden das InnoDB-Speichermodul.

   Weitere Informationen zu InnoDB finden Sie unter Das InnoDB-Speichermodul. Weitere Informationen zum Konvertieren in InnoDB finden Sie unter Tabellen von MyISAM zu InnoDB konvertieren.

10. Das Passwort des Nutzerkontos, das für die Verbindung zur Quelldatenbank verwendet wird, darf nicht länger als 32 Zeichen sein. Dieses Problem tritt nur bei der MySQL-Replikation auf.

    Weitere Informationen zur Längenbeschränkung für MySQL-Nutzerpasswörter finden Sie unter MySQL-Fehler 43439.

11. Nur für Microsoft Azure Database for MySQL-Quellen: Prüfen Sie den Wert der 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 festgelegt ist, wählen Sie Basic, TLS oder mTLS aus.
    • Wenn require_secure_transport auf off gesetzt ist, wählen Sie Keine aus.