Limitações conhecidas

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

As limitações conhecidas para usar um banco de dados PostgreSQL como fonte incluem:

• A extensão pglogical não suporta a replicação de colunas geradas para PostgreSQL 12+.

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

  • Por exemplo, pglogical fornece uma função pglogical.replicate_ddl_command que permite que o DDL seja executado no banco de dados de origem e na réplica em um ponto consistente. O usuário que executa esse comando na origem já deve existir na réplica.

  • Para replicar dados para novas tabelas, você deve usar o comando pglogical.replication_set_add_table para adicionar as novas tabelas aos conjuntos de replicação existentes.

  • Para saber mais sobre a replicação DDL enquanto a migração está em andamento, consulte a seção sobre fidelidade de migração .

• Para tabelas que não têm chaves primárias, o Database Migration Service oferece suporte à migração do instantâneo inicial e das instruções INSERT durante a fase de captura de dados de alteração (CDC) . Você deve migrar as instruções UPDATE e DELETE manualmente.

• 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 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 Objeto Grande não é compatível. Mais detalhes na seção sobre fidelidade migratória .

• Somente extensões e linguagens procedurais suportadas pelo AlloyDB para PostgreSQL podem ser migradas.

• O Database Migration Service não dá 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 fontes do Amazon RDS onde o pacote de extensão AWS SCT é aplicado.

• Funções definidas pelo usuário escritas em C não podem ser migradas, exceto funções instaladas no banco de dados PostgreSQL quando você instala extensões suportadas pelo AlloyDB.

• Se existirem outras extensões e linguagens procedurais no banco de dados de origem, ou se suas versões não forem suportadas, quando você testar ou iniciar o trabalho de migração, ele falhará.

• Os bancos de dados adicionados após o início do trabalho 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 ).
  • Quaisquer tabelas que comecem com pg , por exemplo, pg_catalog . Para obter a lista completa de catálogos 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 de usuário 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 , os dados poderão ser migrados com o Database Migration Service (porque o AlloyDB 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 Amazon RDS porque esses bancos de dados lidam com a descriptografia de forma transparente em seus serviços. Para obter mais informações, consulte Criptografar recursos do Amazon Aurora e Criptografar recursos do Amazon RDS .

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

• O comportamento do gatilho depende de como eles foram configurados. O comportamento padrão é que eles não serão acionados, mas se tiverem sido configurados usando a instrução ALTER EVENT TRIGGER ou ALTER TABLE e o estado do acionador estiver definido como réplica ou sempre, eles serão acionados na réplica durante a replicação.

• Funções com definidor de segurança serão criadas por alloydbexternalsync no AlloyDB primário. Quando for executado por qualquer usuário, será executado com os privilégios de alloydbexternalsync que possui funções alloydbsuperuser e alloydbreplica . É melhor restringir o uso de uma função de definidor de segurança apenas a alguns usuários. Para fazer isso, o usuário deve revogar os privilégios PUBLIC padrão e então conceder o privilégio de execução seletivamente.

Limitações para migrações para clusters de destino existentes

• O cluster de destino existente deve estar vazio ou conter apenas dados de configuração do sistema. A migração para o cluster de destino existente que contém dados do usuário (como tabelas) não é compatível.
• Você pode configurar apenas um trabalho 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 de pool de leitura é suportada .

  Para obter mais informações sobre clusters e instâncias do AlloyDB for PostgreSQL, consulte Visão geral do AlloyDB for PostgreSQL .

Cotas

• Podem existir até 2.000 perfis de conexão e 1.000 trabalhos de migração a qualquer momento. Para criar espaço para mais, os trabalhos de migração (incluindo os concluídos) e os perfis de conexão podem ser excluídos.