Configure a sua origem

MySQL   |  PostgreSQL   |  PostgreSQL para AlloyDB

Vista geral

O Database Migration Service suporta migrações contínuas de bases de dados de origem para bases de dados de destino do AlloyDB.

As bases de dados de origem compatíveis com o 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, 15, 16, 17
• PostgreSQL autogerido (no local ou em qualquer VM na nuvem que controla totalmente) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16 e 17
• Cloud SQL 9.6, 10, 11, 12, 13, 14, 15, 16 e 17

A configuração da origem requer a configuração da instância de origem e das bases de dados de origem subjacentes.

Configure a instância de origem

Para configurar a instância de origem, siga os passos abaixo:

1. A instância de origem tem de incluir a base de dados postgres. Se não tiver esta base de dados, crie-a.
2. Instale o pacote pglogical na instância de origem e certifique-se de que está incluído na variável shared_preload_libraries.
   1. Consulte o artigo Instale o pacote pglogical na instância de origem para o seu ambiente.

Configure as bases de dados de origem

O Database Migration Service migra todas as bases de dados na sua instância de origem, exceto as seguintes bases de dados:

• Para origens no local: bases de dados de modelos template0 e template1
• Para origens do Amazon RDS: template0, template1 e rdsadmin
• Para origens do Cloud SQL: bases de dados de modelos template0 e template1

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

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

3. Para tabelas que não têm chaves primárias, o Database Migration Service suporta a migração da imagem instantânea inicial e das declarações INSERT durante a fase de CDC. Deve migrar as declarações UPDATE e DELETE manualmente.

   Consulte Resolução de problemas e outras ferramentas para saber como gerar uma consulta para listar tabelas numa base de dados PostgreSQL sem chaves primárias. Para cada tabela da base de dados que encontrar que não tenha uma chave principal e que não faça parte das bases de dados que não foram migradas, deve alterar a tabela para que tenha uma chave principal ou seguir este processo. Para tabelas que não têm chaves principais, apenas a imagem instantânea inicial e as declarações INSERT são migradas.

4. O USER que está a usar para estabelecer ligação à instância de origem (que vai ser configurado como o utilizador na página Perfis de ligação) tem de ter determinados privilégios em cada uma das bases de dados migradas, bem como na base de dados postgres predefinida. Pode criar um novo utilizador ou reutilizar um existente. Para definir estes privilégios, ligue-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 por "pg_") em cada base de dados a migrar.
   2. GRANT USAGE on SCHEMA pglogical to PUBLIC; em cada base de dados a migrar.
   3. GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER em todas as bases de dados para obter informações de replicação das bases 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 por "pg_") em cada base de dados a migrar.
   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 por "pg_") em cada base de dados a migrar.
   6. Se a sua origem for o Amazon RDS, execute o seguinte comando:
      1. GRANT rds_replication to USER
   7. Se a sua origem não for o Amazon RDS, execute o seguinte comando:
      1. ALTER USER USER with REPLICATION função

Instale o pacote pglogical na instância de origem

Esta secção descreve como configurar o pacote pglogical, incluindo a configuração dos parâmetros max_replication_slots, max_wal_senders e max_worker_processes. Também pode obter os valores corretos para estes parâmetros executando um teste de tarefa de migração quando criar a tarefa de migração. Durante este teste, o Database Migration Service pode validar as suas definições e sugerir os valores corretos.

PostgreSQL nas instalações ou autogerido

