Limitações conhecidas

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Limitações conhecidas para o uso de um banco de dados PostgreSQL como fonte:

• A extensão pglogical não é compatível com a replicação de colunas geradas para PostgreSQL 12 ou versões mais recentes.

• As mudanças nas estruturas de tabela (DDL) não são replicadas com comandos DDL padrão, mas apenas com comandos executados usando a extensão pglogical usada para replicação. Isso inclui mudanças nos tipos enum.

  • Por exemplo, pglogical fornece uma função pglogical.replicate_ddl_command que permite que a DDL seja executada no banco de dados de origem e 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_table para 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 do snapshot inicial e das instruções INSERT durante a fase de captura de dados alterados (CDC). Migre as instruções UPDATE e DELETE manualmente.

• O Database Migration Service não migra dados de visualizações materializadas, apenas o esquema da 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 estados SEQUENCE de origem.

• As tabelas UNLOGGED e TEMPORARY não são e não podem ser replicadas.

• O tipo de dados Large Object não é compatível. Mais detalhes na seção sobre fidelidade da migração.

• Somente extensões e linguagens procedurais compatíveis com o AlloyDB para PostgreSQL podem ser migradas.

• O Database Migration Service não é compatível com a migração de réplicas de leitura no modo de recuperação.

• O Database Migration Service não é compatível com 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 compatíveis com o AlloyDB.

• Se houver outras extensões e linguagens procedimentais no banco de dados de origem ou se as versões delas não forem compatíveis, o teste ou o job de migração vai falhar.

• Os bancos de dados adicionados depois do início do job de migração não são migrados.

• Não é possível selecionar tabelas ou esquemas específicos ao migrar usando o Database Migration Service. O Database Migration Service migra todas as tabelas e esquemas, exceto os seguintes:
  • O esquema de informações (information_schema).
  • Qualquer tabela que comece com pg, por exemplo, pg_catalog. Para conferir a lista completa de catálogos do PostgreSQL que começam com pg, consulte Catálogos do sistema PostgreSQL na documentação do PostgreSQL.
  • As informações sobre usuários e funções não são migradas.

• 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, eles poderão ser migrados com o Database Migration Service, já que o AlloyDB é compatível com a 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 eles processam a descriptografia de maneira transparente nos serviços. Para mais informações, consulte Criptografar recursos do Amazon Aurora e Criptografar recursos do Amazon RDS.

• O banco de dados de destino do AlloyDB pode ser gravado durante a migração para permitir que as mudanças de DDL sejam aplicadas, se necessário. Tenha cuidado para não fazer mudanças na configuração do banco de dados ou nas estruturas de tabela que possam interromper o processo de migração ou afetar a integridade dos dados.

• O comportamento do gatilho depende de como ele foi configurado. O comportamento padrão é que eles não sejam acionados, mas, se forem configurados usando a instrução ALTER EVENT TRIGGER ou ALTER TABLE e o estado de acionamento for definido como "replica" ou "always", eles serão acionados na réplica durante a replicação.

• As funções com definidor de segurança serão criadas por alloydbexternalsync no AlloyDB principal. Quando executado por qualquer usuário, ele é executado com os privilégios de alloydbexternalsync, que tem as funções alloydbsuperuser e alloydbreplica. É melhor restringir o uso de uma função de definição de segurança a apenas alguns usuários. Para 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 das 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

• O cluster de destino precisa estar vazio ou conter apenas dados de configuração do sistema. Não é possível migrar para um cluster de destino que contenha dados do usuário (como tabelas).
• Só é possível configurar um job de migração por cluster de destino.
• A migração para clusters com clusters secundários não é compatível.
• A migração para clusters com instâncias do pool de leitura é compatível.

  Para mais informações sobre clusters e instâncias do AlloyDB para PostgreSQL, consulte a 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 podem ser excluídos.