Configure sua fonte

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Visão geral

O Database Migration Service oferece suporte a migrações contínuas de bancos de dados de origem para bancos de dados de destino do Cloud SQL.

Os bancos de dados de origem suportados para PostgreSQL incluem:

• Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16, 17.
• Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14.6+, 15.2+, 16, 17.
• PostgreSQL autogerenciado (no local ou em qualquer VM na nuvem que você controle totalmente) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17.
• Cloud SQL para PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17.
• Banco de dados Microsoft Azure para servidor flexível PostgreSQL: 11+

A configuração da sua origem requer a configuração da instância de origem e dos bancos de dados de origem subjacentes.

Configure sua instância de origem

Para configurar sua instância de origem, siga estas etapas:

1. Para origens do Cloud SQL: se você estiver migrando de uma instância do Cloud SQL que usa uma conexão IP privada para uma instância do Cloud SQL que usa um intervalo de endereços IP não RFC 1918 , adicione o intervalo não RFC 1918 à configuração de rede da sua instância de origem do Cloud SQL. Consulte Configurar redes autorizadas na documentação do Cloud SQL.
2. Sua instância de origem deve incluir o banco de dados postgres . Se você não possui esse banco de dados, crie-o.

3. Instale o pacote pglogical na instância de origem e certifique-se de que ele esteja incluído na variável shared_preload_libraries . Consulte Instalar o pacote pglogical na instância de origem do seu ambiente.

4. Verifique as extensões na sua instância de origem. 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 de migração tranquilo, verifique se seus objetos ou aplicativos não fazem referência a extensões não suportadas. Recomendamos remover essas extensões e referências do seu banco de dados de origem antes de continuar.

5. Para fontes que usam a extensão pg_cron : 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 após a conclusão da migração.

Configure seus bancos de dados de origem

O Database Migration Service migra todos os bancos de dados em sua instância de origem, exceto os seguintes bancos de dados:

• Para fontes PostgreSQL locais: bancos de dados de modelo template0 e template1
• Para fontes do Amazon RDS: template0 , template1 e rdsadmin
• Para origens do Cloud SQL: bancos de dados de modelo template0 e template1
• Para fontes do Microsoft Azure: azure_maintenance , azure_sys , template0 , template1

Faça o seguinte em cada banco de dados da instância de origem que não foi mencionado acima:

1. Somente para fontes do PostgreSQL versão 9.4 , instale as seguintes extensões pglogical em cada banco de dados em sua instância de origem:

   • CREATE EXTENSION IF NOT EXISTS pglogical;
   • CREATE EXTENSION IF NOT EXISTS pglogical_origin;

2. Para todas as outras versões , instale apenas a extensão pglogical em cada banco de dados na sua instância de origem: CREATE EXTENSION IF NOT EXISTS pglogical .

3. Para tabelas que não possuem chaves primárias, o Database Migration Service oferece suporte à migração do snapshot inicial e das instruções INSERT durante a fase CDC . Você deve migrar as instruções UPDATE e DELETE manualmente.

4. O USER que você está usando para se conectar à instância de origem (que será configurado como o usuário na página Perfis de conexão ) deve ter determinados privilégios em cada um dos bancos de dados migrados, bem como no banco de dados postgres padrão. Você pode criar um novo usuário ou reutilizar um existente. Para definir esses privilégios, conecte-se à instância e execute os seguintes comandos:

   1. GRANT USAGE on SCHEMA SCHEMA to USER em todos os esquemas (exceto o esquema de informações e os esquemas que começam com "pg_") em cada banco de dados a ser migrado.
   2. GRANT USAGE on SCHEMA pglogical to PUBLIC; em cada banco de dados para migrar.
   3. GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER em todos os bancos de dados para obter informações de replicação dos bancos de dados de origem.
   4. GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER em todos os esquemas (exceto o esquema de informações e os esquemas que começam com "pg_") em cada banco de dados a ser migrado.
   5. GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER em todos os esquemas (exceto o esquema de informações e os esquemas que começam com "pg_") em cada banco de dados a ser migrado.
   6. Se sua origem for Amazon RDS , execute o seguinte comando:
      1. GRANT rds_replication to USER
   7. Se sua fonte não for o Amazon RDS , execute o seguinte comando:
      1. ALTER USER USER with REPLICATION

Instale o pacote pglogical na instância de origem

Esta seção descreve como configurar o pacote pglogical e os parâmetros aplicáveis, dependendo da sua instância de origem.

PostgreSQL local ou autogerenciado