1. Instale o pacote pglogical no servidor.
2. Estabeleça ligação à instância e defina os seguintes parâmetros, conforme necessário:

   • shared_preload_libraries tem de incluir pglogical.

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

     Para obter as bibliotecas existentes para a sua instância, execute o comando show shared_preload_libraries.

   • Defina wal_level como logical.

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

   • Defina wal_sender_timeout como 0.

     Para definir este parâmetro, execute o comando ALTER SYSTEM SET wal_sender_timeout = 0;, em que 0 desativa o mecanismo de limite de tempo usado para terminar as ligações de replicação inativas.

   • max_replication_slots define o número máximo de horários de replicação que a instância de origem pode suportar. Tem de ser definido, pelo menos, para o número de subscrições esperado para estabelecer ligação, mais algumas reservas para a sincronização de tabelas.

     O Database Migration Service requer uma ranhura para cada base de dados migrada (que são todas as bases de dados na instância de origem).

     Por exemplo, se existirem 5 bases de dados na instância de origem e 2 tarefas de migração criadas para a origem, o número de espaços de replicação tem de ser, pelo menos, 5 * 2 = 10, mais o número de espaços de replicação já usados por si. Se planeia usar definições de paralelismo de descarga de dados ajustados, certifique-se de que aumenta o número de espaços de replicação e valide a sua configuração executando o teste da tarefa de migração quando criar a tarefa de migração.

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

   • max_wal_senders deve ser definido, pelo menos, como 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 já estiver a usar 2 remetentes, o número de processos de remetentes WAL em execução em simultâneo seria 10 + 2 = 12. Se planeia usar definições de paralelismo de descarga de dados ajustados, certifique-se de que aumenta o número de remetentes e valide a configuração executando o teste da tarefa de migração quando criar a tarefa de migração.

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

   • max_worker_processes deve ser definido, pelo menos, para o mesmo número de bases de dados que o Database Migration Service vai migrar (que são todas as bases de dados na instância de origem), mais o número de max_worker_processes já usados na sua instância.

     Se planeia usar definições de paralelismo de descarga de dados ajustadas, certifique-se de que aumenta o número de processos de trabalho e valide a configuração executando o teste da tarefa de migração quando criar a tarefa de migração.

     Para definir este parâmetro, execute o comando ALTER SYSTEM SET max_worker_processes = #;, em que # representa o número de bases de dados que vão ser migradas.

   Os parâmetros que está a definir neste passo aplicam-se a um servidor de base de dados PostgreSQL em execução. Também pode tornar estas alterações persistentes adicionando as seguintes linhas de código ao ficheiro 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 alterações de configuração, reinicie a instância de origem.

Amazon RDS PostgreSQL

1. Instale a extensão pglogical na base de dados de origem. Para mais informações, consulte o artigo Usar extensões do PostgreSQL com o Amazon RDS para PostgreSQL na documentação do Amazon RDS.

2. Configure a instância de origem através de grupos de parâmetros.

   • Crie um novo grupo de parâmetros. No grupo de parâmetros:
   • Certifique-se de que o parâmetro shared_preload_libraries inclui pglogical.
   • Defina o parâmetro rds.logical_replication como 1. Isto ativa os registos WAL ao nível lógico.
   • Defina o parâmetro wal_sender_timeout como 0. Esta ação desativa o mecanismo de limite de tempo usado para terminar as ligações de replicação inativas.

   • Defina 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. Tem de ser definido, pelo menos, para o número de subscrições que se espera que se associem, mais algumas reservas para a sincronização de tabelas.

     O Database Migration Service requer uma ranhura para cada base de dados migrada (que são todas as bases de dados na instância de origem).

     Por exemplo, se existirem 5 bases de dados na instância de origem e se forem criadas 2 tarefas de migração para a origem, o número de espaços de replicação tem de ser, pelo menos, 5 * 2 = 10, mais o número de espaços de replicação já usados por si. Se planeia usar definições de paralelismo de descarga de dados ajustados, certifique-se de que aumenta o número de slots de replicação e valide a configuração executando o teste da tarefa de migração quando criar a tarefa de migração.

     O valor predefinido para este parâmetro é 10.

   • Defina o parâmetro max_wal_senders 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 já estiver a usar 2 remetentes, o número de processos de remetentes WAL em execução em simultâneo seria 10 + 2 = 12. Se planeia usar definições de paralelismo de descarga de dados ajustadas, certifique-se de que aumenta o número de remetentes e valide a configuração executando o teste da tarefa de migração quando criar a tarefa de migração.

     O valor predefinido para este parâmetro é 10.

   • Defina o parâmetro max_worker_processes de origem para, pelo menos, o mesmo número de bases de dados que o Database Migration Service vai migrar (que são todas as bases de dados na instância de origem), mais o número de max_worker_processes já usado na sua instância. Se planeia usar definições de paralelismo de descarga de dados ajustadas, certifique-se de que aumenta o número de processos de trabalho e valide a configuração executando o teste da tarefa de migração quando criar a tarefa de migração.

     O valor predefinido para este parâmetro é 8.

