Zuverlässigkeit der Migration

MySQL   |  PostgreSQL   |  PostgreSQL zu AlloyDB

Übersicht

Wenn Sie Ihr Schema, Ihre Daten und Ihre Metadaten aus einer Quelldatenbank in eine Zieldatenbank migrieren, sollten Sie darauf achten, dass alle diese Informationen korrekt migriert werden. Der Database Migration Service bietet eine zuverlässige Möglichkeit, Datenbankobjekte (einschließlich Schema, Daten und Metadaten) von einer Datenbank in eine andere zu migrieren.

Im Rahmen der Datenbankmigration werden alle folgenden Daten-, Schema- und Metadatenkomponenten migriert:

Daten

• Alle Tabellen aus allen Datenbanken und Schemas, mit Ausnahme der folgenden Schemas:

  • Das Informationsschema information_schema
  • Alle Schemas, die mit pg beginnen (z. B. pg_catalog)

  Weitere Informationen zu diesen Schemas finden Sie unter Bekannte Einschränkungen.

Schema

• Benennung

• Primärschlüssel

• Datentyp

• Ordinale Position

• Standardwert

• Null-Zulässigkeit

• Attribute mit automatischer Inkrementenfolge

• Sekundäre Indexe

Metadaten

• Gespeicherte Prozeduren

• Funktionen

• Trigger

• Aufrufe

• Einschränkungen für Fremdschlüssel

Kontinuierliche Migration

Bei kontinuierlichen Migrationen werden nur DML-Änderungen (Data Manipulation Language) automatisch aktualisiert. Die Verwaltung von Änderungen an der Datendefinitionssprache (DDL), damit die Quell- und Zieldatenbanken kompatibel bleiben, liegt in der Verantwortung des Nutzers. Dies kann auf zwei Arten erfolgen:

1. Beenden Sie Schreibvorgänge in die Quelle und führen Sie die DDL-Befehle in der Quelle und dem Ziel aus. Gewähren Sie dem AlloyDB-Nutzer, der die DDL-Änderungen anwendet, die Rolle alloydbexternalsync, bevor die DDL-Befehle für das Ziel ausgeführt werden. Gewähren Sie den entsprechenden AlloyDB-Nutzern die Rolle alloydbexternalsync, um Abfragen oder Änderungen der Daten zu ermöglichen.
2. Verwenden Sie die pglogical.replicate_ddl_command, damit DDL an der Quelle und am Ziel an einem konsistenten Punkt ausgeführt werden kann. Der Nutzer, der diesen Befehl ausführt, muss sowohl an der Quelle als auch am Ziel denselben Nutzernamen haben und Superuser oder Inhaber des zu migrierenden Artefakts sein (z. B. der Tabelle, Sequenz, Ansicht oder Datenbank).

   Hier einige Beispiele für die Verwendung von pglogical.replicate_ddl_command.

   Ersetzen Sie:

   • [SCHEMA] durch den Namen des zu verwendenden Tabellenschemas
   • [TABLE_NAME] durch den Tabellennamen
   • [NEW_NAME_FOR_TABLE] durch den neuen Namen der Tabelle beim Umbenennen

   Datenbanktabelle mit einem Primärschlüssel eine Spalte hinzufügen

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] add column surname varchar(20)',
     '{default}'
   );

   Datenbanktabelle ohne Primärschlüssel eine Spalte hinzufügen

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] add column surname varchar(20)',
     '{default_insert_only}'
   );

   Namen einer Datenbanktabelle mit einem Primärschlüssel ändern

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
     '{default}'
   );

   Namen einer Datenbanktabelle ohne Primärschlüssel ändern

   select pglogical.replicate_ddl_command(
     'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
     '{default_insert_only}'
   );

   Datenbanktabelle mit einem Primärschlüssel erstellen

   Führen Sie folgende Befehle aus:

   1. select pglogical.replicate_ddl_command(
        command := 'CREATE TABLE [SCHEMA].[TABLE_NAME]
          (id INTEGER PRIMARY KEY, name VARCHAR);',
        replication_sets := ARRAY['default']
      );

   2. select pglogical.replication_set_add_table('default', '[SCHEMA].[TABLE_NAME]');

   Datenbanktabelle ohne Primärschlüssel erstellen

   Führen Sie folgende Befehle aus:

   1. select pglogical.replicate_ddl_command(
        command := 'CREATE TABLE [SCHEMA].[TABLE_NAME]
         (id INTEGER PRIMARY KEY, name VARCHAR);',
        replication_sets := ARRAY['default_insert_only']
      );

   2. select pglogical.replication_set_add_table(
        'default_insert_only', '[SCHEMA].[TABLE_NAME]'
      );

Was nicht migriert wird

• Große Objekte können nicht repliziert werden, da die logische Decodierungsfunktion von PostgreSQL keine Decodierung von Änderungen an großen Objekten unterstützt. Bei Tabellen mit dem Spaltentyp oid, der auf große Objekte verweist, werden die Zeilen synchronisiert und neue Zeilen repliziert. Der Zugriff auf das Large Object in der Zieldatenbank (Lesen mit lo_get, Exportieren mit lo_export oder Prüfen des Katalogs pg_largeobject auf die angegebene oid) schlägt jedoch fehl und es wird die Meldung angezeigt, dass das Large Object nicht vorhanden ist.

• Bei Tabellen ohne Primärschlüssel unterstützt Database Migration Service die Migration des ersten Snapshots und der INSERT-Anweisungen während der CDC-Phase (Change Data Capture). Sie sollten UPDATE- und DELETE-Anweisungen manuell migrieren.

• Der Database Migration Service migriert keine Daten aus materialisierten Ansichten, sondern nur das Ansichtsschema. Führen Sie den folgenden Befehl aus, um die Daten in die Ansichten einzufügen: REFRESH MATERIALIZED VIEW view_name.

• Die SEQUENCE-Status (z. B. last_value) des neuen Ziels können von den SEQUENCE-Status der Quelle abweichen.

• Benutzerdefinierte Tablespaces werden in der Ziel-Cloud SQL-Instanz nicht unterstützt. Alle Daten in benutzerdefinierten Tablespaces werden in Cloud SQL in den Standard-Tablespace pg_default migriert.