O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Configurar o banco de dados PostgreSQL de origem para migrações contínuas

Nesta página, descrevemos como configurar as instâncias do banco de dados de origem para migrações homogêneas contínuas do PostgreSQL para clusters do AlloyDB para PostgreSQL. Para detalhes sobre as versões de origem compatíveis, consulte Bancos de dados de origem e destino compatíveis. Se você quiser usar as migrações de início rápido, siga o guia Usar migrações de início rápido. As migrações de início rápido oferecem um fluxo de migração simplificado que usa a replicação do pgnative e a conectividade especializada com base nas interfaces do Private Service Connect. Para mais informações, consulte Sobre as migrações de início rápido na documentação principal do Database Migration Service.

Esta página inclui procedimentos independentes para cada origem compatível:

PostgreSQL autogerenciado (no local ou em uma VM do Compute Engine)
Amazon RDS para PostgreSQL
Amazon Aurora para PostgreSQL
Cloud SQL para PostgreSQL

Configurar uma origem do PostgreSQL auto-hospedada

Para configurar uma instância de origem do PostgreSQL autohospedada (no local ou hospedada em uma VM do Compute Engine) para migração contínua, conclua as seguintes etapas:

Para origens do PostgreSQL auto-hospedadas, o Database Migration Service migra todos os bancos de dados na instância de origem, exceto os bancos de dados de modelo template0 e template1.
Verifique se a instância de origem inclui o banco de dados postgres padrão. Se esse banco de dados não existir, crie-o antes de configurar a migração.
Configure a autenticação do cliente de rede no arquivo pg_hba.conf. Adicione entradas que permitam conexões de replicação e acesso ao banco de dados pelo intervalo de endereços IP do cluster de destino do AlloyDB para PostgreSQL, pelo intervalo CIDR da VPC ou pelo bastion host de SSH reverso:
```
# Allow replication connections
host  replication  MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5
# Allow database access
host  all          MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5
```
Recarregue a configuração do PostgreSQL para aplicar as regras pg_hba.conf:
```
SELECT pg_reload_conf();
```
Verifique as extensões do PostgreSQL instaladas nos bancos de dados de origem. O Database Migration Service não migra extensões que não são compatíveis com o AlloyDB para PostgreSQL. Verifique se os objetos do banco de dados de origem e as consultas do aplicativo não fazem referência a extensões incompatíveis. Remova as extensões e referências não compatíveis dos bancos de dados de origem antes de continuar.
A extensão pg_cron não é migrada automaticamente pelo Database Migration Service, mas é compatível com destinos do AlloyDB para PostgreSQL. Se você usar pg_cron no banco de dados de origem, reinstale e configure-o no cluster de destino do AlloyDB para PostgreSQL depois de promover a migração.
Crie uma conta de usuário de migração dedicada na instância de origem e conceda a ela os privilégios necessários:
1. Conecte-se à instância de origem usando uma conta de administrador, crie o usuário e atribua a função de replicação:
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
ALTER USER MIGRATION_USER_ACCOUNT_NAME WITH REPLICATION;
```
2. Conceda à conta de usuário de migração as permissões necessárias para o banco de dados postgres padrão e para todos os bancos de dados que você quer migrar. Execute os seguintes comandos em cada banco de dados para cada esquema, exceto o esquema de informações e os esquemas que começam com pg_:
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Instale a extensão pglogical em cada banco de dados que você quer migrar, exceto template0 e template1:
- Para o PostgreSQL versão 9.4: execute os seguintes comandos:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- Para o PostgreSQL versão 9.5 e mais recentes: execute o seguinte comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Verifique se as tabelas têm chaves primárias. Para migrações contínuas, a replicação lógica do PostgreSQL exige que as tabelas tenham chaves primárias para replicar as operações UPDATE e DELETE durante a fase de captura de dados alterados (CDC):
- As tabelas com uma chave primária replicam todas as operações INSERT, UPDATE e DELETE automaticamente.
- Para tabelas sem chaves primárias, o Database Migration Service oferece suporte à migração apenas do snapshot inicial e das instruções INSERT subsequentes durante a fase de CDC. É preciso migrar as instruções UPDATE e DELETE manualmente.
  Recomendamos que você adicione chaves primárias às tabelas que não as têm antes de iniciar a migração. Para saber como gerar uma consulta para listar tabelas em um banco de dados PostgreSQL sem chaves primárias ou como migrar manualmente as operações UPDATE e DELETE, consulte Depuração e outras ferramentas.
  
  Como alternativa, tente usar o fluxo de migração de início rápido: um cenário de migração simplificado em que é possível usar REPLICA IDENTITY para migrar tabelas sem chaves primárias. Para mais informações, consulte o guia Usar migrações de início rápido.
Origens que executam o PostgreSQL versão 9.5 e anteriores: a métrica de atraso de replicação não está disponível para instâncias de origem que executam versões do PostgreSQL anteriores à 9.6. Se você quiser usar essa métrica para acompanhar o progresso da migração, consulte Ativar o atraso de replicação.
Instale o pacote pglogical e configure os parâmetros de WAL e replicação no servidor PostgreSQL:
1. Instale o pacote pglogical no sistema operacional do host do servidor de banco de dados. Para pacotes e instruções de instalação da sua distribuição, consulte o repositório pglogical do GitHub.
2. Conecte-se à instância do PostgreSQL usando uma conta de administrador e defina os seguintes parâmetros:
  1. Defina shared_preload_libraries para incluir 'pglogical':
```
ALTER SYSTEM SET shared_preload_libraries = 'pglogical';
```
    Observação: se outras bibliotecas já estiverem carregadas na instância, adicione 'pglogical' ao final da lista separada por vírgulas. Para ver as bibliotecas atuais, execute SHOW shared_preload_libraries;.
  2. Defina wal_level como 'logical':
```
ALTER SYSTEM SET wal_level = 'logical';
```
    Consulte wal_level na documentação do PostgreSQL.
  3. Defina wal_sender_timeout como 0:
```
ALTER SYSTEM SET wal_sender_timeout = 0;
```
    O valor 0 desativa o mecanismo de tempo limite que encerra conexões de replicação inativas. Consulte wal_sender_timeout.
  4. Defina max_replication_slots como pelo menos o número de bancos de dados a serem migrados multiplicado pelo número de jobs de migração, além de reservas para sincronização de tabelas:
    Por exemplo, se houver cinco bancos de dados na instância de origem e você criar dois jobs de migração para essa origem, o número de slots de replicação precisará ser pelo menos 5 * 2 = 10, além do número de slots de replicação já usados na origem por outras tarefas. Se você planeja usar configurações ajustadas de paralelismo de despejo de dados, aumente o número de slots de replicação e verifique sua configuração ao criar o job de migração.
```
ALTER SYSTEM SET max_replication_slots = MAX_REPLICATION_SLOTS;
```
    O valor padrão desse parâmetro é 10. Consulte max_replication_slots.
  5. Defina max_wal_senders como pelo menos o valor de max_replication_slots mais o número de remetentes já usados na sua instância:
    Por exemplo, se o parâmetro max_replication_slots estiver definido como 10 e você já estiver usando dois remetentes, o número de processos de remetentes WAL em execução ao mesmo tempo será 10 + 2 = 12. Se você planeja usar configurações ajustadas de paralelismo de despejo de dados, aumente o número de remetentes e verifique sua configuração ao criar o job de migração.
```
ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;
```
    O valor padrão desse parâmetro é 10. Consulte max_wal_senders.
  6. Defina max_worker_processes como, pelo menos, o número de bancos de dados a serem migrados mais os processos de worker atuais na instância. Se você planeja usar as configurações ajustadas de paralelismo de despejo de dados, considere dois processos de worker adicionais por conexão (até um máximo de 20 workers):
```
ALTER SYSTEM SET max_worker_processes = MAX_WORKER_PROCESSES;
```
    O valor padrão desse parâmetro é 8. Consulte max_worker_processes.
  Observação: como alternativa, é possível tornar essas mudanças permanentes adicionando os parâmetros diretamente ao arquivo de configuração postgresql.conf:
```
shared_preload_libraries = 'pglogical'
wal_level = 'logical'
wal_sender_timeout = 0
max_replication_slots = MAX_REPLICATION_SLOTS
max_wal_senders = MAX_WAL_SENDERS
max_worker_processes = MAX_WORKER_PROCESSES
```
Reinicie o servidor PostgreSQL para que as alterações de configuração entrem em vigor.

Configurar uma origem do Amazon RDS para PostgreSQL

Para configurar uma instância de origem do Amazon RDS para PostgreSQL para migração contínua, conclua as seguintes etapas:

Para origens do Amazon RDS para PostgreSQL, o Database Migration Service migra todos os bancos de dados na instância de origem, exceto os bancos de dados de modelo template0, template1 e o banco de dados interno da AWS rdsadmin.
Verifique se a instância de origem inclui o banco de dados postgres padrão. Se esse banco de dados não existir, crie-o antes de configurar a migração.
Configure as regras de entrada do grupo de segurança da VPC do Amazon RDS. Permita conexões TCP de entrada na porta 5432 do intervalo de endereços IP do cluster de destino do AlloyDB para PostgreSQL, do intervalo CIDR da VPC ou da VM do bastion host de SSH reverso.
Verifique as extensões do PostgreSQL instaladas nos bancos de dados de origem. O Database Migration Service não migra extensões que não são compatíveis com o AlloyDB para PostgreSQL. Verifique se os objetos do banco de dados de origem e as consultas do aplicativo não fazem referência a extensões incompatíveis. Remova as extensões e referências não compatíveis dos bancos de dados de origem antes de continuar.
A extensão pg_cron não é migrada automaticamente pelo Database Migration Service, mas é compatível com destinos do AlloyDB para PostgreSQL. Se você usar pg_cron no banco de dados de origem, reinstale e configure-o no cluster de destino do AlloyDB para PostgreSQL depois de promover a migração.
Crie uma conta de usuário de migração dedicada na instância de origem e conceda a ela os privilégios necessários:
1. Conecte-se à instância de origem usando uma conta de administrador, crie o usuário e conceda o papel rds_replication gerenciado pela AWS:
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
```
2. Conceda à conta de usuário de migração as permissões necessárias para o banco de dados postgres padrão e para todos os bancos de dados que você quer migrar. Execute os seguintes comandos em cada banco de dados para cada esquema, exceto o esquema de informações e os esquemas que começam com pg_:
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Instale a extensão pglogical em cada banco de dados que você quer migrar, exceto template0, template1 e rdsadmin. Execute este comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Para mais detalhes sobre os requisitos, consulte Como usar extensões do PostgreSQL com o Amazon RDS para PostgreSQL na documentação da AWS.

