Limitações conhecidas

Antes de migrar seus bancos de dados para o AlloyDB para PostgreSQL, considere as limitações conhecidas para esse cenário de migração.

As limitações conhecidas do uso de um banco de dados PostgreSQL como origem incluem:

  • A extensão pglogical não é compatível com a replicação de colunas geradas para o PostgreSQL 12+.

  • As alterações 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 replicação. Isso inclui mudanças nos tipos de enum.

    • Por exemplo, o pglogical fornece a 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 tabelas recém-criadas, use o comando pglogical.replication_set_add_table para adicionar 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 Fidelidade da migração.

  • Limitações de objetos:

    • As tabelas externas não são replicadas pela replicação lógica.
    • As tabelas UNLOGGED e TEMPORARY não são e não podem ser replicadas.
    • O tipo de dados de objeto grande (oid referenciando pg_largeobject) não é compatível com a decodificação lógica do PostgreSQL.
    • O Database Migration Service não migra dados de visualizações materializadas, apenas o esquema da visualização. Para preencher as visualizações no banco de dados de destino, execute: REFRESH MATERIALIZED VIEW view_name;.
    • Os estados SEQUENCE (por exemplo, last_value) no destino podem variar da origem durante a CDC em andamento. Os valores de sequência são sincronizados durante a etapa final de promoçã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). A migração de instruções UPDATE e DELETE é diferente para:

    • Migrações padrão: as instruções UPDATE e DELETE não são migradas para tabelas sem chaves primárias. É necessário adicionar chaves primárias para as colunas antes de migrar ou migrar as instruções UPDATE e DELETE manualmente.
    • Migrações de início rápido: com as migrações de início rápido, as chaves primárias não são necessárias para replicar as operações UPDATE e DELETE se você definir a identidade da réplica como INDEX ou FULL. Configurar REPLICA IDENTITY FULL aumenta o volume do registro prévio de escrita (WAL) e a sobrecarga de recursos. Recomendamos adicionar uma chave primária sempre que possível. Para mais informações, consulte a documentação sobre identidade de réplica do PostgreSQL e o guia de migração de início rápido.

  • Somente as extensões e as versões de extensão compatíveis com o AlloyDB para PostgreSQL podem ser migradas. O Database Migration Service não migra extensões que não são compatíveis com o AlloyDB para PostgreSQL. Se houver extensões no banco de dados de origem com versões não compatíveis com o AlloyDB para PostgreSQL, o teste ou o início do job de migração poderá falhar. Para garantir uma migração tranquila, verifique se as extensões de origem são compatíveis e se os aplicativos não fazem referência a extensões incompatíveis. Para ver a lista de extensões compatíveis, consulte Extensões compatíveis na documentação do AlloyDB para PostgreSQL.

  • A extensão pg_cron (ou qualquer cron job configurado nela) não é migrada pelo Database Migration Service, mas é compatível com destinos do AlloyDB para PostgreSQL. Se você usa pg_cron nos bancos de dados de origem, reinstale a extensão e configure os cron jobs no cluster de destino após a conclusão da migração.

  • O Database Migration Service não é compatível com a migração de réplicas de leitura que estão 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 ao criar extensões compatíveis com o AlloyDB para PostgreSQL.

  • Os bancos de dados adicionados à instância de origem 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. Todas as tabelas e esquemas dos bancos de dados selecionados são migrados, exceto:

    • O esquema de informações (information_schema).
    • Qualquer esquema que comece com pg_ (por exemplo, pg_catalog, pg_toast, pgtemp*). Para ver a lista completa de catálogos do PostgreSQL que começam com pg_, consulte Catálogos do sistema PostgreSQL na documentação do PostgreSQL.
    • Credenciais de login e funções do usuário.

  • Se os bancos de dados criptografados exigirem chaves de criptografia gerenciadas pelo cliente (CMEK) para descriptografar dados e o Database Migration Service não tiver acesso às chaves, os bancos de dados não poderão ser migrados. No entanto, os dados criptografados com a extensão pgcrypto podem ser migrados porque o AlloyDB para PostgreSQL é compatível com pgcrypto. O Database Migration Service também é compatível com a migração de bancos de dados criptografados do Amazon Aurora ou do Amazon RDS, porque a AWS lida com a descriptografia de maneira transparente. Para mais informações, consulte Como criptografar recursos do Amazon Aurora e Como criptografar recursos do Amazon RDS.

  • Os bancos de dados em migração não são protegidos contra gravação durante a migração: o AlloyDB para PostgreSQL não executa a instância de destino no modo somente leitura durante a migração. Embora seja possível se conectar ao cluster de destino para criar e gerenciar usuários do banco de dados ou aplicar as mudanças de esquema necessárias (DDL), não execute operações de gravação (como INSERT, UPDATE ou DELETE) em bancos de dados ou tabelas que estão sendo migrados. A gravação em dados em migração pode causar conflitos de replicação ou falhas de migração.

  • O comportamento do gatilho depende da configuração dele. Por padrão, os gatilhos não são disparados na réplica durante a replicação, a menos que sejam configurados com ALTER EVENT TRIGGER ou ALTER TABLE ... ENABLE ALWAYS TRIGGER.

  • Os espaços de tabela personalizados são mapeados para o espaço de tabela padrão pg_default no AlloyDB para PostgreSQL.

  • O método de conectividade de interfaces do Private Service Connect é compatível apenas com a migração para clusters de destino atuais. Se você quiser usar a conectividade de IP particular e migrar para um novo cluster de destino em uma migração padrão, use o peering de VPC.

  • A autenticação de banco de dados do Identity and Access Management para clusters de destino não é compatível. O Database Migration Service se conecta ao banco de dados de destino usando a autenticação de usuário do banco de dados. Para mais informações sobre o IAM, consulte Gerenciar a autenticação do IAM na documentação do AlloyDB para PostgreSQL.

