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 red 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 trasladar tus cargas de trabajo de PostgreSQL a AlloyDB.

¿Qué fuentes se admiten?

• 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, 17 y 18

¿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 esquemas

• 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 operaciones de escritura al origen y ejecuta los comandos de DDL en el origen y el destino. Antes de ejecutar comandos DDL en el destino, otorga la función alloydbexternalsync al usuario de Cloud SQL que aplicará los cambios de DDL. Para habilitar la búsqueda o las modificaciones de los datos, otorga la función alloydbexternalsync a los usuarios de Cloud SQL pertinentes.

2. Usa el 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).

   Estos son algunos ejemplos del uso del comando pglogical.replicate_ddl_command.

   Para agregar una columna a una tabla de 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 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.

No se pueden replicar objetos grandes 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 el tipo de columna oid que hace referencia a objetos grandes, las filas aún se sincronizan y se replican las filas nuevas. Sin embargo, si intentas acceder a l objeto grande en la base de datos de destino (leer con lo_get, exportar con lo_export, o consultar 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 nuevo destino de AlloyDB pueden variar de los estados SEQUENCE de origen.

¿Qué métodos de red se usan?

Para crear una migración en Database Migration Service, se debe establecer la conectividad entre el origen y la instancia de destino de Cloud SQL. Hay una variedad de métodos admitidos. Elige el 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 el origen a través de un túnel SSH inverso seguro. Requiere una VM de host de bastión en el Google Cloud proyecto y una máquina (por ejemplo, una laptop en la red) que tenga conectividad con el origen. Database Migration Service collects the required information at migration creation time, and auto-generates the script for setting it up.	Es fácil de configurar. No requiere ninguna configuración de firewall personalizada. Se recomienda para situaciones de migración de corta duración (pruebas de concepto o migraciones de bases de datos pequeñas).	Eres propietario de la VM bastión y la administras. Puede generar costos adicionales.
Proxy TCP a través de una VM alojada en la nube	Establece la conectividad desde el destino hasta el origen a través de un proxy TCP a través de una VM alojada en la nube. Database Migration Service recopila la información requerida 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 el origen está en la arquitectura de red anterior.	Es fácil de configurar. No requiere ninguna configuración de firewall personalizada.	Eres propietario de la VM bastión y la administras, y puede generar costos adicionales.
Intercambio de tráfico entre VPC	Este método funciona mediante la configuración de las VPC para que se comuniquen entre sí.	Soluciónnativa Google Cloud . Es fácil de configurar. Tiene un 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 de VPN con IPSec que conecta la red interna y Google Cloud VPC a través de una conexión segura a través de Internet público. Usa Google Cloud VPN o cualquier solución de VPN que esté configurada para la red interna.	Solución de conectividad sólida y escalable. Ancho de banda medio-alto. Seguridad integrada. Se ofrece como Google Cloud soluciones o de otros terceros.	Costo adicional. Configuración no trivial (a menos que ya esté implementada).
Cloud Interconnect	Usa una conexión de baja latencia con alta disponibilidad entre la red local y Google Cloud.	El ancho de banda más alto es ideal para migraciones de gran volumen y de 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 Limitaciones conocidas.