Observação: a extensão pglogical pode registrar credenciais de login em texto simples nos registros do banco de dados na instância de origem. Esse é um comportamento conhecido da própria extensão e não está relacionado ao Database Migration Service ou ao AlloyDB para PostgreSQL.
Verifique se as tabelas têm chaves primárias. Para migrações contínuas, a replicação lógica do PostgreSQL exige que as tabelas tenham chaves primárias para replicar as operações UPDATE e DELETE durante a fase de captura de dados alterados (CDC):
- As tabelas com uma chave primária replicam todas as operações INSERT, UPDATE e DELETE automaticamente.
- Para tabelas sem chaves primárias, o Database Migration Service oferece suporte à migração apenas do snapshot inicial e das instruções INSERT subsequentes durante a fase de CDC. É preciso migrar as instruções UPDATE e DELETE manualmente.
  Recomendamos que você adicione chaves primárias às tabelas que não as têm antes de iniciar a migração. Para saber como gerar uma consulta para listar tabelas em um banco de dados PostgreSQL sem chaves primárias ou como migrar manualmente as operações UPDATE e DELETE, consulte Depuração e outras ferramentas.
  
  Como alternativa, tente usar o fluxo de migração de início rápido: um cenário de migração simplificado em que é possível usar REPLICA IDENTITY para migrar tabelas sem chaves primárias. Para mais informações, consulte o guia Usar migrações de início rápido.