1. Instale o pacote pglogical no servidor.
2. Conecte-se à instância e defina os seguintes parâmetros, conforme necessário:

   • shared_preload_libraries deve incluir pglogical .

     Para definir este parâmetro, execute ALTER SYSTEM SET shared_preload_libraries = 'pglogical, [any other libraries in your instance] '; comando.

   • Defina wal_level como logical .

     Para definir este parâmetro, execute ALTER SYSTEM SET wal_level = 'logical'; comando.

   • Defina wal_sender_timeout como 0 .

     Para definir este parâmetro, execute ALTER SYSTEM SET wal_sender_timeout = 0; comando, onde 0 desativa o mecanismo de tempo limite usado para encerrar conexões de replicação inativas.

   • max_replication_slots define o número máximo de slots de replicação que a instância de origem pode suportar. Deve ser definido pelo menos para o número de assinaturas esperadas para conexão, além de algumas reservas para sincronização de tabelas.

     O Database Migration Service requer um slot para cada banco de dados migrado (que são todos os bancos de dados na instância de origem).

     Por exemplo, se houver cinco bancos de dados na instância de origem e se houver dois trabalhos de migração criados para a origem, o número de slots de replicação deverá ser pelo menos 5 * 2 = 10, mais o número de slots de replicação já usados ​​por você. Se você planeja usar configurações ajustadas de paralelismo de dump de dados, aumente o número de slots de replicação e verifique sua configuração executando o teste de tarefa de migração ao criar a tarefa de migração.

     Para definir este parâmetro, execute ALTER SYSTEM SET max_replication_slots = # ; comando, onde # representa o número máximo de slots de replicação.

   • max_wal_senders deve ser definido pelo menos como max_replication_slots , mais o número de remetentes já usados ​​em sua instância.

     Por exemplo, se o parâmetro max_replication_slots estiver definido como 10 e você já estiver usando 2 remetentes, o número de processos de remetente WAL em execução ao mesmo tempo seria 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 executando o teste de trabalho de migração ao criar o trabalho de migração.

     Para definir este parâmetro, execute ALTER SYSTEM SET max_wal_senders = # ; comando, onde # representa o número de processos do remetente WAL em execução simultaneamente.

   • max_worker_processes deve ser definido como pelo menos o mesmo número de bancos de dados que o Database Migration Service irá migrar (que é todos os bancos de dados na instância de origem), mais o número de max_worker_processes já usados ​​em sua instância.

     Se você planeja usar configurações ajustadas de paralelismo de dump de dados, aumente o número de processos de trabalho e verifique sua configuração executando o teste de tarefa de migração ao criar a tarefa de migração.

     Para definir este parâmetro, execute ALTER SYSTEM SET max_worker_processes = # ; comando, onde # representa o número de bancos de dados que serão migrados.

3. Para aplicar as alterações de configuração, reinicie a instância de origem .

Banco de dados Microsoft Azure para PostgreSQL

Para configurar seu banco de dados do Microsoft Azure para origem PostgreSQL, siga estas etapas:

1. Instale o pacote pglogical em seu servidor.

2. Somente para fontes do PostgreSQL versão 9.4 , instale as seguintes extensões pglogical em cada banco de dados em sua instância de origem:

   • CREATE EXTENSION IF NOT EXISTS pglogical;
   • CREATE EXTENSION IF NOT EXISTS pglogical_origin;

3. Para todas as outras versões , instale a extensão pglogical em cada banco de dados em sua instância de origem: CREATE EXTENSION IF NOT EXISTS pglogical .

