Fidelidad de la migración

MySQL   |  PostgreSQL   |  PostgreSQL a AlloyDB

Información general

Cuando migras tu esquema, datos y metadatos de una base de datos de origen a una de destino, quieres asegurarte de que toda esta información se migre correctamente. Database Migration Service ofrece una forma de alta fidelidad de migrar objetos de bases de datos (incluidos el esquema, los datos y los metadatos) de una base de datos a otra.

Todos los siguientes componentes de datos, esquemas y metadatos se migran como parte de la migración de la base de datos:

Datos

• Todas las tablas de todas las bases de datos y esquemas, excepto los siguientes esquemas:

  • El esquema de información information_schema
  • Cualquier esquema que empiece por pg (por ejemplo, pg_catalog)

  Para obtener más información sobre estos esquemas, consulta Limitaciones conocidas.

Esquema

• Nomenclatura

• Clave principal

• Tipo de datos

• Posición ordinal

• Valor predeterminado

• Nulabilidad

• Atributos de incremento automático

• Índices secundarios

Metadatos

• Procedimientos almacenados

• Functions

• Activadores

• Vistas

• Restricciones de clave externa

Migración continua

Solo los cambios del lenguaje de manipulación de datos (DML) se actualizan automáticamente durante las migraciones continuas. El usuario es el responsable de gestionar los cambios del lenguaje de definición de datos (DDL) para que las bases de datos de origen y destino sigan siendo compatibles. Para ello, puede usar dos métodos:

1. Deteniendo las operaciones de escritura en el origen y ejecutando los comandos de DDL en el origen y en el destino. Antes de ejecutar los comandos de DDL en el destino, concede el rol alloydbexternalsync al usuario de AlloyDB que vaya a aplicar los cambios en el DDL. Para habilitar las consultas o los cambios en los datos, concede el rol alloydbexternalsync a los usuarios pertinentes de AlloyDB.
2. Usa pglogical.replicate_ddl_command para permitir que se ejecute DDL en el origen y en el destino en un punto coherente. El usuario que ejecute este comando debe tener el mismo nombre de usuario en el origen y en el destino, y debe ser el superusuario o el propietario del artefacto que se va a migrar (por ejemplo, la tabla, la secuencia, la vista o la base de datos).

   A continuación, te mostramos algunos ejemplos de cómo usar el pglogical.replicate_ddl_command.

   Sustituye:

   • [SCHEMA] con el nombre del esquema de tabla que quieras usar
   • [TABLE_NAME] con el nombre de la tabla
   • [NEW_NAME_FOR_TABLE] con el nuevo nombre de la tabla al realizar la operación de cambio de nombre

   Añadir una columna a una tabla de base de datos con una clave principal

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

   Añadir una columna a una tabla de una base de datos sin clave principal

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

   Cambiar el nombre de una tabla de base de datos con una clave principal

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

   Cambiar el nombre de una tabla de una base de datos sin clave principal

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

   Crear una tabla de base de datos con una clave principal

   Ejecuta estos comandos:

   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]');

   Crear una tabla de base de datos sin clave principal

   Ejecuta estos comandos:

   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]'
      );

Qué no se migra

• Los objetos grandes no se pueden replicar, ya que la función de decodificación lógica de PostgreSQL no admite la decodificación de cambios en objetos grandes. En las tablas que tienen el tipo de columna oid que hace referencia a objetos grandes, las filas se sincronizan y las nuevas filas se replican. Sin embargo, al intentar acceder al objeto grande en la base de datos de destino (leer con lo_get, exportar con lo_export o consultar el catálogo pg_largeobject del oid), se produce un error y se muestra un mensaje que indica que el objeto grande no existe.

• En el caso de las tablas que no tienen claves principales, Database Migration Service admite la migración de la copia inicial y las instrucciones INSERT durante la fase de captura de datos de cambios (CDC). Debes migrar las instrucciones UPDATE y DELETE manualmente.

• Database Migration Service no migra datos de vistas materializadas, solo el esquema de la vista. Para rellenar las vistas, ejecuta el siguiente comando: REFRESH MATERIALIZED VIEW view_name.

• Los estados SEQUENCE (por ejemplo, last_value) del nuevo destino pueden variar con respecto a los estados SEQUENCE de la fuente.

• Los espacios de tablas personalizados no se admiten en la instancia de Cloud SQL de destino. Todos los datos de los espacios de tablas personalizados se migran al espacio de tablas pg_default predeterminado de Cloud SQL.