Configure um grupo de parâmetros de banco de dados personalizado e anexe-o à instância:
1. Crie um grupo de parâmetros personalizado (consulte Como trabalhar com grupos de parâmetros de banco de dados na documentação da AWS) e configure os seguintes parâmetros:
  1. Defina shared_preload_libraries para incluir pglogical.
  2. Defina rds.logical_replication como 1. Esse parâmetro ativa o registro lógico de WAL no Amazon RDS. Consulte Replicação lógica do Amazon RDS para PostgreSQL.
  3. Defina wal_sender_timeout como 0. O valor 0 desativa o mecanismo de tempo limite que encerra conexões de replicação inativas.
  4. Defina max_replication_slots como pelo menos o número de bancos de dados a serem migrados multiplicado pelo número de jobs de migração, além de reservas para sincronização de tabelas:
    Por exemplo, se houver cinco bancos de dados na instância de origem e você criar dois jobs de migração para essa origem, o número de slots de replicação precisará ser pelo menos 5 * 2 = 10, além do número de slots de replicação já usados na origem por outras tarefas. Se você planeja usar configurações ajustadas de paralelismo de despejo de dados, aumente o número de slots de replicação e verifique sua configuração ao criar o job de migração.
    
    O valor padrão desse parâmetro é 10.
  5. Defina max_wal_senders como pelo menos o valor de max_replication_slots mais o número de remetentes já usados na sua instância:
    Por exemplo, se o parâmetro max_replication_slots estiver definido como 10 e você já estiver usando dois remetentes, o número de processos de remetentes WAL em execução ao mesmo tempo será 10 + 2 = 12. Se você planeja usar configurações ajustadas de paralelismo de despejo de dados, aumente o número de remetentes e verifique sua configuração ao criar o job de migração.
    
    O valor padrão desse parâmetro é 10.
  6. Defina max_worker_processes como, pelo menos, o número de bancos de dados a serem migrados mais os processos de worker atuais na instância. Se você planeja usar as configurações ajustadas de paralelismo de despejo de dados, considere dois processos de worker adicionais por conexão (até um máximo de 20 workers):
    O valor padrão desse parâmetro é 8.
