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.

So konfigurieren Sie eine Quelldatenbank:

1. Für Cloud SQL-Quellen: Wenn Sie von einer Cloud SQL-Instanz, die eine private IP-Verbindung verwendet, zu einer Cloud SQL-Instanz migrieren, die einen IP-Adressbereich außerhalb von RFC 1918 verwendet, fügen Sie den Bereich außerhalb von RFC 1918 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 Schreibvorgänge der Datendefinitionssprache (DDL) während der Phase des vollständigen Dumps beenden. Sie können mit einem Skript prüfen, ob die DDL-Vorgänge beendet wurden. Nachdem die Migration in die CDC-Phase (Change Data Capture) eingetreten ist, können Sie die 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 einer DEFINER-Klausel erstellen und ausführen.
4. Wenn Ihre Quelldatenbank Objekte enthält, die auf Tabellen in den mysql, performance_schema, information_schema, ndbinfo, oder sys Systemschemata verweisen, müssen die Replikatdatenbanken auch diese System Schematabellen enthalten.

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

5. Sie müssen die Option „server-id“ auf einen Wert von 1 oder höher festlegen. Weitere Informationen finden Sie unter Optionen und Variablen für Replikation und binäres Logging.
6. Konfigurieren Sie das Logging der globalen Transaktions-ID (GTID), indem Sie das GTID_MODE auf ON oder OFF setzen. Der Wert ON_PERMISSIVE für GTID_MODE 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, setzen Sie GTID_MODE auf ON.
   • Wenn Sie einen manuellen Dump verwenden, um Ihre Daten zu migrieren, setzen Sie GTID_MODE auf ON.
   Weitere Informationen zu GTID_MODE finden Sie unter Systemvariable für globale Transaktions-ID.

7. Sie müssen das Nutzerkonto, das für die Verbindung zur Quelldatenbank verwendet wird, so konfigurieren, dass Verbindungen von einem beliebigen Host (%) zugelassen 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 Kombinationen aus Migration und Dump 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 darauf, dass das Migrationskonto nicht die BACKUP_ADMIN Berechtigung hat.

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

   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 Format von MySQL-Nutzerkonten.

   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 darauf, dass das Migrationskonto nicht die BACKUP_ADMIN Berechtigung hat.

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

   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 Format von MySQL-Nutzerkonten.

8. Bevor Sie binäre Logs konfigurieren, müssen Sie Folgendes tun:
   • 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, um die Datenbankmigration zu ermöglichen. In der Regel ist eine Woche ausreichend.

   Wenn Sie binäre Logs konfigurieren möchten, maximieren Sie den Abschnitt für Ihre Quelle:

   Cloud SQL for MySQL

   In Cloud SQL for MySQL wird das binäre Logging automatisch aktiviert, wenn Sie die Wiederherstellung zu einem bestimmten Zeitpunkt verwenden. Sie können das Logformat und die Aufbewahrungsdauer mit den in Cloud SQL verfügbaren System-Flags konfigurieren:

   1. Aktivieren Sie die Wiederherstellung zu einem bestimmten Zeitpunkt für Ihre Instanz, um das binäre Logging 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. Für das Logformat müssen Sie keine Einstellungen anpassen. Cloud SQL for MySQL setzt das binlog_format Flag auf ROW.
      2. Verwenden Sie eines der folgenden Flags für die Ablaufzeit des Logs:
         • MySQL 5.6–5.7: expire_logs_days
         • MySQL 8.0 und höher: expire_logs_days, binlog_expire_logs_seconds

   Selbst gehostetes MySQL

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

   • 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 für binlog_expire_logs_seconds einen Zeitraum fest, der für die Datenbankmigration ausreichend ist.

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

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

   Amazon RDS

   Für Amazon RDS legen Sie die zeilenbasierte Konfiguration in der Parametergruppe fest, indem Sie den binlog retention hours Parameter konfigurieren. Mit diesem Parameter geben Sie an, wie viele Stunden Amazon RDS Binärlogdateien aufbewahren soll.

   Wenn Sie die Aufbewahrungsdauer 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 ausreichend ist. Beispiel:

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

   Der maximale Wert, 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. Aktivieren Sie das binäre Logging für Ihre MySQL-Datenbank.
   2. Legen Sie die Aufbewahrungsdauer für binäre Logs fest:

      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ärlogs 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 zu 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 Beschränkung der Länge des MySQL-Nutzerpassworts 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 erfordern Microsoft Azure-Datenbanken für alle eingehenden Verbindungen eine SSL/TLS-Verschlüsselung. Verwenden Sie je nach Wert von require_secure_transport 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 None aus.