3. Associe o grupo de parâmetros à instância. Se estiver a criar uma nova instância, pode encontrar esta opção em Configuração adicional. Caso contrário, modifique a instância para anexar o grupo de parâmetros.

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

Nota: a extensão pglogical pode registar credenciais em texto simples na instância de origem. Este comportamento é causado pela própria extensão e não está relacionado com o Database Migration Service nem com o Cloud SQL.

Cloud SQL para PostgreSQL

Ative a replicação lógica e a descodificação para a base de dados de origem configurando as seguintes flags.

Todas as definições nesta secção são configuradas através de flags no Cloud SQL. Para ativar flags no Cloud SQL, consulte o artigo Configurar flags de base de dados.

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

2. Defina a flag max_replication_slots. Esta flag define o número máximo de slots de replicação que a instância de origem pode suportar. Tem de ser definido, pelo menos, para o número de subscrições esperado para estabelecer ligação, mais algumas reservas para a sincronização de tabelas.

   O Database Migration Service requer uma ranhura para cada base de dados migrada (que são todas as bases de dados na instância de origem).

   Por exemplo, se existirem 5 bases de dados na instância de origem e se forem criadas 2 tarefas de migração para a origem, o número de espaços de replicação tem de ser, pelo menos, 5 * 2 = 10, mais o número de espaços de replicação já usados por si. Se planeia usar definições de paralelismo de descarga de dados ajustados, certifique-se de que aumenta o número de espaços de replicação e valide a sua configuração executando o teste da tarefa de migração quando criar a tarefa de migração.

   O valor predefinido para esta flag é 10.

3. Defina a flag max_wal_senders para, pelo menos, o mesmo valor que 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 já estiver a usar 2 remetentes, o número de processos de remetentes WAL em execução em simultâneo seria 10 + 2 = 12. Se planeia usar definições de paralelismo de descarga de dados ajustados, certifique-se de que aumenta o número de remetentes e valide a configuração executando o teste da tarefa de migração quando criar a tarefa de migração.

   O valor predefinido para esta flag é 10.

4. Defina a flag de origem max_worker_processes, pelo menos, para o mesmo número de bases de dados que o Database Migration Service vai migrar (que são todas as bases de dados na instância de origem), mais o número de max_worker_processes já usadas na sua instância. Se planeia usar definições de paralelismo de descarga de dados ajustados, tenha em conta dois processos de trabalho adicionais por ligação (até um máximo de 20 trabalhadores).

   O valor predefinido para esta flag é 8.

5. Reinicie a instância de origem para que as alterações de configuração que fez às flags possam entrar em vigor.

Ative a monitorização do atraso de replicação para a versão do PostgreSQL inferior a 9.6

Se estiver a migrar de uma versão do PostgreSQL anterior à 9.6, a métrica de atraso na replicação não está disponível por predefinição. Existem três alternativas que lhe permitem acompanhar esta métrica para garantir um tempo de inatividade mínimo quando promove a base de dados:

1. Opção 1: ative o serviço de migração de bases de dados para acompanhar o atraso na replicação concedendo acesso a uma consulta específica. Usando um utilizador com o privilégio SUPERUSER, faça o seguinte:

   1. Defina a seguinte função para permitir que o serviço de migração de base de dados consulte o atraso na 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 autorizaçã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};

2. Opção 2: conceda o privilégio SUPERUSER diretamente ao USER usado para estabelecer ligação à instância de origem. Isto permite que o serviço de migração de base de dados leia o atraso na replicação diretamente.

3. Opção 3: acompanhe o atraso na replicação de forma independente através da seguinte consulta:

   Para versões do PostgreSQL anteriores à 10, execute este comando como 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 serviço de migração de bases de dados não reflete a métrica de atraso na replicação nos gráficos nem nas respostas da API.