Funções de definidor de segurança

As funções definidas com SECURITY DEFINER são executadas com os privilégios do usuário que é proprietário da função, não do usuário que a executa.

Durante a migração contínua para o AlloyDB para PostgreSQL, as rotinas definidas com SECURITY DEFINER passam a ser de propriedade do usuário do serviço de migração interna alloydbexternalsync na instância principal de destino. Como alloydbexternalsync tem privilégios de administrador elevados, incluindo os papéis alloydbsuperuser e alloydbreplica, qualquer usuário autorizado a executar essas funções as executa com todos os direitos de alloydbsuperuser. Isso cria um risco não intencional de escalonamento de privilégios.

Para corrigir esse risco, audite todas as funções SECURITY DEFINER no cluster de destino e revogue os privilégios de execução pública imediatamente após a migração:

REVOKE EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) TO "AUTHORIZED_USER";

Alinhamento de agrupamento e localidade

O AlloyDB para PostgreSQL usa por padrão as localidades C.UTF-8 e en_US.utf8 fornecidas por libc. Todas as outras localidades no AlloyDB para PostgreSQL usam agrupamentos de componentes internacionais para Unicode (ICU).

Se o banco de dados de origem usar uma ordenação padrão com base em outra localidade libc, esse padrão não será transferido automaticamente. Para garantir uma classificação consistente para consultas que usam ORDER BY, talvez seja necessário atualizar as tabelas com agrupamentos explícitos da ICU após a migração. Para mais informações, consulte Locais compatíveis com dados importados na documentação do AlloyDB para PostgreSQL.

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

  • Só é possível configurar um job de migração ativo por cluster de destino.
  • Rebaixamento do cluster de destino para migrações padrão: para migrações padrão para clusters do AlloyDB para PostgreSQL, o Database Migration Service rebaixa o cluster independente para configurá-lo como uma réplica externa do banco de dados de origem.
    • É preciso confirmar o rebaixamento ao criar o job de migração no console do Google Cloud inserindo o ID do cluster de destino (ou executando gcloud database-migration migration-jobs demote-destination).
    • As migrações de início rápido usam a replicação lógica do PostgreSQL pgnative e não exigem nem realizam o rebaixamento do cluster de destino.
  • Para migrações padrão, o cluster de destino atual precisa estar vazio ou conter apenas dados de configuração padrão do sistema. Não é possível migrar para um cluster de destino atual que contenha dados do usuário (como tabelas) em migrações padrão.

    Se você encontrar problemas devido a dados extras no cluster de destino, limpe os bancos de dados no cluster de destino e tente novamente o job de migração. Consulte Limpar dados extras do cluster de destino atual.

  • 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.

