Información general
Antes de migrar tus bases de datos a Cloud SQL, ten en cuenta las limitaciones conocidas de este escenario de migración.
Entre las limitaciones conocidas al usar una base de datos PostgreSQL como fuente, se incluyen las siguientes:
La extensión
pglogical
no admite la replicación de columnas generadas en PostgreSQL 12 o versiones posteriores.Los cambios en las estructuras de las tablas (DDL) no se replican mediante comandos DDL estándar, sino solo con los comandos ejecutados mediante la extensión
pglogical
que se usa para la replicación. Esto incluye cambios en losenum
tipos.Por ejemplo,
pglogical
proporciona una funciónpglogical.replicate_ddl_command
que permite ejecutar DDL en la base de datos de origen y en la réplica en un punto coherente. El usuario que ejecuta este comando en la fuente ya debe existir en la réplica.Para replicar datos de tablas nuevas, debes usar el comando
pglogical.replication_set_add_table
para añadir las tablas nuevas a los conjuntos de réplicas que ya tengas.Para obtener más información sobre la replicación de DDL mientras la migración está en curso, consulta la sección sobre la fidelidad de la migración.
En el caso de las tablas que no tienen claves principales, Database Migration Service admite la migración de la copia inicial y las instrucciones
INSERT
durante la fase de captura de datos de cambios (CDC). Debes migrar las instruccionesUPDATE
yDELETE
manualmente.Database Migration Service no migra datos de vistas materializadas, solo el esquema de la vista. Para rellenar las vistas, ejecuta el siguiente comando:
REFRESH MATERIALIZED VIEW view_name
.Los estados
SEQUENCE
(por ejemplo,last_value
) del nuevo destino de Cloud SQL pueden variar con respecto a los estadosSEQUENCE
de origen.Las tablas
UNLOGGED
yTEMPORARY
no se replican ni se pueden replicar.No se admite el tipo de datos de objeto grande. Para obtener más información, consulta la sección sobre la fidelidad de la migración.
Solo se pueden migrar las extensiones y los lenguajes de procedimiento que Cloud SQL admite en PostgreSQL. Database Migration Service no migra las extensiones que no son compatibles con Cloud SQL. La presencia de estas extensiones no bloquea la migración, pero, para que el proceso sea fluido, comprueba que tus objetos o aplicaciones no hagan referencia a ninguna extensión no admitida. Te recomendamos que elimines estas extensiones y referencias de tu base de datos de origen antes de continuar.
Database Migration Service no migra la extensión
pg_cron
ni los ajustes decron
asociados a ella, pero se admite en los destinos de Cloud SQL para PostgreSQL. Si usas la extensiónpg_cron
en tus bases de datos de origen, puedes volver a instalarla en tu instancia de destino una vez que se haya completado la migración.
Database Migration Service no admite la migración desde réplicas de lectura que estén en modo de recuperación.
Database Migration Service no admite orígenes de Amazon RDS en los que se haya aplicado el paquete de extensiones de AWS SCT.
- Las funciones definidas por el usuario escritas en C no se pueden migrar, excepto las funciones que se instalan en la base de datos PostgreSQL cuando instalas extensiones compatibles con Cloud SQL.
Si hay otras extensiones y lenguajes de procedimiento en la base de datos de origen, o si sus versiones no son compatibles, se producirá un error al probar o iniciar el trabajo de migración.
Las bases de datos que se añadan después de que se haya iniciado la tarea de migración no se migrarán.
- No puedes seleccionar tablas ni esquemas específicos cuando migras con Database Migration Service.
Database Migration Service migra todas las tablas y esquemas, excepto los siguientes:
- El esquema de información (
information_schema
). - Cualquier tabla que empiece por
pg
, comopg_catalog
. Para ver la lista completa de catálogos de PostgreSQL que empiezan porpg
, consulta los catálogos del sistema de PostgreSQL en la documentación de PostgreSQL. - No se migra la información sobre los usuarios ni los roles de usuario.
- El esquema de información (
Si las bases de datos cifradas requieren claves de cifrado gestionadas por el cliente para descifrarlas y Database Migration Service no tiene acceso a las claves, las bases de datos no se pueden migrar.
Sin embargo, si los datos de los clientes están cifrados con la extensión
pgcrypto
, se pueden migrar con Database Migration Service (porque Cloud SQL admite la extensión).Database Migration Service también admite la migración de datos de bases de datos cifradas de Amazon Aurora o Amazon RDS, ya que estas bases de datos gestionan el descifrado de forma transparente en sus servicios. Para obtener más información, consulta Cifrar recursos de Amazon Aurora y Cifrar recursos de Amazon RDS.
La base de datos de Cloud SQL de destino se puede escribir durante la migración para permitir que se apliquen cambios en el DDL si es necesario. Asegúrate de no hacer ningún cambio en la configuración de la base de datos ni en las estructuras de las tablas que pueda interrumpir el proceso de migración o afectar a la integridad de los datos.
El comportamiento de los activadores depende de cómo se hayan configurado. De forma predeterminada, no se activarán, pero si se han configurado con la instrucción
ALTER EVENT TRIGGER
oALTER TABLE
y el estado del activador se ha definido como réplica o siempre, se activarán en la réplica durante la replicación.Las funciones con definidor de seguridad se crearán mediante
cloudsqlexternalsync
en la réplica de Cloud SQL. Cuando lo ejecuten los usuarios, se hará con los privilegios decloudsqlexternalsync
, que tiene los rolescloudsqlsuperuser
ycloudsqlreplica
. Es mejor restringir el uso de una función de definidor de seguridad a algunos usuarios. Para ello, el usuario debe revocar los privilegios PUBLIC predeterminados y, a continuación, conceder el privilegio de ejecución de forma selectiva.Cloud SQL no admite espacios de tablas personalizados. Todos los datos de los espacios de tablas personalizados se migran al espacio de tablas
pg_default
de la instancia de destino de Cloud SQL.El método de conectividad de las interfaces de Private Service Connect solo se admite para migrar a instancias de destino. Si quieres usar la conectividad IP privada y migrar a una instancia de destino nueva, usa el emparejamiento de VPCs.
Limitaciones de las migraciones a instancias de destino
- La instancia de destino debe estar vacía o contener solo datos de configuración del sistema. No se admite la migración a instancias de destino que ya contengan datos de usuario (como tablas).
Si tienes problemas debido a datos adicionales en tu instancia de destino, borra las bases de datos de la instancia de destino y vuelve a intentar la tarea de migración. Consulta Borrar datos adicionales de tu instancia de destino.
- Solo puedes configurar una tarea de migración por instancia de destino.
- Solo puedes migrar a instancias de Cloud SQL independientes. No se admite la migración a réplicas de servidores externos.
- No se admite la migración de datos a una instancia de Cloud SQL que tenga habilitado Private Service Connect.
- Después de promover una instancia, debes activar la recuperación a un momento dado.
- Si tu instancia tiene ajustes de copia de seguridad personalizados (por ejemplo, una ubicación de copia de seguridad personalizada), después de promover la instancia, debes volver a personalizar los ajustes de copia de seguridad. Durante el proceso de promoción, Cloud SQL restablece los ajustes de copia de seguridad a sus valores predeterminados.
- Para los usuarios de Terraform: Database Migration Service modifica los ajustes de copia de seguridad y recuperación de tu instancia de destino. Esto puede provocar que los ajustes de la instancia de destino sean diferentes de la configuración de Terraform que has usado para el aprovisionamiento. Si tienes este problema, sigue las indicaciones de la sección Diagnosticar problemas.
Cuotas
- Puedes disponer de hasta 2000 perfiles de conexión y 1000 tareas de migración al mismo tiempo. Si quieres liberar espacio, puedes eliminar los perfiles de conexión y las tareas de migración, incluidas las completadas.
- La instancia de destino debe estar vacía o contener solo datos de configuración del sistema. No se admite la migración a instancias de destino que ya contengan datos de usuario (como tablas).