Configurar sua fonte

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

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 compatíveis com o PostgreSQL incluem o seguinte:

• Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16 e 17.
• Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14.6+, 15.2+, 16 e 17.
• PostgreSQL 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16 e 17 autogerenciado (no local ou em qualquer VM de nuvem totalmente controlada por você).
• Cloud SQL para PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16 e 17.
• Microsoft Azure Database para PostgreSQL Flexible Server: 11 ou posterior

Para configurar a origem, é preciso ajustar a instância de origem e os bancos de dados de origem básicos.

Configurar a instância de origem

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

1. Para fontes do Cloud SQL:se você estiver migrando de uma instância do Cloud SQL que usa uma conexão de IP particular 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 instância de origem do Cloud SQL. Consulte Configurar redes autorizadas na documentação do Cloud SQL.
2. A instância de origem precisa incluir o banco de dados postgres. Crie esse banco de dados, caso ele não exista.

3. Instale o pacote pglogical na instância de origem e verifique se ele está incluído na variável shared_preload_libraries. Consulte Instalar o pacote pglogical na instância de origem para seu ambiente.

4. Verifique as extensões na 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 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.

5. Para fontes que usam a extensão pg_cron: 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.

Configurar os bancos de dados de origem

O Database Migration Service migra todos os bancos de dados na instância de origem que não sejam os seguintes:

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

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

1. Somente para fontes do PostgreSQL versão 9.4, instale as seguintes extensões pglogical em cada banco de dados na 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 instância de origem: CREATE EXTENSION IF NOT EXISTS pglogical.

