Limitações conhecidas

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Vista geral

Antes de optar por migrar as suas bases de dados para o Cloud SQL, certifique-se de que considera as limitações conhecidas para este cenário de migração.

Nota: também pode usar o Centro de Migração do Google Cloud para descobrir possíveis limitações ou lacunas no suporte de funcionalidades para o seu cenário específico. Consulte o artigo Descubra e importe bases de dados na documentação do Centro de Migração.

As limitações conhecidas para usar uma base de dados PostgreSQL como origem incluem:

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

• As alterações às estruturas das tabelas (LDD) não são replicadas através de comandos LDD padrão, mas apenas com comandos executados através da extensão pglogical usada para replicação. Isto inclui alterações aos enum tipos.

  • Por exemplo, pglogical fornece uma função pglogical.replicate_ddl_command que permite executar DDL na base de dados de origem e na réplica num ponto consistente. O utilizador que executa este comando na origem já tem de existir na réplica.

  • Para replicar dados para novas tabelas, tem de usar o comando pglogical.replication_set_add_table para adicionar as novas tabelas a conjuntos de replicação existentes.

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

• Para tabelas que não têm chaves principais, o Database Migration Service suporta a migração da imagem instantânea inicial e das declarações INSERT durante a fase de captura de dados de alterações (CDC). Deve migrar as declarações UPDATE e DELETE manualmente.

• O Database Migration Service não migra dados de vistas materializadas, apenas o esquema de vistas. Para preencher as vistas, execute o seguinte comando: REFRESH MATERIALIZED VIEW view_name.

• Os estados SEQUENCE (por exemplo, last_value) no novo destino do Cloud SQL podem variar em relação aos estados SEQUENCE de origem.

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

• O tipo de dados de objeto grande não é suportado. Mais detalhes na secção sobre a fidelidade da migração.

• Só é possível migrar extensões e linguagens processuais que o Cloud SQL suporta para o PostgreSQL. O Database Migration Service não migra extensões não suportadas pelo Cloud SQL. A presença destas extensões não bloqueia a migração, mas, para garantir um processo de migração sem problemas, verifique se os seus objetos ou aplicações não fazem referência a extensões não suportadas. Recomendamos que remova estas extensões e referências da base de dados de origem antes de continuar.

• A extensão pg_cron (ou quaisquer definições cron associadas à extensão) não é migrada pelo serviço de migração de base de dados, mas é suportada em destinos do Cloud SQL para PostgreSQL. Se usar a extensão pg_cron nas bases de dados de origem, pode reinstalá-la na instância de destino depois de a migração estar concluída.

• O serviço de migração de bases de dados não suporta a migração a partir de réplicas de leitura que estejam no modo de recuperação.

• O serviço de migração de base de dados não suporta origens do Amazon RDS onde o pacote de extensão do AWS SCT é aplicado.

• As funções definidas pelo utilizador escritas em C não podem ser migradas, exceto as funções instaladas na base de dados PostgreSQL quando instala extensões suportadas pelo Cloud SQL.

• Se existirem outras extensões e linguagens processuais na base de dados de origem ou se as respetivas versões não forem suportadas, o teste ou o trabalho de migração falham.

• As bases de dados adicionadas após o início da tarefa de migração não são migradas.

• Não pode selecionar tabelas nem esquemas específicos quando migra através do serviço de migração de bases de dados. O Database Migration Service migra todas as tabelas e esquemas, exceto os seguintes:
  • O esquema de informações (information_schema).
  • Todas as tabelas que começam por pg, por exemplo, pg_catalog. Para ver a lista completa de catálogos do PostgreSQL que começam por pg, consulte Catálogos do sistema PostgreSQL na documentação do PostgreSQL.
  • As informações sobre os utilizadores e as funções de utilizador não são migradas.

• Se as bases de dados encriptadas exigirem chaves de encriptação geridas pelo cliente para desencriptar as bases de dados e se o Database Migration Service não tiver acesso às chaves, não é possível migrar as bases de dados.

  No entanto, se os dados de clientes estiverem encriptados pela extensão pgcrypto, os dados podem ser migrados com o serviço de migração de base de dados (porque o Cloud SQL é compatível com a extensão).

  O serviço de migração de bases de dados também suporta a migração de dados de bases de dados Amazon Aurora ou Amazon RDS encriptadas, uma vez que estas bases de dados processam a desencriptação de forma transparente nos respetivos serviços. Para mais informações, consulte os artigos Encriptar recursos do Amazon Aurora e Encriptar recursos do Amazon RDS.

• A base de dados do Cloud SQL de destino é gravável durante a migração para permitir que as alterações de DDL sejam aplicadas, se necessário. Tenha cuidado para não fazer alterações à configuração da base de dados nem às estruturas das tabelas que possam interromper o processo de migração ou afetar a integridade dos dados.

• O comportamento do acionador depende da forma como foram configurados. Por predefinição, não são acionados, mas, se tiverem sido configurados através da declaração ALTER EVENT TRIGGER ou ALTER TABLE e o estado do acionador estiver definido como réplica ou sempre, são acionados na réplica durante a replicação.

• As funções com o definidor de segurança são criadas por cloudsqlexternalsync na réplica do Cloud SQL. Quando é executado por qualquer utilizador, é executado com os privilégios de cloudsqlexternalsync, que tem as funções cloudsqlsuperuser e cloudsqlreplica. É melhor restringir a utilização de uma função de definidor de segurança apenas a alguns utilizadores. Para tal, o utilizador deve revogar os privilégios PUBLIC predefinidos e, em seguida, conceder o privilégio de execução seletivamente.

• O Cloud SQL não suporta espaços de tabelas personalizados. Todos os dados nos espaços de tabelas personalizados são migrados para o espaço de tabelas pg_default na instância de destino do Cloud SQL.

• O método de conetividade das interfaces do Private Service Connect só é suportado para a migração para instâncias de destino existentes. Se quiser usar a conetividade IP privada e migrar para uma nova instância de destino, use o peering de VPC.

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

  • A instância de destino existente tem de estar vazia ou conter apenas dados de configuração do sistema. A migração para instâncias de destino existentes que contenham dados do utilizador (como tabelas) não é suportada.

    Se encontrar problemas devido a dados adicionais na instância de destino existente, limpe as bases de dados na instância de destino e tente novamente a tarefa de migração. Consulte o artigo Limpe os dados adicionais da instância de destino existente.

  • Só pode configurar uma tarefa de migração por instância de destino.
  • Só pode migrar para instâncias autónomas do Cloud SQL. A migração para réplicas de servidores externos não é suportada.
  • A migração de dados para uma instância do Cloud SQL com o Private Service Connect ativado não é suportada.
  • Depois de promover uma instância, tem de ativar a recuperação num determinado momento.
  • Se a sua instância tiver definições de cópia de segurança personalizadas (por exemplo, uma localização de cópia de segurança personalizada), depois de promover a instância, tem de personalizar novamente as definições de cópia de segurança. Durante o processo de promoção, o Cloud SQL repõe as definições de cópia de segurança para os respetivos valores predefinidos.
  • Para utilizadores do Terraform: o serviço de migração de bases de dados modifica as definições de cópia de segurança e recuperação da instância de destino. Isto pode fazer com que as definições da instância de destino sejam diferentes da configuração do Terraform que usou para o aprovisionamento. Se tiver este problema, siga as orientações em Diagnosticar problemas.

  Quotas

  • Podem existir até 2000 perfis de ligação e 1000 tarefas de migração em qualquer altura. Para criar espaço para mais, pode eliminar tarefas de migração (incluindo as concluídas) e perfis de ligação.