Entre las limitaciones conocidas para usar una base de datos de PostgreSQL como fuente, se incluyen las siguientes:
La extensión
pglogical
no admite la replicación de columnas generadas para PostgreSQL 12 y versiones posteriores.Los cambios en las estructuras de tablas (DDL) no se replican a través de comandos DDL estándar, sino solo con comandos ejecutados con la extensión
pglogical
que se usa para la replicación.Por ejemplo,
pglogical
proporciona una funciónpglogical.replicate_ddl_command
que permite que el DDL se ejecute en la base de datos de origen y 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 agregar las tablas nuevas a los conjuntos de replicación existentes.Para obtener más información sobre la replicación de DDL mientras la migración está en proceso, consulta la sección sobre fidelidad de la migración.
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 sentenciasUPDATE
yDELETE
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 estadosSEQUENCE
de origen.Las tablas
UNLOGGED
yTEMPORARY
no se replican y no se pueden replicar.No se admite el tipo de datos de objeto grande. Obtén más información en la sección sobre la fidelidad de la migración.
- Solo se pueden migrar las extensiones y los lenguajes de procedimientos que AlloyDB admite para PostgreSQL.
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 fuentes de Amazon RDS en las que se aplica el paquete de extensión de SCT de AWS.
- No se pueden migrar las funciones definidas por el usuario escritas en C, excepto las que se instalan en la base de datos de PostgreSQL cuando instalas extensiones compatibles con AlloyDB.
Si existen otras extensiones y lenguajes procedimentales en la base de datos de origen, o si sus versiones no son compatibles, la prueba o el inicio del trabajo de migración fallarán.
No se migran las bases de datos que se agregan después de que se inicia el trabajo de migración.
No puedes seleccionar objetos de base de datos específicos (como bases de datos, tablas o esquemas) cuando realizas la migración con Database Migration Service. Todas las tablas de todas las bases de datos y esquemas se migran como parte de la migración de bases de datos, excepto los siguientes esquemas:
- El esquema de información (
information_schema
) - Cualquier esquema que comience con
pg
(por ejemplo,pg_catalog
, que contiene las tablas del sistema y todos los tipos de datos, funciones y operadores integrados, y existe automáticamente en todas las bases de datos) Como resultado, no se migra la información sobre los usuarios y sus roles. Consulta la lista completa de esquemas que comienzan conpg
.
- El esquema de información (
Si las bases de datos encriptadas requieren claves de encriptación administradas por el cliente para desencriptarlas y si Database Migration Service no tiene acceso a las claves, no se pueden migrar las bases de datos.
Sin embargo, si la extensión
pgcrypto
encripta los datos del cliente, estos se pueden migrar con Database Migration Service (porque AlloyDB admite la extensión).Database Migration Service también admite la migración de datos desde bases de datos encriptadas de Amazon Aurora o Amazon RDS, ya que estas bases de datos manejan la desencriptación de forma transparente en sus servicios. Para obtener más información, consulta Cómo encriptar recursos de Amazon Aurora y Cómo encriptar recursos de Amazon RDS.
La base de datos de destino de AlloyDB se puede escribir durante la migración para permitir que se apliquen los cambios de DDL si es necesario. Ten cuidado de no realizar cambios en la configuración de la base de datos ni en las estructuras de las tablas que puedan interrumpir el proceso de migración o afectar la integridad de los datos.
El comportamiento de los activadores depende de cómo se hayan configurado. El comportamiento predeterminado es que no se activarán, pero si se configuraron con la sentencia
ALTER EVENT TRIGGER
oALTER TABLE
, y el estado del activador se establece en réplica o siempre, se activarán en la réplica durante la replicación.alloydbexternalsync
creará las funciones con el definidor de seguridad en el elemento principal de AlloyDB. Cuando cualquier usuario lo ejecute, se ejecutará con los privilegios dealloydbexternalsync
, que tiene los rolesalloydbsuperuser
yalloydbreplica
. Es mejor restringir el uso de una función de definidor de seguridad solo a algunos usuarios. Para ello, el usuario debe revocar los privilegios PÚBLICOS predeterminados y, luego, otorgar el privilegio de ejecución de forma selectiva.
Limitaciones para las migraciones a clústeres de destino existentes
- El clúster de destino existente debe estar vacío o contener solo datos de configuración del sistema. No se admite la migración a un clúster de destino existente que contenga datos del usuario (como tablas).
- Solo puedes configurar un trabajo de migración por clúster de destino.
- No se admite la migración a clústeres con clústeres secundarios.
- Se admite la migración a clústeres con instancias de grupo de lectura.
Para obtener más información sobre los clústeres y las instancias de AlloyDB para PostgreSQL, consulta la descripción general de AlloyDB para PostgreSQL.
Cuotas
- Pueden existir hasta 2,000 perfiles de conexión y 1,000 trabajos de migración en un momento determinado. Para liberar espacio, se pueden borrar trabajos de migración (incluso los que están completos) y perfiles de conexión.