4. Configure os parâmetros de servidor necessários na sua origem usando o portal do Microsoft Azure. Para obter mais informações, consulte Configurar parâmetros de servidor no Banco de Dados do Azure para PostgreSQL e Parâmetros de servidor no Banco de Dados do Azure para PostgreSQL na documentação da Microsoft.

   Configure os seguintes parâmetros:

   • Defina shared_preload_libraries para incluir pglogical .
   • Defina azure.extensions para incluir pglogical .
   • Defina wal_level como logical .

   • Defina max_replication_slots como pelo menos o número de assinaturas que se espera conectar, além de algumas reservas para sincronização de tabelas.

     O parâmetro max_replication_slots define o número máximo de slots de replicação que a instância de origem pode suportar.

     O Database Migration Service requer um slot para cada banco de dados migrado (que são todos os bancos de dados na instância de origem).

     Por exemplo, se houver cinco bancos de dados na instância de origem e se houver dois trabalhos de migração criados para a origem, o número de slots de replicação deverá ser pelo menos 5 * 2 = 10, mais o número de slots de replicação já usados ​​por você. Se você planeja usar configurações ajustadas de paralelismo de dump de dados, aumente o número de slots de replicação e verifique sua configuração executando o teste de tarefa de migração ao criar a tarefa de migração.

   • Defina max_wal_senders como pelo menos igual a max_replication_slots , mais o número de remetentes já usados ​​em sua instância.

     Por exemplo, se o parâmetro max_replication_slots estiver definido como 10 e você já estiver usando 2 remetentes, o número de processos de remetente WAL em execução ao mesmo tempo seria 10 + 2 = 12.

     Se você planeja usar configurações ajustadas de paralelismo de dump de dados, aumente o número de remetentes e verifique sua configuração executando o teste de tarefa de migração ao criar a tarefa de migração.

   • Defina max_worker_processes como pelo menos o mesmo número de bancos de dados que o Database Migration Service irá migrar (que é todos os bancos de dados na instância de origem), mais o número de max_worker_processes já usados ​​em sua instância.

     Se você planeja usar configurações ajustadas de paralelismo de dump de dados, aumente o número de processos de trabalho e verifique sua configuração executando o teste de tarefa de migração ao criar a tarefa de migração.

5. Verifique o valor da sua configuração require_secure_transport .

   Por padrão, os bancos de dados do Microsoft Azure exigem criptografia SSL/TLS para todas as conexões de entrada. Dependendo do valor require_secure_transport , use uma das seguintes configurações de criptografia ao criar o perfil de conexão de origem :

   • Se require_secure_transport estiver on , selecione Basic , TLS ou mTLS .
   • Se require_secure_transport estiver off , selecione Nenhum .
6. Para aplicar as alterações de configuração, reinicie a instância de origem .

PostgreSQL do Amazon RDS

1. Instale a extensão pglogical no seu banco de dados de origem.

   Para obter mais informações, consulte Usar extensões do PostgreSQL com o Amazon RDS para PostgreSQL na documentação do Amazon RDS.

2. Configure a instância de origem usando grupos de parâmetros .

   1. Crie um novo grupo de parâmetros . No grupo de parâmetros:
   • Certifique-se de que o parâmetro shared_preload_libraries inclua pglogical .
   • Defina o parâmetro rds.logical_replication como 1. Isso ativará os logs WAL no nível 'lógico'.
   • Defina o parâmetro wal_sender_timeout como 0. Isso desativará o mecanismo de tempo limite usado para encerrar conexões de replicação inativas.

   • Configure o parâmetro max_replication_slots . Este parâmetro define o número máximo de slots de replicação que a instância de origem pode suportar. Deve ser definido pelo menos para o número de assinaturas esperadas para conexão, além de algumas reservas para sincronização de tabelas.

     O Database Migration Service requer um slot para cada banco de dados migrado (que são todos os bancos de dados na instância de origem).

     Por exemplo, se houver 5 bancos de dados na instância de origem e se houver 2 trabalhos de migração criados para a origem, o número de slots de replicação deverá ser pelo menos 5 * 2 = 10, mais o número de slots de replicação já usados ​​por você. Se você planeja usar configurações ajustadas de paralelismo de dump de dados, aumente o número de slots de replicação e verifique sua configuração executando o teste de tarefa de migração ao criar a tarefa de migração.

     O valor padrão para esse parâmetro é 10 .

   • Defina o parâmetro max_wal_senders como pelo menos igual a max_replication_slots , mais o número de remetentes já usados ​​em sua instância.

     Por exemplo, se o parâmetro max_replication_slots estiver definido como 10 e você já estiver usando 2 remetentes, o número de processos de remetente WAL em execução ao mesmo tempo seria 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 executando o teste de trabalho de migração ao criar o trabalho de migração.

     O valor padrão para esse parâmetro é 10 .

   • Defina o parâmetro de origem max_worker_processes para pelo menos o mesmo número de bancos de dados que o Database Migration Service irá migrar (que é todos os bancos de dados na instância de origem), mais o número de max_worker_processes já usados ​​em sua instância. Se você planeja usar configurações ajustadas de paralelismo de dump de dados, aumente o número de processos de trabalho e verifique sua configuração executando o teste de tarefa de migração ao criar a tarefa de migração.

     O valor padrão para esse parâmetro é 8 .

   2. Anexe o grupo de parâmetros à instância. Se estiver criando uma nova instância, você poderá encontrar essa opção em Configuração Adicional .

      Caso contrário, modifique a instância para anexar o grupo de parâmetros.

