Fidelidad en la migración

MySQL   |  PostgreSQL   |  PostgreSQL a AlloyDB

Descripción general

Cuando migras tu esquema, tus datos y tus metadatos de una base de datos de origen a una base de datos de destino, debes asegurarte de que toda esta información se migre con precisión. Database Migration Service ofrece una forma de alta fidelidad para 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 comience con pg (por ejemplo, pg_catalog)

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

Esquema

• Nombres

• Clave primaria

• Tipo de datos

• Posición ordinal

• Valor predeterminado

• Nulabilidad

• Atributos de incremento automático

• Índices secundarios

Metadatos

• Procedimientos almacenados

• Funciones

• Activadores

• Vistas

• Restricciones de clave externa

Migración continua

Solo se actualizan automáticamente los cambios del lenguaje de manipulación de datos (DML) durante las migraciones continuas. La administración de los cambios en el lenguaje de definición de datos (DDL) para que las bases de datos de origen y de destino sigan siendo compatibles es responsabilidad del usuario y se puede lograr de dos maneras:

1. Detener las escrituras en el origen y ejecutar los comandos de DDL en el origen y el destino Antes de ejecutar comandos DDL en el destino, otorga alloydbexternalsync al usuario de AlloyDB que aplicará los cambios de DDL. Para habilitar la búsqueda o las modificaciones de los datos, otorga el rol alloydbexternalsync a los usuarios de AlloyDB pertinentes.
2. Usa pglogical.replicate_ddl_command para permitir que el DDL se ejecute en el origen y el destino en un punto coherente. El usuario que ejecuta este comando debe tener el mismo nombre de usuario en el origen y el destino, y debe ser el superusuario o el propietario del artefacto que se migra (por ejemplo, la tabla, la secuencia, la vista o la base de datos).

   A continuación, se muestran algunos ejemplos del uso de pglogical.replicate_ddl_command.

   Reemplaza lo siguiente:

   • [SCHEMA] con el nombre del esquema de la tabla que deseas usar
   • [TABLE_NAME] con el nombre de la tabla
   • [NEW_NAME_FOR_TABLE] con el nuevo nombre de la tabla cuando realices la operación de cambio de nombre

   Agrega una columna a una tabla de base de datos con una clave primaria

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

   Agregar una columna a una tabla de base de datos sin clave primaria

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

   Cómo cambiar el nombre de una tabla de base de datos con una clave primaria

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

   Cambia el nombre de una tabla de base de datos sin clave primaria

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

   Crea una tabla de base de datos con una clave primaria

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

   Crea una tabla de base de datos sin una clave primaria

   Ejecuta los siguientes 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 el caso de las tablas que tienen el tipo de columna oid que hace referencia a objetos grandes, las filas se sincronizan y las filas nuevas se replican. Sin embargo, cuando se intenta acceder al objeto grande en la base de datos de destino (leer con lo_get, exportar con lo_export o verificar el catálogo pg_largeobject para el oid determinado), se produce un error con un mensaje que indica que el objeto grande no existe.

• Para las tablas que no tienen claves primarias, Database Migration Service admite la migración de la instantánea inicial y las sentencias INSERT durante la fase de captura de datos modificados (CDC). Debes migrar las declaraciones UPDATE y DELETE de forma manual.

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

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

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