Preguntas frecuentes sobre Database Migration Service para AlloyDB

MySQL   |  PostgreSQL   |  PostgreSQL a AlloyDB

• ¿Qué es Database Migration Service?
• ¿Qué fuentes se admiten?
• ¿Hay compatibilidad entre versiones?
• ¿Qué componentes de datos, esquemas y metadatos se migran?
• ¿Qué cambios se replican durante la migración continua?
• ¿Qué no se migra?
• ¿Qué métodos de redes se usan?
• ¿Cuáles son las limitaciones conocidas?

¿Qué es Database Migration Service?

Database Migration Service es un servicio que te facilita la migración de tus datos a Google Cloud. Database Migration Service te ayuda a migrar tus cargas de trabajo de PostgreSQL a AlloyDB con el método lift-and-shift.

¿Qué fuentes son compatibles?

• Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16 y 17
• Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14, 15, 16 y 17
• PostgreSQL autoadministrado (local o en cualquier VM en la nube que controlas por completo) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16 y 17
• Cloud SQL 9.6, 10, 11, 12, 13, 14, 15, 16 y 17

¿Qué destinos se admiten?

• AlloyDB para PostgreSQL 14, 15, 16 y 17

¿Hay compatibilidad entre versiones?

Database Migration Service admite migraciones de PostgreSQL a AlloyDB desde cualquiera de las versiones de bases de datos de origen admitidas.

¿Qué componentes de datos, esquemas y metadatos se migran?

Database Migration Service migra el esquema, los datos y los metadatos del origen al destino. Todos los siguientes componentes de datos, esquemas y metadatos se migran como parte de la migración de la base de datos:

Migración de datos

• Todos los esquemas y todas las tablas de la base de datos seleccionada.

Migración de esquema

• Nombre
• Clave primaria
• Tipo de datos
• Posición ordinal
• Valor predeterminado
• Nulabilidad
• Atributos de incremento automático
• Índices secundarios

Migración de metadatos

• Procedimientos almacenados
• Funciones
• Activadores
• Vistas
• Restricciones de clave externa

¿Qué cambios se replican durante la migración continua?

Solo se actualizan de forma automática los cambios de DML durante la migración. La administración de DDL para que las bases de datos de origen y destino sigan siendo compatibles es responsabilidad del usuario y se puede lograr de dos maneras:

1. Detén las escrituras al origen y ejecuta los comandos de DDL en el origen y el destino. Antes de ejecutar comandos DDL en el destino, otorga el rol alloydbexternalsync al usuario de Cloud SQL 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 Cloud SQL pertinentes.

2. Usa pglogical.replicate_ddl_command para ejecutar DDL 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.

   Para agregar una columna a una tabla de la base de datos, ejecuta el siguiente comando:

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

   Para cambiar el nombre de una tabla de la base de datos, ejecuta el siguiente comando:

   select pglogical.replicate_ddl_command('ALTER TABLE [schema].[table] RENAME TO [table_name]','{default}');

   Para crear una tabla de base de datos, ejecuta los siguientes comandos:

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

¿Qué no se migra?

Para agregar usuarios a la instancia de destino de AlloyDB, agrégalos desde el cliente de PostgreSQL. Obtén más información para crear y administrar usuarios de PostgreSQL.

Los objetos grandes no se pueden replicar porque 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 un tipo de columna oid que hace referencia a objetos grandes, las filas se siguen sincronizando y las filas nuevas se replican. Sin embargo, intentar 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) falla 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 SEQUENCE (por ejemplo, last_value) en el nuevo destino de AlloyDB pueden variar con respecto a los estados SEQUENCE de la fuente.

¿Qué métodos de redes se utilizan?

Para crear una migración en Database Migration Service, se debe establecer la conectividad entre la instancia de origen y la instancia de destino de Cloud SQL. Se admite una variedad de métodos. Elige la que mejor se adapte a la carga de trabajo específica.

Método de red	Descripción	Ventajas	Desventajas
Túnel SSH inverso a través de una VM alojada en la nube	Establece la conectividad desde el destino hasta la fuente a través de un túnel SSH inverso seguro. Requiere una VM de host de bastión en el proyecto Google Cloud y una máquina (por ejemplo, una laptop en la red) que tenga conectividad con la fuente. Database Migration Service recopila la información necesaria en el momento de la creación de la migración y genera automáticamente la secuencia de comandos para configurarla.	Es fácil de configurar. No requiere ninguna configuración personalizada del firewall. Se recomienda para situaciones de migración de corta duración (POC o migraciones de bases de datos pequeñas).	Eres propietario y administrador de la VM de Bastion. Es posible que se generen costos adicionales.
Proxy TCP a través de una VM alojada en la nube	Establece la conectividad del destino a la fuente a través de un proxy TCP a través de una VM alojada en la nube. Database Migration Service recopila la información necesaria en el momento de la creación de la migración y genera automáticamente la secuencia de comandos para configurarla. Es relevante en las migraciones de AlloyDB en las que la fuente se encuentra en la arquitectura de red anterior.	Es fácil de configurar. No requiere ninguna configuración personalizada del firewall.	La VM de bastión es de tu propiedad y la administras tú, y puede generar costos adicionales.
Intercambio de tráfico entre VPC	Este método funciona configurando las VPC para que se comuniquen entre sí.	Solución Google Cloud nativa. Es fácil de configurar. Ancho de banda alto Se recomienda para migraciones de larga duración o de gran volumen.	Solo se aplica si las bases de datos de origen y destino están alojadas en Google Cloud.
VPN	Configura un túnel VPN con IPSec que conecta la red interna y la Google Cloud VPC a través de una conexión segura por Internet público. Usa Google Cloud VPN o cualquier solución de VPN configurada para la red interna.	Solución de conectividad sólida y escalable Ancho de banda medio a alto Seguridad integrada. Se ofrecen como Google Cloud soluciones o a través de otros terceros.	Costo adicional. Configuración no trivial (a menos que ya esté implementada).
Cloud Interconnect	Utiliza una conexión de baja latencia y alta disponibilidad entre la red local y Google Cloud.	Es el ancho de banda más alto, ideal para migraciones de gran volumen y larga duración.	Costo adicional. La conexión no es segura de forma predeterminada. Configuración no trivial (a menos que ya esté implementada).

¿Cuáles son las limitaciones conocidas?

Consulta las limitaciones conocidas.