Esta página foi traduzida pela API Cloud Translation.

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 para esse cenário de migração.

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 Cloud SQL 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 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 um processo tranquilo, verifique se os 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 prosseguir.
A extensão pg_cron (ou qualquer configuração cron associada à extensão) não é migrada pelo Database Migration Service, mas é compatível com destinos do Cloud SQL para PostgreSQL. Se você usar a extensão pg_cron nos bancos de dados de origem, poderá reinstalá-la na instância de destino depois que a migração for concluída.

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 compatíveis com o Cloud SQL.

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 Cloud SQL 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 do Cloud SQL de destino é 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 cloudsqlexternalsync na réplica do Cloud SQL. Quando ele é executado por qualquer usuário, ele é executado com os privilégios de cloudsqlexternalsync, que tem 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 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.
O Cloud SQL não é compatível com espaços de tabela personalizados. Todos os dados nos 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

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 existentes que 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 sua instância de destino atual.
É possível configurar apenas 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 servidor externo.
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.
Se a instância tiver 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 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 Como 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.