3. Para aplicar as alterações de configuração, reinicie a instância de origem .

Cloud SQL para PostgreSQL

Habilite a replicação lógica e a decodificação para o banco de dados de origem configurando os seguintes sinalizadores:

1. Defina os sinalizadores cloudsql.logical_decoding e cloudsql.enable_pglogical como on .

2. Configure o sinalizador max_replication_slots . Esse sinalizador define o número máximo de slots de replicação que a instância de origem pode suportar. Deve ser definido pelo menos para o número de assinaturas esperadas para conexão, além de algumas reservas para sincronização de tabelas.

   O Database Migration Service requer um slot para cada banco de dados migrado (que são todos os bancos de dados na instância de origem).

   Por exemplo, se houver 5 bancos de dados na instância de origem e se houver 2 trabalhos de migração criados para a origem, o número de slots de replicação deverá ser pelo menos 5 * 2 = 10, mais o número de slots de replicação já usados ​​por você. Se você planeja usar configurações ajustadas de paralelismo de dump de dados, aumente o número de slots de replicação e verifique sua configuração executando o teste de tarefa de migração ao criar a tarefa de migração.

   O valor padrão para esse sinalizador é 10 .

3. Defina o sinalizador max_wal_senders como pelo menos igual a max_replication_slots , mais o número de remetentes já usados ​​em sua instância.

   Por exemplo, se o sinalizador max_replication_slots estiver definido como 10 e você já estiver usando 2 remetentes, o número de processos de remetente WAL em execução ao mesmo tempo seria 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 executando o teste de trabalho de migração ao criar o trabalho de migração.

   O valor padrão para esse sinalizador é 10 .

4. Defina o sinalizador de origem max_worker_processes para pelo menos o mesmo número de bancos de dados que o Database Migration Service irá migrar (que é todos os bancos de dados na instância de origem), mais o número de max_worker_processes já usados ​​em sua instância. Se você planeja usar configurações ajustadas de paralelismo de dump de dados, aumente o número de processos de trabalho e verifique sua configuração executando o teste de tarefa de migração ao criar a tarefa de migração.

   O valor padrão para esse sinalizador é 8 .

5. Defina o parâmetro 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.

6. Reinicie sua instância de origem para que as alterações de configuração feitas nos sinalizadores possam entrar em vigor.

Habilitar monitoramento de atraso de replicação para versões do PostgreSQL anteriores à 9.6

Se você estiver migrando de uma versão do PostgreSQL anterior à 9.6, a métrica de atraso de replicação não estará disponível por padrão. As alternativas a seguir permitem rastrear essa métrica para garantir um tempo de inatividade mínimo ao promover o banco de dados:

• Opção 1 : Habilite o Database Migration Service para rastrear o atraso de replicação concedendo acesso a uma consulta específica. Usando um usuário com privilégio SUPERUSER , faça o seguinte:

  1. Defina a função a seguir para permitir que o Database Migration Service consulte o atraso de replicação.

     CREATE OR REPLACE FUNCTION pg_stat_replication_user()
     RETURNS TABLE (
     pid               integer                  ,
     usesysid          oid                      ,
     username          name                    ,
     application_name  text                     ,
     client_addr       inet                     ,
     client_hostname   text                     ,
     client_port       integer                  ,
     backend_start     timestamp with time zone ,
     backend_xmin      xid                      ,
     state             text                     ,
     sent_location     pg_lsn                   ,
     write_location    pg_lsn                   ,
     flush_location    pg_lsn                   ,
     replay_location   pg_lsn                   ,
     sync_priority     integer                  ,
     sync_state        text
     )
     LANGUAGE SQL
     SECURITY DEFINER
     AS $$
      SELECT *
      FROM pg_catalog.pg_stat_replication;
     $$;
     

  2. Conceda a permissão EXECUTE ao USER executando os seguintes comandos:

     1. REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
     2. GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};

• Opção 2 : conceda o privilégio SUPERUSER diretamente ao USER usado para se conectar à instância de origem. Isso permitirá que o Database Migration Service leia diretamente o atraso de replicação.

• Opção 3 : rastreie o atraso de replicação de forma independente usando a seguinte consulta:

      SELECT current_timestamp, application_name,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.sent_location) AS sent_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.write_location) AS write_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.flush_location) AS flush_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.replay_location) AS replay_location_lag
      FROM pg_stat_replication
      WHERE application_name like 'cloudsql%';
    

  Nesta opção, o Database Migration Service não refletirá a métrica de atraso de replicação nos gráficos ou nas respostas da API.