Fidelidad en la migración

MySQL   |  PostgreSQL   |  PostgreSQL a AlloyDB

Descripción general

Cuando migras tu esquema, datos y 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 proporciona una forma de alta fidelidad para migrar objetos de base 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:

  • 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

• Nombre

• 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 los cambios del lenguaje de manipulación de datos (DML) se actualizan automáticamente 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 operaciones de escritura 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 relevantes.
2. Usar 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 la fuente 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] por el nombre del esquema de la tabla que deseas usar
   • [TABLE_NAME] con el nombre de la tabla
   • [NEW_NAME_FOR_TABLE] con el nombre nuevo de la tabla cuando se realiza 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}'
   );

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

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

   Cambia 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 una 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

• No se pueden replicar los objetos grandes, 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, se sincronizan las filas y se replican las nuevas. Sin embargo, si intentas acceder al objeto grande en la base de datos de destino (lee con lo_get, exporta con lo_export o verifica el catálogo pg_largeobject para el oid determinado), se produce un error con un mensaje que indica que el objeto grande no existe.

• En el caso de 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 sentencias UPDATE y DELETE de forma manual.

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

• Los estados SEQUENCE (por ejemplo, last_value) en el destino nuevo pueden variar de los estados SEQUENCE de origen.

• Los espacios de tabla personalizados no son compatibles con 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.