2. Anexe o grupo de parâmetros à instância de banco de dados do RDS. Se você estiver criando uma nova instância, essa opção estará em Configuração adicional. Caso contrário, modifique a instância para anexar o grupo de parâmetros.
Reinicie a instância do Amazon RDS para que as alterações no grupo de parâmetros entrem em vigor.

Configurar uma origem do Amazon Aurora PostgreSQL

Para configurar um cluster de origem do Amazon Aurora PostgreSQL para migração contínua, siga estas etapas:

Para origens do Amazon Aurora para PostgreSQL, o Database Migration Service migra todos os bancos de dados no cluster de origem, exceto os bancos de dados de modelo template0, template1 e o banco de dados interno da AWS rdsadmin.
Verifique se o cluster de origem inclui o banco de dados postgres padrão. Se esse banco de dados não existir, crie-o antes de configurar a migração.
Configure as regras de entrada do grupo de segurança da VPC do cluster do Amazon Aurora. Permita conexões TCP de entrada na porta 5432 do intervalo de endereços IP do cluster de destino do AlloyDB para PostgreSQL, do intervalo CIDR da VPC ou da VM do bastion host de SSH reverso.
Verifique as extensões do PostgreSQL instaladas nos bancos de dados de origem. O Database Migration Service não migra extensões que não são compatíveis com o AlloyDB para PostgreSQL. Verifique se os objetos do banco de dados de origem e as consultas do aplicativo não fazem referência a extensões incompatíveis. Remova as extensões e referências não compatíveis dos bancos de dados de origem antes de continuar.
A extensão pg_cron não é migrada automaticamente pelo Database Migration Service, mas é compatível com destinos do AlloyDB para PostgreSQL. Se você usar pg_cron no banco de dados de origem, reinstale e configure-o no cluster de destino do AlloyDB para PostgreSQL depois de promover a migração.
Crie uma conta de usuário de migração dedicada no cluster de origem e conceda a ela os privilégios necessários:
1. Conecte-se ao cluster de origem usando uma conta de administrador, crie o usuário e conceda o papel rds_replication gerenciado pela AWS:
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
```
2. Conceda à conta de usuário de migração as permissões necessárias para o banco de dados postgres padrão e para todos os bancos de dados que você quer migrar. Execute os seguintes comandos em cada banco de dados para cada esquema, exceto o esquema de informações e os esquemas que começam com pg_:
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Instale a extensão pglogical em cada banco de dados que você quer migrar, exceto template0, template1 e rdsadmin:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Observação: a extensão pglogical pode registrar credenciais de login em texto simples nos registros do banco de dados na instância de origem. Esse é um comportamento conhecido da própria extensão e não está relacionado ao Database Migration Service ou ao AlloyDB para PostgreSQL.
Verifique se as tabelas têm chaves primárias. Para migrações contínuas, a replicação lógica do PostgreSQL exige que as tabelas tenham chaves primárias para replicar as operações UPDATE e DELETE durante a fase de captura de dados alterados (CDC):
- As tabelas com uma chave primária replicam todas as operações INSERT, UPDATE e DELETE automaticamente.
- Para tabelas sem chaves primárias, o Database Migration Service oferece suporte à migração apenas do snapshot inicial e das instruções INSERT subsequentes durante a fase de CDC. É preciso migrar as instruções UPDATE e DELETE manualmente.
  Recomendamos que você adicione chaves primárias às tabelas que não as têm antes de iniciar a migração. Para saber como gerar uma consulta para listar tabelas em um banco de dados PostgreSQL sem chaves primárias ou como migrar manualmente as operações UPDATE e DELETE, consulte Depuração e outras ferramentas.
  
  Como alternativa, tente usar o fluxo de migração de início rápido: um cenário de migração simplificado em que é possível usar REPLICA IDENTITY para migrar tabelas sem chaves primárias. Para mais informações, consulte o guia Usar migrações de início rápido.
Configure um grupo de parâmetros personalizado do cluster de banco de dados e anexe-o ao cluster:
1. Crie um grupo de parâmetros de cluster de banco de dados personalizado e configure os seguintes parâmetros:
  1. Defina shared_preload_libraries para incluir pglogical.
  2. Defina rds.logical_replication como 1. Esse parâmetro ativa a geração de registros WAL lógica.
  3. Defina wal_sender_timeout como 0. O valor 0 desativa o mecanismo de tempo limite que encerra conexões de replicação inativas.
  4. Defina max_replication_slots como pelo menos o número de bancos de dados a serem migrados multiplicado pelo número de jobs de migração, além de reservas para sincronização de tabelas:
    Por exemplo, se houver cinco bancos de dados na instância de origem e você criar dois jobs de migração para essa origem, o número de slots de replicação precisará ser pelo menos 5 * 2 = 10, além do número de slots de replicação já usados na origem por outras tarefas. Se você planeja usar configurações ajustadas de paralelismo de despejo de dados, aumente o número de slots de replicação e verifique sua configuração ao criar o job de migração.
    
    O valor padrão desse parâmetro é 10.
  5. Defina max_wal_senders como pelo menos o valor de max_replication_slots mais o número de remetentes já usados na sua instância:
    Por exemplo, se o parâmetro max_replication_slots estiver definido como 10 e você já estiver usando dois remetentes, o número de processos de remetentes WAL em execução ao mesmo tempo será 10 + 2 = 12. Se você planeja usar configurações ajustadas de paralelismo de despejo de dados, aumente o número de remetentes e verifique sua configuração ao criar o job de migração.
    
    O valor padrão desse parâmetro é 10.
  6. Defina max_worker_processes como, pelo menos, o número de bancos de dados a serem migrados mais os processos de worker atuais na instância. Se você planeja usar as configurações ajustadas de paralelismo de despejo de dados, considere dois processos de worker adicionais por conexão (até um máximo de 20 workers):
    O valor padrão desse parâmetro é 8.
2. Anexe o grupo de parâmetros do cluster de banco de dados ao cluster de banco de dados do Aurora.
Reinicie o cluster de banco de dados do Amazon Aurora para que as alterações no grupo de parâmetros entrem em vigor.

Configurar uma origem do Cloud SQL para PostgreSQL

Para configurar uma instância de origem do Cloud SQL para PostgreSQL para migração contínua, siga estas etapas:

Para origens do Cloud SQL para PostgreSQL, o Database Migration Service migra todos os bancos de dados na instância de origem, exceto os bancos de dados de modelo template0 e template1.
Verifique se a instância de origem inclui o banco de dados postgres padrão. Se esse banco de dados não existir, crie-o antes de configurar a migração.
Se você migrar de uma instância de origem do Cloud SQL configurada com um endereço IP privado para um cluster de destino do AlloyDB para PostgreSQL que usa um intervalo de endereços IP não RFC 1918, adicione o intervalo não RFC 1918 às redes autorizadas da instância de origem. Para mais informações, consulte Configurar redes autorizadas.
Verifique as extensões do PostgreSQL instaladas nos bancos de dados de origem. O Database Migration Service não migra extensões que não são compatíveis com o AlloyDB para PostgreSQL. Verifique se os objetos do banco de dados de origem e as consultas do aplicativo não fazem referência a extensões incompatíveis. Remova as extensões e referências não compatíveis dos bancos de dados de origem antes de continuar.
A extensão pg_cron não é migrada automaticamente pelo Database Migration Service, mas é compatível com destinos do AlloyDB para PostgreSQL. Se você usar pg_cron no banco de dados de origem, reinstale e configure-o no cluster de destino do AlloyDB para PostgreSQL depois de promover a migração.
Crie uma conta de usuário de migração dedicada na instância de origem e conceda a ela os privilégios necessários:
1. Siga as etapas na página Criar um usuário na documentação do Cloud SQL para criar a conta de usuário.
2. Conceda o papel cloudsqlsuperuser à conta de usuário de migração:
```
GRANT cloudsqlsuperuser TO "MIGRATION_USER_ACCOUNT_NAME";
```
3. Conceda à conta de usuário de migração as permissões necessárias para o banco de dados postgres padrão e para todos os bancos de dados que você quer migrar. Execute os seguintes comandos em cada banco de dados para cada esquema, exceto o esquema de informações e os esquemas que começam com pg_:
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
Instale a extensão pglogical em cada banco de dados que você quer migrar, exceto template0 e template1. Execute este comando:
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
Verifique se as tabelas têm chaves primárias. Para migrações contínuas, a replicação lógica do PostgreSQL exige que as tabelas tenham chaves primárias para replicar as operações UPDATE e DELETE durante a fase de captura de dados alterados (CDC):
- As tabelas com uma chave primária replicam todas as operações INSERT, UPDATE e DELETE automaticamente.
- Para tabelas sem chaves primárias, o Database Migration Service migra o snapshot inicial e as instruções INSERT subsequentes durante a fase de CDC. É preciso migrar as instruções UPDATE e DELETE manualmente.
  Recomendamos que você adicione chaves primárias às tabelas que não as têm antes de iniciar a migração. Para saber como gerar uma consulta para listar tabelas em um banco de dados PostgreSQL sem chaves primárias ou como migrar manualmente as operações UPDATE e DELETE, consulte Depuração e outras ferramentas.
  
  Como alternativa, tente usar o fluxo de migração de início rápido: um cenário de migração simplificado em que é possível usar REPLICA IDENTITY para migrar tabelas sem chaves primárias. Para mais informações, consulte o guia Usar migrações de início rápido.
Configure as seguintes flags de banco de dados na instância de origem do Cloud SQL:
1. Defina cloudsql.logical_decoding como on.
2. Defina cloudsql.enable_pglogical como on.
3. Defina wal_sender_timeout como 0. O valor 0 desativa o mecanismo de tempo limite que encerra conexões de replicação inativas.
4. Defina max_replication_slots como pelo menos o número de bancos de dados a serem migrados multiplicado pelo número de jobs de migração, além de reservas para sincronização de tabelas.
  Por exemplo, se houver cinco bancos de dados na instância de origem e você criar dois jobs de migração para essa origem, o número de slots de replicação precisará ser pelo menos 5 * 2 = 10, além do número de slots de replicação já usados na origem por outras tarefas. Se você planeja usar as configurações ajustadas de paralelismo de despejo de dados, aumente o número de slots de replicação e verifique sua configuração ao criar o job de migração.
  
  O valor padrão dessa flag é 10.
5. Defina max_wal_senders como pelo menos o valor de max_replication_slots mais o número de remetentes já usados na sua instância.
  Por exemplo, se a flag max_replication_slots estiver definida como 10 e você já estiver usando dois remetentes, o número de processos de remetentes WAL em execução ao mesmo tempo será 10 + 2 = 12. Se você planeja usar as configurações ajustadas de paralelismo de despejo de dados, aumente o número de remetentes e verifique sua configuração ao criar o job de migração.
  
  O valor padrão dessa flag é 10.
6. Defina max_worker_processes como, pelo menos, o número de bancos de dados a serem migrados mais os processos de worker atuais na instância. Se você planeja usar configurações ajustadas de paralelismo de despejo de dados, considere dois processos de worker adicionais por conexão (até um máximo de 20 workers).
  O valor padrão dessa flag é 8.
Para mais informações sobre como modificar flags, consulte Configurar flags de banco de dados na documentação do Cloud SQL.
Reinicie a instância de origem do Cloud SQL para que as alterações na flag de banco de dados entrem em vigor.

A seguir

Para ver tutoriais completos de migração, consulte Começar a usar as migrações do AlloyDB para PostgreSQL.
Para planejar a conectividade de rede entre as instâncias de origem e de destino, consulte Considerações sobre rede.