Limitações conhecidas

Antes de migrar seus bancos de dados para o Cloud SQL, 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.
    • 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.

  • 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). 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. A configuração de 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.

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

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

  • Somente as extensões compatíveis com o Cloud SQL para PostgreSQL podem ser migradas. O Database Migration Service não migra extensões que não são compatíveis com o Cloud SQL. A presença dessas extensões não bloqueia a migração, mas, para garantir uma migração tranquila, verifique se os aplicativos não fazem referência a extensões sem suporte. Para ver a lista de extensões compatíveis, consulte Extensões do PostgreSQL na documentação do Cloud SQL.

  • A extensão pg_cron (ou qualquer cron job configurado nela) não é migrada pelo Database Migration Service, mas é compatível com destinos do Cloud SQL para PostgreSQL. Se você usa pg_cron nos bancos de dados de origem, reinstale a extensão e configure os cron jobs na instância 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 Cloud SQL.

  • Se houver outras extensões no banco de dados de origem e as versões delas não forem compatíveis com o Cloud SQL, o teste ou o início do job de migração vai falhar.

  • 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 Cloud SQL é 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.

  • Comportamento operacional do banco de dados de destino durante a migração:

    • Banco de dados de destino gravável: o Cloud SQL para PostgreSQL não executa o banco de dados de destino no modo somente leitura durante a migração. A instância de destino não é rebaixada quando criada pelo Database Migration Service.

    • Evite operações de gravação em dados de migração: não execute operações de gravação (como INSERT, UPDATE, DELETE ou alterações de esquema DDL) em tabelas ou bancos de dados que participam da migração. A execução de gravações em dados de migração pode resultar em conflitos de replicação com o fluxo de captura de dados alterados (CDC) recebido.

    • Gerenciar usuários do banco de dados: é possível criar e gerenciar usuários do banco de dados a qualquer momento usando comandos psql padrão ou pelo Cloud SQL no console do Google Cloud . Para mais informações, consulte Gerenciar usuários na documentação do Cloud SQL.

    • Recursos suspensos: os backups automatizados e a recuperação pontual (PITR, na sigla em inglês) são suspensos durante a replicação contínua. Além disso, não é possível criar réplicas de leitura do Cloud SQL na instância de destino até que o job de migração seja promovido.

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

  • As funções definidas com SECURITY DEFINER são criadas por cloudsqlexternalsync na instância de destino do Cloud SQL, que tem privilégios elevados. Restrinja os privilégios de execução em funções sensíveis do SECURITY DEFINER revogando permissões públicas e concedendo acesso seletivamente.

  • O Cloud SQL não é compatível com espaços de tabela personalizados. Todos os objetos dentro de espaços de tabela personalizados são migrados para o espaço de tabela padrão pg_default no Cloud SQL.

  • O método de conectividade de interfaces do Private Service Connect é compatível apenas com a migração para instâncias de destino atuais. Se você quiser usar a conexão por IP particular e migrar para uma nova instância de destino, use o peering de VPC.

Limitações para migrações para instâncias de destino atuais

  • Rebaixamento da instância de destino para migrações padrão: para migrações padrão para instâncias atuais do Cloud SQL, o Database Migration Service rebaixa a instância independente para configurá-la como uma réplica externa do banco de dados de origem.
    • O rebaixamento da instância não coloca o mecanismo do PostgreSQL no modo somente leitura, mas é preciso evitar operações de gravação em tabelas de migração para evitar conflitos de replicação.
    • O rebaixamento da instância suspende os backups automatizados e a recuperação pontual (PITR, na sigla em inglês) e impede a adição de réplicas de leitura do Cloud SQL até a promoção.
    • É preciso confirmar o rebaixamento ao criar o job de migração no console do Google Cloud inserindo o ID da instância 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 da instância de destino.
  • A instância de destino atual só pode conter bancos de dados padrão do sistema que são configurados automaticamente quando você cria a instância de destino. Não é possível migrar para instâncias de destino que já existem e contêm dados do usuário.

    Se você tiver problemas devido a dados extras na instância de destino, limpe os bancos de dados nela e tente executar o job de migração novamente. Consulte Limpar dados extras da instância de destino atual.

  • Só é possível configurar um job de migração por instância de destino.
  • Só é possível migrar para instâncias independentes do Cloud SQL. Não é possível migrar para réplicas de servidor externo.
  • Depois de promover uma instância, é necessário ativar a recuperação pontual.
  • Se a instância tiver configurações de backup personalizadas (por exemplo, um local de backup personalizado), será necessário restaurar as configurações de backup novamente após a promoção. Durante o processo de promoção, o Cloud SQL redefine as configurações de backup para os valores padrão.
  • Para usuários do Terraform: o Database Migration Service modifica as configurações de backup e recuperação da instância de destino. Isso pode fazer com que as configurações da instância de destino sejam diferentes da configuração do Terraform usada para provisionamento. Se você tiver esse problema, consulte as orientações em Diagnosticar problemas.

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.

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