Preguntas frecuentes sobre Database Migration Service para AlloyDB

MySQL   |  PostgreSQL   |  PostgreSQL a AlloyDB

• ¿Qué es Database Migration Service?
• ¿Qué fuentes son compatibles?
• ¿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 utilizan?
• ¿Cuáles son las limitaciones conocidas?

¿Qué es Database Migration Service?

Database Migration Service es un servicio que te permite migrar tus datos con mayor facilidad a Google Cloud. Database Migration Service te ayuda a migrar tus cargas de trabajo de PostgreSQL a AlloyDB.

¿Qué fuentes se admiten?

• Amazon RDS 9.6.10, 10.5, 11.1, 12, 13, 14 y 15
• Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14 y 15
• 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 y 15
• Cloud SQL: 9.6, 10, 11, 12, 13, 14 y 15

¿Qué destinos son compatibles?

• AlloyDB para PostgreSQL 14, 15 y 16

¿Hay compatibilidad entre versiones?

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

¿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 claves externas

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

Solo se actualizan automáticamente los cambios de DML durante la migración. La administración del 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. 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 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 relevantes.

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 la fuente y en 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 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.

Los objetos grandes no se pueden replicar porque la función de decodificación lógica de PostgreSQL no admite cambios de decodificación en objetos grandes. En el caso de las tablas que tienen un OID de tipo de columna que hace referencia a objetos grandes, las filas se siguen sincronizando y se replican las filas 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 nuevo destino de AlloyDB pueden variar de los estados SEQUENCE de origen.

¿Qué métodos de creación de redes se usan?

Para crear una migración en Database Migration Service, se debe establecer la conectividad entre la fuente y la instancia de destino de Cloud SQL. Se admiten varios 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 del destino a la fuente a través de un túnel SSH inverso seguro. Requiere una VM de host de bastión en el proyecto de 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 de la VM de Bastion y la administras. 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 está en la arquitectura de red anterior.	Es fácil de configurar. No requiere ninguna configuración personalizada del firewall.	Tú eres el propietario y administrador de la VM de Bastion, y es posible que se generen costos adicionales.
Intercambio de tráfico entre VPC	Este método funciona configurando las VPC para que se comuniquen entre sí.	Solución nativa de Google Cloud . Es fácil de configurar. Ancho de banda alto Se recomienda para migraciones de larga duración o de alto volumen.	Solo se aplica si las bases de datos de origen y destino se alojan en Google Cloud.
VPN	Establece un túnel VPN con IPsec que conecta la red interna y la VPC de Google Cloud a través de una conexión segura a través de Internet público. Usa la VPN de Google Cloud 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 ofrecen como soluciones de Google Cloud o de otros terceros.	Costo adicional. Configuración no trivial (a menos que ya esté implementada).
Cloud Interconnect	Usa una conexión de alta disponibilidad y baja latencia entre la red local y Google Cloud.	Ancho de banda más alto, ideal para migraciones de alto volumen 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 las limitaciones conocidas.