Limitações conhecidas

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

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

• A extensão pglogical não oferece suporte à replicação de colunas geradas para o PostgreSQL 12 ou mais recente.

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

  • 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 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 INSERT durante a fase de captura de dados alterados (CDC). Você precisa 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 do AlloyDB podem variar dos estados SEQUENCE de origem.

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

• Não há suporte para o tipo de dados de objeto grande. Mais detalhes na seção sobre fidelidade de migração.

• Somente as extensões e linguagens procedurais com suporte do AlloyDB para PostgreSQL podem ser migradas.

• Database Migration Service dados 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 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 ao 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ê testar ou iniciar.

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

• Não é possível selecionar objetos de banco de dados específicos (como bancos de dados, tabelas ou esquemas) ao migrar usando Database Migration Service. Todas as tabelas de todos os bancos de dados e esquemas são migradas como parte da migração do banco de dados, exceto os seguintes esquemas:

  • O esquema de informações (information_schema)
  • Qualquer esquema que comece com pg (por exemplo, pg_catalog, que contém as tabelas do sistema e todos os tipos de dados, funções e operadores integrados e existe automaticamente em todos os bancos de dados). Como resultado, as informações sobre usuários e funções de usuário não são migradas. Confira a lista completa de esquemas que começam com pg.

• Se os bancos de dados criptografados exigirem chaves de criptografia gerenciadas pelo cliente para descriptografar os bancos de dados e 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, 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 do Amazon RDS, porque eles processam a descriptografia de forma transparente nos serviços. Para mais informações, consulte Como criptografar recursos do Amazon Aurora e Como criptografar recursos do Amazon RDS.

• O banco de dados de destino do AlloyDB é gravável durante a migração para permitir que as mudanças de DDL sejam aplicadas, se necessário. Tome cuidado para não fazer nenhuma mudança 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 ele foi configurado. O comportamento padrão é que elas não serão acionadas, mas se tiverem sido configuradas usando a instrução ALTER EVENT TRIGGER ou ALTER TABLE e o estado do acionador estiver definido como réplica ou sempre, elas serão acionadas na réplica durante a replicação.

• As funções com o definidor de segurança serão criadas por alloydbexternalsync no primário do AlloyDB. Quando ele é executado por qualquer usuário, ele é executado com os privilégios de alloydbexternalsync, que tem 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 fazer isso, o usuário precisa revogar os privilégios PÚBLICOS padrão e conceder o privilégio de execução de forma seletiva.

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

• O cluster de destino atual precisa estar vazio ou conter apenas dados de configuração do sistema. Não é possível migrar para um cluster de destino existente que contenha dados do usuário (como tabelas).
• É possível configurar apenas um job de migração por cluster de destino.
• Não é possível migrar para clusters com clusters secundários.
• 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 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.