Considerações sobre o paralelismo de despejo de dados

Ao criar um job de migração, é possível aumentar o número de assinaturas paralelas para acelerar o despejo de dados inicial e a replicação contínua da captura de dados alterados (CDC). O uso de configurações de paralelismo de despejo de dados mais altas também aumenta a utilização de conexões e recursos no banco de dados de origem e no cluster de destino do AlloyDB para PostgreSQL.

  • Verifique se o banco de dados de origem tem CPU, memória e margem de E/S suficientes antes de usar o paralelismo Máximo.
  • Ao usar o paralelismo de despejo de dados ajustado, é necessário configurar valores mais altos para max_replication_slots, max_wal_senders e max_worker_processes no banco de dados de origem. Para cálculos detalhados de parâmetros, consulte Configurar o banco de dados de origem.
  • A extensão pglogical replica dados no nível da tabela durante o despejo completo inicial. Uma única tabela não particionada é atribuída a uma assinatura e não é dividida em várias assinaturas paralelas ou linhas de execução de worker.
  • A extensão pglogical replica partições de folha individuais como tabelas separadas e pode distribuir várias partições de folha em assinaturas paralelas durante o despejo completo inicial. Uma única partição de folha grande não pode ser dividida em várias assinaturas e é copiada por uma única linha de execução.
  • O Database Migration Service classifica as tabelas por tamanho e as distribui em assinaturas paralelas. O Database Migration Service cria até duas assinaturas por banco de dados (e até duas no total em todos os bancos de dados) para paralelismo Ideal e até quatro assinaturas por banco de dados (e até quatro no total em todos os bancos de dados) para paralelismo Máximo, com pelo menos uma assinatura por banco de dados migrado. Por exemplo, se um banco de dados tiver uma tabela de 1 TB e várias tabelas pequenas, o Database Migration Service vai isolar a tabela de 1 TB em uma assinatura e distribuir as tabelas menores entre as assinaturas restantes. Mesmo com várias assinaturas ativas, a velocidade geral do despejo inicial ainda é limitada pelo tempo necessário para copiar a única tabela de 1 TB.
  • O Database Migration Service atribui tabelas sem chaves primárias a conjuntos de replicação dedicados somente de inserção (um por assinatura paralela). Várias tabelas sem chaves primárias podem ser distribuídas em assinaturas paralelas, mas, durante o despejo completo inicial, cada tabela individual é copiada como um único fluxo de tabela em uma assinatura e não é dividida em várias linhas de execução paralelas.

Cotas

  • É possível ter a qualquer momento até 2.000 perfis de conexão e 1.000 jobs de migração. Para liberar espaço, exclua os jobs de migração e os perfis de conexão que não estão sendo usados. Para mais detalhes, consulte Cotas e limites.

Compatibilidade de versões de extensão do PostgreSQL durante upgrades de versões principais

Quando você migra para uma versão principal mais recente do PostgreSQL, o Database Migration Service usa o utilitário pg_restore, que instala a versão de extensão padrão da versão principal de destino do PostgreSQL. Não é possível especificar uma versão exata da extensão para o utilitário pg_restore.

Se o banco de dados de origem usar uma versão de extensão incompatível com o esquema da versão padrão instalada na versão principal do PostgreSQL de destino, a migração poderá falhar devido a uma incompatibilidade de esquema ou a erros internos.

Para evitar falhas na migração, verifique a compatibilidade do esquema. Antes de migrar, faça upgrade das extensões no banco de dados de origem para uma versão compatível com a versão principal do PostgreSQL de destino.

A seguir