As limitações conhecidas para o uso de um banco de dados PostgreSQL como fonte incluem:
A extensão
pglogicalnão oferece suporte à replicação de colunas geradas para o PostgreSQL 12 e versões mais recentes.As mudanças nas estruturas de tabelas (DDL) não são replicadas por comandos DDL padrão, mas apenas com comandos executados usando a extensão
pglogicalusada para replicação. Isso inclui mudanças nosenumtipos.Por exemplo,
pglogicalfornece uma funçãopglogical.replicate_ddl_commandque permite que o DDL seja executado em tanto no banco de dados de origem quanto na réplica em um ponto consistente. O usuário que executa esse comando na origem já precisa existir na réplica.Para replicar dados de novas tabelas, use o comando
pglogical.replication_set_add_tablepara adicionar as novas tabelas aos conjuntos de replicação atuais.Para saber mais sobre a replicação de DDL enquanto a migração está em andamento, consulte a seção sobre fidelidade da migração.
Para tabelas sem chaves primárias, o Database Migration Service oferece suporte à migração de snapshots iniciais e instruções
INSERTdurante a fase de captura de dados alterados (CDC). Você deve migrar as instruçõesUPDATEeDELETEmanualmente.O Database Migration Service não migra dados de visualizações materializadas, apenas o esquema de visualização. Para preencher as visualizações, execute o seguinte comando:
REFRESH MATERIALIZED VIEW view_name.Os estados
SEQUENCE(por exemplo,last_value) no novo destino do AlloyDB podem variar dos estadosSEQUENCEde origem.As tabelas
UNLOGGEDeTEMPORARYnão são e não podem ser replicadas.O tipo de dados de objeto grande não é compatível. Mais detalhes na seção sobre fidelidade da migração.
Somente extensões e linguagens procedurais que o AlloyDB oferece suporte para PostgreSQL podem ser migradas.
O Database Migration Service não oferece suporte à migração de réplicas de leitura que estão no modo de recuperação.
O Database Migration Service não oferece suporte a origens do Amazon RDS em que o pacote de extensão do AWS SCT é aplicado.
As funções definidas pelo usuário escritas em C não podem ser migradas, exceto as funções instaladas no banco de dados PostgreSQL ao instalar extensões com suporte do AlloyDB.
Se outras extensões e linguagens procedurais existirem no banco de dados de origem ou se as versões delas não forem compatíveis, o job de migração vai falhar quando você o testar ou iniciar.
Os bancos de dados adicionados após o início do job de migração não são migrados.
É possível selecionar bancos de dados específicos ao migrar usando o Database Migration Service. No entanto, não é possível selecionar tabelas ou esquemas específicos nesses bancos de dados. O Database Migration Service migra todas as tabelas e esquemas dos bancos de dados selecionados, exceto os seguintes:
- O esquema de informações (
information_schema). - Qualquer esquema que comece com
pg_(por exemplo,pg_catalog,pg_toast,pgtemp*). Para conferir a lista completa de catálogos do PostgreSQL que começam compg_, consulte Catálogos do sistema PostgreSQL na documentação do PostgreSQL. - As informações sobre usuários e funções de usuário não são migradas.
- O esquema de informações (
Se os bancos de dados criptografados exigirem chaves de criptografia gerenciadas pelo cliente para descriptografar os bancos de dados e se o Database Migration Service não tiver acesso às chaves, os bancos de dados não poderão ser migrados.
No entanto, se os dados do cliente forem criptografados pela extensão
pgcrypto, os dados poderão ser migrados com o Database Migration Service (porque o AlloyDB para PostgreSQL oferece suporte à extensão).O Database Migration Service também oferece suporte à migração de dados de bancos de dados criptografados do Amazon Aurora ou do Amazon RDS, porque esses bancos de dados processam a descriptografia de maneira transparente nos serviços deles. Para mais informações, consulte Criptografar recursos do Amazon Aurora e Criptografar recursos do Amazon RDS.
O banco de dados de destino do AlloyDB para PostgreSQL pode ser gravado durante a migração para permitir que as mudanças de DDL sejam aplicadas, se necessário. Não faça mudanças na configuração do banco de dados ou nas estruturas de tabelas que possam interromper o processo de migração ou afetar a integridade dos dados.
O comportamento do acionador depende de como eles foram configurados. O comportamento padrão é que eles não serão acionados, mas, se forem configurados usando a instrução
ALTER EVENT TRIGGERouALTER TABLEe o estado do acionador estiver definido como réplica ou sempre, eles serão acionados na réplica durante a replicação.As funções com definidor de segurança serão criadas por
alloydbexternalsyncno AlloyDB primário. Quando executado por qualquer usuário, ele será executado com os privilégios dealloydbexternalsync, que tem as funçõesalloydbsuperuserealloydbreplica. É melhor restringir o uso de uma função de definidor de segurança a apenas alguns usuários. Para fazer isso, o usuário precisa revogar os privilégios PUBLIC padrão e conceder o privilégio de execução seletivamente.O método de conectividade de interfaces do Private Service Connect só é compatível com a migração para instâncias de destino atuais. Se você quiser usar a conectividade de IP particular e migrar para uma nova instância de destino, use o peering de VPC.
Limitações para migrações para clusters de destino atuais
- Só é possível configurar um job de migração ativo por cluster de destino.
- O cluster de destino atual precisa estar vazio ou conter apenas dados de configuração do sistema. A migração para um cluster de destino atual que contém dados do usuário (como tabelas) não é compatível.
- A migração para clusters com instâncias de pool de leitura é compatível.
Para mais informações sobre clusters e instâncias do AlloyDB para PostgreSQL, consulte Visão geral do AlloyDB para PostgreSQL.
Cotas
- É possível ter a qualquer momento até 2.000 perfis de conexão e 1.000 jobs de migração. Se você quiser criar mais espaço para esses itens, os jobs de migração (incluindo os concluídos) e os perfis de conexão poderão ser excluídos.