Limitações conhecidas

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Visão geral

Antes de migrar seus bancos de dados para o Cloud SQL, considere as limitações conhecidas desse cenário de migração.

Observação: também é possível usar a Central de migração do Google Cloud para descobrir possíveis limitações ou lacunas no suporte a recursos para seu cenário específico. Consulte Descobrir e importar bancos de dados na documentação do Migration Center.

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

• A extensão pglogical não é compatível com a replicação de colunas geradas para PostgreSQL 12 ou versões mais recentes.

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

  • 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 de 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 do snapshot inicial e das instruções INSERT durante a fase de captura de dados alterados (CDC). Migre as instruções UPDATE e DELETE manualmente.

• O Database Migration Service não migra dados de visualizações materializadas, apenas o esquema da 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 Cloud SQL 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 Large Object não é compatível. Mais detalhes na seção sobre fidelidade da migração.

• Somente extensões e linguagens procedurais compatíveis com o Cloud SQL para PostgreSQL podem ser migradas. O Database Migration Service não migra extensões sem suporte do Cloud SQL. A presença dessas extensões não bloqueia a migração, mas para garantir um processo tranquilo, verifique se seus objetos ou aplicativos não fazem referência a extensões sem suporte. Recomendamos remover essas extensões e referências do banco de dados de origem antes de continuar.

• A extensão pg_cron (ou qualquer configuração cron associada a ela) não é migrada pelo Database Migration Service, mas é compatível com destinos do Cloud SQL para PostgreSQL. Se você usa a extensão pg_cron nos bancos de dados de origem, é possível reinstalá-la 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 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 no banco de dados PostgreSQL ao instalar extensões compatíveis com o Cloud SQL.

• Se houver outras extensões e linguagens procedimentais no banco de dados de origem ou se as versões delas não forem compatíveis, o teste ou o job de migração vai falhar.

• Os bancos de dados adicionados depois do início do job 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).
  • Qualquer tabela que comece com pg, por exemplo, pg_catalog. Para conferir a lista completa de catálogos do 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 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, eles poderão ser migrados com o Database Migration Service, já que o Cloud SQL é compatível com a 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 maneira transparente nos serviços. Para mais informações, consulte Criptografar recursos do Amazon Aurora e Criptografar recursos do Amazon RDS.

• O banco de dados de destino do Cloud SQL pode ser gravado durante a migração para permitir que as mudanças de DDL sejam aplicadas, se necessário. Tenha cuidado para não fazer mudanças na configuração do banco de dados ou nas estruturas de tabela que possam interromper o processo de migração ou afetar a integridade dos dados.

• O comportamento do gatilho depende de como ele foi configurado. O comportamento padrão é que eles não sejam acionados, mas, se forem configurados usando a instrução ALTER EVENT TRIGGER ou ALTER TABLE e o estado de acionamento for definido como "replica" ou "always", eles serão acionados na réplica durante a replicação.

• As funções com definidor de segurança serão criadas por cloudsqlexternalsync na réplica do Cloud SQL. Quando executado por qualquer usuário, ele é executado com os privilégios de cloudsqlexternalsync, que tem as funções cloudsqlsuperuser e cloudsqlreplica. É melhor restringir o uso de uma função de definição de segurança a apenas alguns usuários. Para isso, o usuário precisa revogar os privilégios PUBLIC padrão e conceder o privilégio de execução seletivamente.

• O Cloud SQL não é compatível com espaços de tabela personalizados. Todos os dados dentro de espaços de tabela personalizados são migrados para o espaço de tabela pg_default na instância de destino do Cloud SQL.

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

• A instância de destino precisa estar vazia ou conter apenas dados de configuração do sistema. Não é possível migrar para instâncias de destino que já existem e contêm dados do usuário (como tabelas).

  Se você encontrar problemas devido a dados extras na instância de destino atual, limpe os bancos de dados na instância de destino e tente novamente o job de migração. 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 autônomas do Cloud SQL. Não é possível migrar para réplicas de servidores externos.
• Não é possível migrar dados para uma instância do Cloud SQL que tenha o Private Service Connect ativado.
• Depois de promover uma instância, ative a recuperação pontual.
• Caso sua instância tenha configurações de backup personalizadas, como um local de backup personalizado, personalize as configurações de backup novamente após promover a instância. Durante o processo de promoção, o Cloud SQL redefine suas 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 sua 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, siga 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. 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.