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, 17.
- Amazon Aurora 10.11+, 11.6+, 12.4+, 13.3+, 14.6+, 15.2+, 16 e 17.
- PostgreSQL autogerenciado (no local ou em qualquer VM de nuvem totalmente controlada) 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 PostgreSQL Flexible Server: 11+
Para configurar a origem, é preciso ajustar a instância de origem e os bancos de dados de origem subjacentes.
Configurar a instância de origem
Para configurar sua instância de origem, siga estas etapas:
- Para origens 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 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.
- A instância de origem precisa incluir o banco de dados
postgres
. Se você não tiver esse banco de dados, crie-o. Instale o pacote
pglogical
na instância de origem e verifique se ele está incluído na variávelshared_preload_libraries
. Consulte Instalar o pacotepglogical
na instância de origem para seu ambiente.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 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.
Para origens que usam a extensão
pg_cron
: a extensãopg_cron
(ou qualquer configuraçãocron
associada a ela) não é migrada pelo Database Migration Service, mas é aceita em destinos do Cloud SQL para PostgreSQL. Se você usar a extensãopg_cron
nos bancos de dados de origem, poderá reinstalá-la na instância de destino depois que a migração for concluída.
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 do PostgreSQL no local: modelos de bancos de dados
template0
etemplate1
- Para origens do Amazon RDS:
template0
,template1
erdsadmin
- Para origens do Cloud SQL: modelos de bancos de dados
template0
etemplate1
- Para origens 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:
Somente para origens do PostgreSQL versão 9.4, instale as seguintes extensões
pglogical
em cada banco de dados na sua instância de origem:CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
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
.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 CDC. Você precisa migrar as instruçõesUPDATE
eDELETE
manualmente.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: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.GRANT USAGE on SCHEMA pglogical to PUBLIC;
em cada banco de dados a ser migrado.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.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.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.- Se a origem for o Amazon RDS, execute o seguinte comando:
GRANT rds_replication to USER
- Se a origem não for o Amazon RDS, execute o seguinte comando:
- Papel
ALTER USER USER with REPLICATION
- Papel
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
- Instale o pacote pglogical no servidor.
- Conecte-se à instância e defina os seguintes parâmetros, conforme necessário:
shared_preload_libraries
precisa incluirpglogical
.Para definir esse parâmetro, execute o comando
ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]';
.- Defina
wal_level
comological
.Para definir esse parâmetro, execute o comando
ALTER SYSTEM SET wal_level = 'logical';
. Defina
wal_sender_timeout
como0
.Para definir esse parâmetro, execute o comando
ALTER SYSTEM SET wal_sender_timeout = 0;
, em que0
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 compatíveis com a instância de origem. Ele precisa ser definido para 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, ou seja, 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. Se você planeja usar configurações de paralelismo de despejo de dados ajustadas, 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 de migração.
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 precisa ser definido pelo menos da mesma forma que
max_replication_slots
, além do número de remetentes já usados na sua instância.Por exemplo, se o parâmetro
Para definir esse parâmetro, execute o comandomax_replication_slots
estiver definido como10
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 de paralelismo de despejo de dados ajustadas, aumente o número de remetentes e verifique sua configuração executando o teste do job de migração ao criar o job de migração.ALTER SYSTEM SET max_wal_senders = #;
, em que # representa o número de processos de remetentes WAL em execução simultaneamente.- 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), além do número de
max_worker_processes
já usados na instância.Se você planeja usar configurações de paralelismo de despejo de dados ajustadas, aumente o número de processos de worker e verifique a configuração executando o teste do job de migração ao criar o job de migração.
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.
- Para aplicar as mudanças na configuração, reinicie a instância de origem.
Banco de Dados do Microsoft Azure para PostgreSQL
Para configurar a origem do Microsoft Azure Database for PostgreSQL, siga estas etapas:
- Instale o pacote pglogical no seu servidor.
Somente para origens do PostgreSQL versão 9.4, instale as seguintes extensões
pglogical
em cada banco de dados na sua instância de origem:CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
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
.Configure os parâmetros de servidor necessários na sua origem usando o portal do Microsoft Azure. Para mais informações, consulte Configurar parâmetros do servidor no Azure Database for PostgreSQL e Parâmetros do servidor no Azure Database for PostgreSQL na documentação da Microsoft.
Configure os seguintes parâmetros:
- Defina
shared_preload_libraries
para incluirpglogical
. - Defina
azure.extensions
para incluirpglogical
. - Defina
wal_level
comological
. 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 compatíveis com a instância de origem.O Database Migration Service requer um slot para cada banco de dados migrado, ou seja, 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. Se você planeja usar configurações de paralelismo de despejo de dados ajustadas, 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 de migração.
Defina
max_wal_senders
como pelo menos o mesmo quemax_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 como10
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 de paralelismo de despejo de dados ajustadas, aumente o número de remetentes e verifique a configuração executando o teste do job de migração ao criar o job de migração.
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), além do número demax_worker_processes
já usados na sua instância.Se você planeja usar configurações de paralelismo de despejo de dados ajustadas, aumente o número de processos de worker e verifique a configuração executando o teste do job de migração ao criar o job de migração.
- Defina
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 comoon
, selecione Básico, TLS ou mTLS. - Se
require_secure_transport
estiver definido comooff
, selecione Nenhum.
- Se
- Para aplicar as mudanças na configuração, reinicie a instância de origem.
Amazon RDS PostgreSQL
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.
Configure a instância de origem usando grupos de parâmetros.
- Crie um novo grupo de parâmetros. No grupo de parâmetros:
- Verifique se o parâmetro
shared_preload_libraries
incluipglogical
. - Defina o parâmetro
rds.logical_replication
como 1. Isso vai ativar os registros WAL no nível "lógico". - 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 compatíveis com a instância de origem. Ele precisa ser definido como pelo menos o número de assinaturas que precisam ser conectadas, além de algumas reservas para sincronização de tabelas.
O Database Migration Service requer um slot para cada banco de dados migrado, ou seja, 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 dois jobs de migração forem criados para a origem, o número de slots de replicação precisará ser pelo menos 5 x 2 = 10, além do número de slots de replicação já usados. Se você planeja usar configurações de paralelismo de despejo de dados ajustadas, 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 de migração.
O valor padrão desse 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 como10
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 de paralelismo de despejo de dados ajustadas, aumente o número de remetentes e verifique sua configuração executando o teste do job de migração ao criar o job de migração.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), além do número de
max_worker_processes
já usados na sua instância. Se você planeja usar configurações de paralelismo de despejo de dados ajustadas, 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 de migração.O valor padrão desse parâmetro é 8.
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.
Para aplicar as mudanças na configuração, reinicie a instância de origem.
Cloud SQL para PostgreSQL
Ative a replicação lógica e a decodificação para o banco de dados de origem configurando as seguintes flags:
- Defina as flags
cloudsql.logical_decoding
ecloudsql.enable_pglogical
comoon
. Defina a flag max_replication_slots. Essa flag define o número máximo de slots de replicação compatíveis com a instância de origem. Ele precisa ser definido com 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, ou seja, 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 dois jobs de migração forem criados para a origem, o número de slots de replicação precisará ser pelo menos 5 x 2 = 10, além do número de slots de replicação já usados. Se você planeja usar configurações de paralelismo de despejo de dados ajustadas, 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 de migração.
O valor padrão dessa flag é 10.
Defina a flag max_wal_senders com pelo menos o mesmo valor de
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 como10
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 de paralelismo de despejo de dados ajustadas, aumente o número de remetentes e verifique sua configuração executando o teste do job de migração ao criar o job de migração.O valor padrão dessa flag é 10.
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á usado na instância. Se você planeja usar configurações de paralelismo de despejo de dados ajustadas, 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 de migração.O valor padrão dessa flag é 8.
Defina o parâmetro
wal_sender_timeout
como0
:ALTER SYSTEM SET wal_sender_timeout = 0;
O valor
0
desativa o mecanismo de tempo limite que encerra as conexões de replicação inativas.- Reinicie a instância de origem para que as alterações 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 que você acompanhe essa métrica para garantir um tempo de inatividade mínimo ao promover o banco de dados:
Opção 1: ative o Database Migration Service para rastrear o atraso de replicação concedendo acesso a uma consulta específica. Usando um usuário com o privilégio
SUPERUSER
, faça o seguinte: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; $$;
Conceda a permissão
EXECUTE
ao USER executando os seguintes comandos:REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
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:
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 banco de dados não reflete a métrica de atraso da replicação nos gráficos ou nas respostas da API.