As limitações conhecidas para usar uma base de dados PostgreSQL como origem incluem:
A extensão
pglogical
não suporta a replicação de colunas geradas para o PostgreSQL 12 ou superior.As alterações às estruturas das tabelas (LDD) não são replicadas através de comandos LDD padrão, mas apenas com comandos executados através da extensão
pglogical
usada para replicação. Isto inclui alterações aosenum
tipos.Por exemplo,
pglogical
fornece uma funçãopglogical.replicate_ddl_command
que permite executar DDL na base de dados de origem e na réplica num ponto consistente. O utilizador que executa este comando na origem já tem de existir na réplica.Para replicar dados para novas tabelas, tem de usar o comando
pglogical.replication_set_add_table
para adicionar as novas tabelas a conjuntos de replicação existentes.Para saber mais sobre a replicação de DDL enquanto a migração está em curso, consulte a secção sobre a fidelidade da migração.
Para tabelas que não têm chaves principais, o Database Migration Service suporta a migração da imagem instantânea inicial e das declarações
INSERT
durante a fase de captura de dados de alterações (CDC). Deve migrar as declaraçõesUPDATE
eDELETE
manualmente.O Database Migration Service não migra dados de vistas materializadas, apenas o esquema de vistas. Para preencher as vistas, execute o seguinte comando:
REFRESH MATERIALIZED VIEW view_name
.Os estados
SEQUENCE
(por exemplo,last_value
) no novo destino do AlloyDB podem variar em relação aos estadosSEQUENCE
de origem.As tabelas
UNLOGGED
eTEMPORARY
não são replicadas e não podem ser replicadas.O tipo de dados de objeto grande não é suportado. Mais detalhes na secção sobre a fidelidade da migração.
- Só é possível migrar extensões e linguagens processuais que o AlloyDB suporta para o PostgreSQL.
O serviço de migração de bases de dados não suporta a migração a partir de réplicas de leitura que estejam no modo de recuperação.
O serviço de migração de base de dados não suporta origens do Amazon RDS onde o pacote de extensão do AWS SCT é aplicado.
- As funções definidas pelo utilizador escritas em C não podem ser migradas, exceto as funções instaladas na base de dados PostgreSQL quando instala extensões suportadas pelo AlloyDB.
Se existirem outras extensões e linguagens processuais na base de dados de origem ou se as respetivas versões não forem suportadas, o teste ou o trabalho de migração falham.
As bases de dados adicionadas após o início da tarefa de migração não são migradas.
- Não pode selecionar tabelas nem esquemas específicos quando migra através do serviço de migração de bases de dados.
O Database Migration Service migra todas as tabelas e esquemas, exceto os seguintes:
- O esquema de informações (
information_schema
). - Todas as tabelas que começam por
pg
, por exemplo,pg_catalog
. Para ver a lista completa de catálogos do PostgreSQL que começam porpg
, consulte Catálogos do sistema PostgreSQL na documentação do PostgreSQL. - As informações sobre os utilizadores e as funções de utilizador não são migradas.
- O esquema de informações (
Se as bases de dados encriptadas exigirem chaves de encriptação geridas pelo cliente para desencriptar as bases de dados e se o Database Migration Service não tiver acesso às chaves, não é possível migrar as bases de dados.
No entanto, se os dados de clientes estiverem encriptados pela extensão
pgcrypto
, podem ser migrados com o serviço de migração de bases de dados (porque o AlloyDB suporta a extensão).O serviço de migração de bases de dados também suporta a migração de dados de bases de dados Amazon Aurora ou Amazon RDS encriptadas, uma vez que estas bases de dados processam a desencriptação de forma transparente nos respetivos serviços. Para mais informações, consulte os artigos Encriptar recursos do Amazon Aurora e Encriptar recursos do Amazon RDS.
A base de dados AlloyDB de destino é gravável durante a migração para permitir que as alterações de DDL sejam aplicadas, se necessário. Tenha cuidado para não fazer alterações à configuração da base de dados nem às estruturas das tabelas que possam interromper o processo de migração ou afetar a integridade dos dados.
O comportamento do acionador depende da forma como foram configurados. Por predefinição, não são acionados, mas, se tiverem sido configurados através da declaração
ALTER EVENT TRIGGER
ouALTER TABLE
e o estado do acionador estiver definido como réplica ou sempre, são acionados na réplica durante a replicação.As funções com o definidor de segurança são criadas por
alloydbexternalsync
no AlloyDB primário. Quando é executado por qualquer utilizador, é executado com os privilégios dealloydbexternalsync
, que tem as funçõesalloydbsuperuser
ealloydbreplica
. É melhor restringir a utilização de uma função de definidor de segurança apenas a alguns utilizadores. Para tal, o utilizador deve revogar os privilégios PUBLIC predefinidos e, em seguida, conceder o privilégio de execução seletivamente.O método de conetividade das interfaces do Private Service Connect só é suportado para a migração para instâncias de destino existentes. Se quiser usar a conetividade IP privada e migrar para uma nova instância de destino, use o peering de VPC.
Limitações para migrações para clusters de destino existentes
- O cluster de destino existente tem de estar vazio ou conter apenas dados de configuração do sistema. A migração para um cluster de destino existente que contenha dados do utilizador (como tabelas) não é suportada.
- Só pode configurar uma tarefa de migração por cluster de destino.
- A migração para clusters com clusters secundários não é suportada.
- A migração para clusters com instâncias de banco de dados de leitura é suportada.
Para mais informações sobre clusters e instâncias do AlloyDB for PostgreSQL, consulte a vista geral do AlloyDB for PostgreSQL.
Quotas
- Podem existir até 2000 perfis de ligação e 1000 tarefas de migração em qualquer altura. Para criar espaço para mais, pode eliminar tarefas de migração (incluindo as concluídas) e perfis de ligação.