3. 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 CDC. Migre as instruções UPDATE e DELETE manualmente.

   Consulte Depuração e outras ferramentas para saber como gerar uma consulta para listar tabelas em um banco de dados PostgreSQL sem chaves primárias. Para cada tabela de banco de dados que você encontrar e que não tem uma chave primária e que não faz parte dos bancos de dados que não foram migrados, altere a tabela para que ela tenha uma chave primária ou siga este processo. Para tabelas que não têm chaves primárias, somente o snapshot inicial e as instruções INSERT são migrados.

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, precisa ter determinados privilégios em cada um dos bancos de dados migrados, bem como no banco de dados postgres padrão. É possível criar um novo usuário ou reutilizar um já 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 (além do esquema de informações e 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 a ser migrado.
   3. GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER em todos os bancos de dados para receber informações de replicação de bancos de dados de origem.
   4. GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER em todos os esquemas (além do esquema de informações e 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 (além do esquema de informações e esquemas que começam com "pg_") em cada banco de dados a ser migrado.
   6. Se sua origem for o Amazon RDS, execute o seguinte comando:
      1. GRANT rds_replication to USER
   7. Se sua origem não for o Amazon RDS, execute o seguinte comando:
      1. Papel ALTER USER USER with REPLICATION

Instale o pacote pglogical na instância de origem

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

Observação: é possível receber os valores corretos para esses parâmetros executando um teste de job de migração ao criar o job de migração. Durante esse teste, Database Migration Service pode verificar suas configurações e sugerir os valores corretos.

PostgreSQL autogerenciado ou local

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

   • shared_preload_libraries precisa incluir pglogical.

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

     Para receber as bibliotecas atuais da sua instância, execute o comando show shared_preload_libraries.

   • Defina wal_level como logical.

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

   • Defina wal_sender_timeout como 0.

     Para definir esse parâmetro, execute o comando ALTER SYSTEM SET wal_sender_timeout = 0;, em que 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 oferecer suporte. Ele precisa ser definido como pelo menos o número de assinaturas que precisam ser conectadas, mais algumas reservas para sincronização de tabelas.

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

     Por exemplo, se houver cinco bancos de dados na instância de origem e dois jobs de migração forem criados para a 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 por você. 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 executando o teste de job de migração ao criar o job.

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

   • max_wal_senders deve ser definido como pelo menos o mesmo que 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 executando o teste do job de migração ao criar o job.

     Para definir esse parâmetro, execute o comando ALTER SYSTEM SET max_wal_senders = #;, em que # representa o número de processos de remetentes WAL em execução simultânea.

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

     Se você planeja usar configurações ajustadas de paralelismo de despejo de dados, aumente o número de processos de worker e verifique sua configuração executando o teste do job de migração ao criar o job.

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

   Os parâmetros que você está definindo nesta etapa se aplicam a um servidor de banco de dados do PostgreSQL em execução. Você também pode tornar essas mudanças persistentes adicionando as seguintes linhas de código ao arquivo postgresql.conf:

   • shared_preload_libraries = 'pglogical';
   • wal_level = 'logical';
   • wal_sender_timeout = 0;
   • max_replication_slots = #;
   • max_wal_senders = #;
   • max_worker_processes = #;
3. Para aplicar as mudanças de configuração, reinicie a instância de origem.

Microsoft Azure Database para PostgreSQL

Para configurar sua origem do Microsoft Azure Database para PostgreSQL, siga estas etapas:

1. Instale o pacote pglogical no seu servidor.

2. Somente para fontes do PostgreSQL versão 9.4, instale as seguintes extensões pglogical em cada banco de dados na 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 na instância de origem: CREATE EXTENSION IF NOT EXISTS pglogical.

4. Configure os parâmetros de servidor necessários na origem usando o portal do Microsoft Azure. Para mais informações, consulte Configurar parâmetros de servidor no Azure Database for PostgreSQL e Parâmetros de servidor no Azure Database for 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 precisam ser conectadas, mais 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 oferecer suporte.

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

     Por exemplo, se houver cinco bancos de dados na instância de origem e dois jobs de migração forem criados para a 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 por você. 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 executando o teste de job de migração ao criar o job.

   • Defina max_wal_senders como pelo menos 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 executando o teste do job de migração ao criar o job.

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

     Se você planeja usar configurações ajustadas de paralelismo de despejo de dados, aumente o número de processos de worker e verifique sua configuração executando o teste do job de migração ao criar o job.

5. Verifique o valor da 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 de 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 definido como on, selecione Básico, TLS ou mTLS.
   • Se require_secure_transport estiver definido como off, selecione Nenhum.
6. Para aplicar as mudanças de configuração, reinicie a instância de origem.

Amazon RDS PostgreSQL

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

   Para mais informações, consulte Como 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 grupo de parâmetros. No grupo de parâmetros:
   • Verifique se o parâmetro shared_preload_libraries inclui pglogical.
   • Defina o parâmetro rds.logical_replication como 1. Isso vai ativar os registros WAL no nível "logical".
   • Defina o parâmetro wal_sender_timeout como 0. Isso desativa o mecanismo de tempo limite usado para encerrar conexões de replicação inativas.

   • Defina o parâmetro max_replication_slots. Esse parâmetro define o número máximo de slots de replicação que a instância de origem pode aceitar. Ele precisa ser definido como pelo menos o número de assinaturas que precisam ser conectadas, mais algumas reservas para sincronização de tabelas.

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

     Por exemplo, se houver cinco bancos de dados na instância de origem e dois jobs de migração forem criados para a 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 por você. 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 executando o teste do job de migração ao criar o job.

     O valor padrão desse parâmetro é 10.

   • Defina o parâmetro max_wal_senders como pelo menos max_replication_slots, além do 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 executando o teste do job de migração ao criar o job.

     O valor padrão desse parâmetro é 10.

   • Defina o parâmetro de origem max_worker_processes como pelo menos o mesmo número de bancos de dados que o Database Migration Service vai migrar (todos os bancos de dados na instância de origem), mais o número de max_worker_processes já usados na sua instância. Se você planeja usar configurações ajustadas de paralelismo de despejo de dados, aumente o número de processos de worker e verifique sua configuração executando o teste do job de migração ao criar o job.

     O valor padrão desse parâmetro é 8.

   2. Anexe o grupo de parâmetros à instância. 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.

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

Observação: a extensão pglogical pode registrar credenciais em texto simples na instância de origem. Esse comportamento é causado pela extensão e não está relacionado ao Database Migration Service nem ao Cloud SQL.

Cloud SQL para PostgreSQL

Ative a replicação lógica e a decodificação do banco de dados de origem configurando as seguintes flags:

Todas as configurações nesta seção são configuradas usando flags no Cloud SQL. Para ativar flags no Cloud SQL, consulte Configurar flags de banco de dados.

1. Defina as flags cloudsql.logical_decoding e cloudsql.enable_pglogical como on.

2. Defina a flag max_replication_slots. Essa flag define o número máximo de slots de replicação que a instância de origem pode oferecer suporte. Ele precisa ser definido como pelo menos o número de assinaturas que precisam ser conectadas, mais algumas reservas para sincronização de tabelas.

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

   Por exemplo, se houver cinco bancos de dados na instância de origem e dois jobs de migração forem criados para a 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 por você. 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 executando o teste de job de migração ao criar o job.

   O valor padrão dessa flag é 10.

3. Defina a flag max_wal_senders como pelo menos max_replication_slots, além do 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 configurações ajustadas de paralelismo de despejo de dados, aumente o número de remetentes e verifique sua configuração executando o teste do job de migração ao criar o job.

   O valor padrão dessa flag é 10.

4. Defina a flag de origem max_worker_processes como pelo menos o mesmo número de bancos de dados que o Database Migration Service vai migrar (todos os bancos de dados na instância de origem), mais o número de max_worker_processes já usados na sua instância. Se você planeja usar configurações ajustadas de paralelismo de despejo de dados, aumente o número de processos de worker e verifique sua configuração executando o teste do job de migração ao criar o job.

   O valor padrão dessa flag é 8.

5. Defina o parâmetro wal_sender_timeout como 0. O valor 0 desativa o mecanismo de tempo limite que encerra conexões de replicação inativas.

6. Reinicie a instância de origem para que as mudanças de configuração feitas nas flags entrem em vigor.

Ativar o 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 da 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: conceda ao Database Migration Service uma consulta específica para que ele possa rastrear o atraso de replicação. Usando um usuário com o 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 permite que o Database Migration Service leia o atraso de replicação diretamente.

• Opção 3: acompanhe o atraso da replicação de maneira independente usando a seguinte consulta:

  Para versões do PostgreSQL anteriores à 10, execute este comando como um superuser.

      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 reflete a métrica de atraso da replicação nos gráficos ou nas respostas da API.