Configurar a replicação e a decodificação lógica

MySQL   |  PostgreSQL   |  SQL Server

É possível usar recursos de replicação e decodificação lógicas (em inglês) no Cloud SQL para PostgreSQL. Esses recursos permitem fluxos de trabalho de replicação lógica e fluxos de trabalho de captura de dados de alterações (CDC).

Importante :antes de usar esses recursos, consulte as Observações e limitações.

Para informações gerais sobre replicação, consulte Sobre replicação no Cloud SQL.

Introdução

Quando o PostgreSQL executa a replicação lógica, as alterações transmitidas por streaming para réplicas são extraídas dos registros WAL usando a decodificação lógica. As alterações decodificadas são independentes do formato de armazenamento físico subjacente. As alterações refletem apenas as alterações nos dados de um nível SQL, em termos de INSERTs, UPDATEs e DELETEs. Essa independência da camada de armazenamento oferece grande flexibilidade e permite uma ampla variedade de funcionalidades pelos consumidores dos streamings de alteração.

A replicação lógica é o recurso principal gerado na decodificação lógica.

Ao contrário do recurso de replicação física (em inglês) do PostgreSQL, que exige que os bancos de dados de origem e destino sejam da mesma versão, a replicação lógica permite a replicação entre versões principais do PostgreSQL. A replicação lógica no Cloud SQL é compatível com a extensão pglogical, disponível em todas as versões do PostgreSQL e na replicação lógica nativa do PostgreSQL, adicionada no PostgreSQL 10.

O formato em que as alterações são transmitidas por streaming pode ser configurado com diferentes plug-ins. Isso permite arquiteturas flexíveis de captura de dados de alterações (CDC, na sigla em inglês). Por exemplo, a extensão wal2json permite fazer streaming de todas as alterações em um banco de dados para um consumidor, formatadas como JSON. O Cloud SQL é compatível com o decodificador pgoutput, o módulo de contribuição test_decoding e wal2json integrados. Atualmente, o Cloud SQL oferece suporte para as variantes wal2json da saída JSON: format-version 1, que codifica toda a transação como um único objeto JSON, e format-version 2, que gera um objeto JSON por comando. Esses plug-ins permitem a replicação para bancos de dados que não são do PostgreSQL.

Configurar a instância do PostgreSQL

Observação: para alterar as sinalizações discutidas nesta seção, é necessário reiniciar a instância. Para minimizar o tempo de inatividade, leia esta seção inteira antes de escolher as configurações de sinalização.

O PostgreSQL é compatível com a decodificação lógica gravando informações no registro de gravação antecipada (WAL, na sigla em inglês).

No Cloud SQL, você ativa esse recurso definindo a sinalização cloudsql.logical_decoding como on. Essa configuração é diferente da usada no PostgreSQL padrão Se você alterar uma instância externa do PostgreSQL, ative esse recurso definindo o parâmetro de configuração wal_level como logical.

Observação: para ativar ou desativar sinalizações no Cloud SQL, use as instruções padrão.

Se você planeja usar a extensão pglogical, ela precisa ser adicionada a shared_preload_libraries. Como o Cloud SQL não permite a modificação direta dessa sinalização, a pglogical é ativada definindo cloudsql.enable_pglogical como on. (Em uma VM, sudo apt-get install postgresql-13-pglogical) e reinicie o banco de dados.

Se você estiver usando pglogical para replicar entre duas instâncias do PostgreSQL, a decodificação lógica só precisará ser ativada na instância principal, e não na instância de réplica (a menos que a própria instância seja uma principal das outras réplicas). No entanto, a extensão pglogical precisa estar ativada nas duas instâncias. Para exemplos de como os termos "principal" e "réplica" são usados e os significados deles, consulte Sobre replicação no Cloud SQL.

Ativar a conectividade de rede

Verifique se as instâncias principais aceitam conexões da instância de réplica.

Principal	Réplica	Configuração
Cloud SQL (IP público)	Cloud SQL (IP público)	Adicione o endereço IP de saída da réplica às redes autorizadas primárias.
Cloud SQL (IP particular)	Cloud SQL (IP particular)	Se as duas instâncias estiverem no mesmo projeto do Google Cloud, adicione o intervalo de IP alocado da rede VPC da réplica à rede autorizada que hospeda as instâncias. Para encontrar o intervalo de IP alocado no Console do Google Cloud: Acesse a página Redes VPC. Selecione a rede VPC que você está usando. Selecione a guia Conexão de serviço privado. Selecione a guia Intervalos de IP alocados. Observação: não é necessário adicionar mais nada às redes autorizadas de nenhuma instância se a sub-rede da rede VPC estiver no intervalo 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16, porque que esses blocos de sub-rede estão na lista de controle de acesso de cada instância por padrão.
Externo	Cloud SQL	É possível usar o Serviço de migração de banco de dados.
Cloud SQL	Externo	Consulte Configurar réplicas externas para mais informações.

Acessar o endereço IP de saída de uma instância de réplica

Se a instância de réplica for uma instância do Cloud SQL e tiver um endereço IP público, siga as etapas a seguir para receber o endereço IP de saída.

Observação: ignore este procedimento se estiver configurando a replicação usando apenas uma rede particular. Isso ocorre porque um endereço IP de saída não é necessário nesse cenário.

Console

1. Abra a página de instâncias do Cloud SQL.

2. Ao lado do endereço IP público da réplica do Cloud SQL, passe o cursor sobre a dica da ferramenta Mais informações e recupere o endereço IP de saída. O endereço IP de saída não é o endereço IP exibido na listagem principal da réplica no Console do Cloud.

Cuidado: as instâncias que usam alta disponibilidade não têm um endereço IP de saída consistente e não podem ser usadas como assinantes.

Se a instância da réplica não for uma instância do Cloud SQL, consulte a documentação relevante.

Para mais informações sobre como conseguir o IP público de uma instância, consulte Conseguir o endereço IP de saída da réplica do Cloud SQL.

gcloud

É possível usar o seguinte comando gcloud:

gcloud sql instances describe [REPLICA_NAME] --format="default(ipAddresses)"

Permitir conexões

Se a instância principal for uma instância do Cloud SQL, é possível permitir o acesso oriundo do endereço IP de saída da réplica adicionando-a como uma rede autorizada.

Cuidado: quando você restaura uma instância de assinante de um backup, o endereço IP de saída da instância do assinante pode mudar. Para reiniciar a replicação depois de restaurar a instância assinante, adicione o novo IP de saída como uma rede autorizada.

Ativar conexões de replicação para o PostgreSQL 9.6 e versões anteriores

Se a instância principal não estiver em execução no Cloud SQL e estiver executando o PostgreSQL 9.6 ou anterior, verifique se o arquivo pg_hba.conf da instância está definido para aceitar conexões de replicação. Adicione a linha a seguir nesse arquivo usando all all apenas para testes iniciais. Para ter mais segurança, limite usuários e endereços IP apenas aos necessários, como neste exemplo:

host replication all all md5

Para mais informações, consulte o arquivo pg_hba.conf (em inglês).

Crie um usuário de réplica

Para usar recursos de decodificação lógica, crie um usuário do PostgreSQL com o atributo REPLICATION.

Observação: no PostgreSQL padrão, forneça as permissões SUPERUSER. Ao usar a extensão pglogical, o usuário precisa ter o papel cloudsqlsuperuser para executar posteriormente o comando CREATE EXTENSION. No Cloud SQL, um usuário precisa ter o papel cloudsqlsuperuser. para executar esse comando.

Exemplos

CREATE USER replication_user WITH REPLICATION
IN ROLE cloudsqlsuperuser LOGIN PASSWORD 'secret';

Como alternativa, é possível definir esse atributo em um usuário existente:

ALTER USER existing_user WITH REPLICATION;

Observação: o usuário atual precisa ter o privilégio CREATE em cada banco de dados que ele está tentando replicar.

Recursos do PostgreSQL

Quando a decodificação lógica é usada, um processo em segundo plano na instância principal do PostgreSQL transforma as alterações WAL em alterações lógicas usando o plug-in de decodificação selecionado e as redireciona para um consumidor, que pode até ser uma instância que não é do PostgreSQL. Esse processo em segundo plano é chamado de remetente do WAL. O número de remetentes WAL simultâneos que podem estar ativos em uma instância do PostgreSQL é limitado pela sinalização max_wal_senders. Essa sinalização assume como padrão 10, e o limite dela cresce linearmente com a memória da instância do Cloud SQL, permitindo oito remetentes de WAL por GB.

Para garantir que os segmentos WAL não sejam descartados antes de serem enviados a todos os consumidores, o PostgreSQL usa slots de replicação lógica para rastrear quais dados foram enviados para qual consumidor (e slots de replicação físicos para réplicas de leitura. O número de slots de replicação que você pode criar para uma instância do PostgreSQL é limitado pela sinalização max_replication_slots. Por padrão, essa sinalização é definida como 10, e o limite aumenta com a memória da instância do Cloud SQL. Isso permite que haja entre dois e oito slots de replicação por GB de memória.

A tabela a seguir mostra a relação entre a memória máxima de uma instância do Cloud SQL e os slots máximos de replicação da instância.

Memória máxima (GB)	Slots máximos de replicação
4	10
16	32
32	128
64	256
128	512
256	1.024
512	2.048
512+	4.096

Importante: um slot que não está sendo usado ativamente para rastrear dados faz com que o PostgreSQL mantenha os segmentos de WAL indefinidamente, fazendo com que o espaço em disco aumente indefinidamente. A maioria das ferramentas baseadas na decodificação lógica cria e descarta slots de replicação automaticamente. Os slots de replicação não utilizados podem ser detectados consultando a visualização do sistema pg_replication_slots e filtrando a coluna active. Os slots não utilizados podem ser descartados para remover segmentos WAL usando o comando pg_drop_replication_slot.

Geralmente, há um slot de replicação e um remetente WAL por consumidor. Portanto, essas sinalizações precisam ser definidas com valores aproximadamente iguais. No entanto, o PostgreSQL recomenda fornecer um pequeno buffer para que max_wal_senders processe quando as conexões são desativadas inesperadamente e novas conexões são estabelecidas. A replicação física, conforme usada pelas réplicas de leitura do Cloud SQL, também usa um slot de replicação e um remetente WAL. Portanto, conte isso ao calcular a quantidade necessária de cada recurso.

A replicação lógica nativa do PostgreSQL e a pglogical exigem mais processos em segundo plano para serem executados, tanto nas instâncias principal quanto nas de réplica. O número de processos em segundo plano que podem ser executados é limitado pela sinalização max_worker_processes. O padrão é oito, e o limite dela cresce linearmente com a memória da instância do Cloud SQL, permitindo dois processos adicionais por GB de memória. O número exato de processos de worker usados com essas abordagens é explicado nas respectivas seções.

Se essa sinalização estiver muito baixa e a replicação falhar com a mensagem de erro worker registration failed nos registros, provavelmente será necessário aumentar a configuração de max_worker_processes.

Os remetentes do WAL não contam como processos de worker. Os workers gerados para a execução de consulta paralela contam. Portanto, se o valor de max_worker_processes estiver definido como muito baixo, é possível que você veja um desempenho ruim, porque o PostgreSQL não pode aproveitar a execução de consulta paralela.

Usando a função pg_ls_waldir (), é possível determinar o uso do disco do WAL. Essa função é restrita a usuários cloudsqlsuperuser, como o usuário administrador padrão postgres. Essa função está disponível apenas no PostgreSQL versão 10 e posteriores.

Para calcular o uso total do disco WAL:

postgres=> select * from pg_ls_waldir();

nome	tamanho	modificação
00000001000000000000000A	16777216	2021-08-11 15:16:49+00
000000010000000000000009	16777216	2021-08-12 06:23:24+00

(2 linhas)

postgres=> select pg_size_pretty(sum(size)) as "Total WAL disk usage" from pg_ls_waldir();

Uso total do disco WAL
32 MB

(1 linha)

Configurar a replicação lógica com uma réplica externa

Consulte Como configurar réplicas externas para ver um exemplo completo que usa a decodificação pglogical e logical.

Configurar a replicação lógica com pglogical

Para configurar a replicação lógica com pglogical, a decodificação lógica precisa estar ativada na instância principal. Defina cloudsql.logical_decoding=on na instância do Cloud SQL ou wal_level=logical em uma instância externa. Além disso, pglogical precisa estar ativada na instância principal e na réplica. Defina cloudsql.enable_pglogical=on em uma instância do Cloud SQL ou adicione pglogical a shared_preload_libraries em uma instância externa. Observe que a alteração dessas sinalizações requer a reinicialização das instâncias principal e réplica.

Se você encontrar problemas nessas etapas, consulte Solução de problemas da pglogical.

Criar um usuário com privilégios de replicação

É necessário um usuário com privilégios de replicação e o papel cloudsqlsuperuser nas instâncias principal e de réplica ao usar a pglogical. Todos os comandos descritos abaixo precisam ser executados por esse usuário.

Instalar a extensão pglogical

É necessário instalar a extensão pglogical nas instâncias principal e réplica. Na principal, o usuário de replicação (ou seja, o usuário que se conecta ao banco de dados) precisa instalá-la.

CREATE EXTENSION pglogical;

Criar um nó pglogical em cada instância

Um nó pglogical representa uma instância física do PostgreSQL e armazena detalhes de conexão dela. As instâncias principal e réplica precisam se registrar como nós:

source-instance$ SELECT pglogical.create_node(
    node_name := 'primary',
    dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=secret'
);

dest-instance$ SELECT pglogical.create_node(
    node_name := 'replica',
    dsn := 'host=<replica-ip> port=5432 dbname=postgres user=replication_user password=secret'
);

Criar uma tabela com dados a serem replicados

A extensão pglogical permite replicar apenas um subconjunto de tabelas para um destino. Por exemplo, criaremos uma tabela fictícia na instância principal e a preencheremos com alguns dados para testar:

CREATE TABLE replica_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO replica_test (data) VALUES ('apple'), ('banana'), ('cherry');

A tabela também precisa ser criada na instância de réplica.

Adicionar a tabela a um conjunto de replicação

Para aceitar a replicação de diferentes conjuntos de dados para destinos diferentes, a pglogical tem o conceito de um conjunto de replicação. É possível adicionar nossa tabela de teste ao conjunto de replicações padrão.

SELECT pglogical.replication_set_add_table('default', 'replica_test', true);

Criar a assinatura da pglogical

Forneça os detalhes da conexão com a instância principal para criar a assinatura da pglogical na instância de destino.

SELECT pglogical.create_subscription(
    subscription_name := 'test_sub',
    provider_dsn := 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
);

SELECT * FROM pglogical.show_subscription_status('test_sub');

Se o status aparecer como "replicando", a configuração foi bem-sucedida. Consulte a tabela replica_test para garantir que os dados tenham sido replicados. Insira e modifique registros na instância principal e verifique se eles aparecem na instância de réplica.

Na principal, consulte a tabela pg_replication_slots para ver o slot de replicação criado pela assinatura.

Limpeza

Depois que o teste for bem-sucedido, descarte a assinatura na réplica usando pglogical.drop_subscription('test_sub'). Verifique se o slot de replicação também é descartado na principal. Caso contrário, os segmentos WAL continuarão sendo acumulados na instância de réplica.

Para saber mais sobre conjuntos de replicação, replicação parcial de dados, replicação DDL e outras configurações e limitações avançadas, consulte a documentação de pglogical (em inglês).

Uso de recursos

A extensão pglogical executa vários processos em segundo plano que contam para o limite max_worker_processes.

No estado estável, um processo "supervisor" é executado quando ativado, um processo "gerenciador" por banco de dados PostgreSQL que instalou a extensão (por exemplo, pode haver D desses) e um processo "aplicar" por assinatura de pglogical na instância de réplica (por exemplo, pode haver S desses). No entanto, a extensão pode gerar mais processos de worker ao executar uma sincronização inicial e, na verdade, gerar processos "gerenciador" para cada banco de dados na instância, mas se o banco de dados não tem a extensão instalada, ela é encerrada imediatamente.

Portanto, aloque um número de processos de worker maior do que o necessário no estado estável. Os processos de worker são usados pelo PostgreSQL para outras finalidades, como o processamento de consultas paralelas. Se max_worker_processes estiver definido muito baixo, a replicação poderá falhar silenciosamente ou o PostgreSQL talvez não consiga realizar o processamento paralelo de consultas.

Em resumo, estas configurações são recomendadas:

max_worker_processes
  >= 1 + D + 8 (on the source instance)
  >= 1 + D + S + 8 (on the destination instance)
max_wal_senders >= S + 2 (on the source instance)
max_replication_slots >= S (on the source instance)

Resolver problemas pglogical

Não foi possível criar a extensão pglogical

Ao tentar instalar a extensão pglogical, é possível ver este erro:

ERROR:  pglogical is not in shared_preload_libraries

Ao instalar a pglogical em uma instância do Cloud SQL, verifique se você definiu cloudsql.enable_pglogical=on. Se estiver usando uma instância externa, adicione-a diretamente à sinalização shared_preload_libraries. Por exemplo, shared_preload_libraries=pg_stat_statements,pglogical. Essas modificações exigem uma reinicialização da instância principal.

Não foi possível criar a assinatura da pglogical

Ao criar uma assinatura, pglogical verifica primeiro se ela pode usar os detalhes da conexão para se conectar à instância. Primeiro, ele tenta criar uma conexão normal e, se isso falhar, ocorrerá um erro: ERROR: could not connect to the postgresql server.

Se esse erro ocorrer, verifique se a instância principal está configurada para permitir conexões da instância de réplica e se os detalhes da conexão fornecidos estão corretos. São fornecidos mais detalhes sobre o motivo pelo qual o PostgreSQL não conseguiu estabelecer uma conexão.

Depois de criar uma conexão normal, pglogical tenta fazer uma conexão de replicação especial. No PostgreSQL 9.6 e versões anteriores, esse tipo de conexão pode ter uma configuração de autenticação diferente. É necessário atualizar o arquivo pg_hba.conf na instância de origem se você vir este erro: ERROR: could not connect to the postgresql server in replication mode.

O arquivo pg_hba.conf usado pelo Cloud SQL já tem as alterações necessárias. Esse erro só ocorre ao se conectar a uma instância externa que não é gerenciada pelo Cloud SQL.

Como alternativa, a conexão do modo de replicação poderá falhar se a instância de origem não permitir remetentes WAL suficientes. Se você vir FATAL: number of requested standby connections exceeds max_wal_senders, aumente max_wal_senders na instância principal.

A assinatura da pglogical está inativa

Uma assinatura da pglogical talvez não foi replicada. Para resolver esse problema, primeiro verifique se um processo em segundo plano está em execução na instância de réplica. Consulte pg_stat_activity para verificar se um processo pglogical apply está em execução. Caso contrário, verifique os registros no nó de destino. Se você vir a mensagem worker registration failed,, é possível aumentar a configuração max_worker_processes.

Em seguida, verifique se um espaço de replicação foi criado na instância principal. Na instância da réplica, a linha em pglogical.subscription contém o nome do slot que a assinatura tenta criar e, na instância principal, é possível consultar pg_replication_slots para verificar se o slot foi criado com sucesso.

Se nenhum slot de replicação tiver sido criado, verifique os registros na instância principal.

Um erro de ERROR: logical decoding requires wal_level >= logical significa que a sinalização wal_level não foi definida como logical. Para resolver isso, defina cloudsql.logical_decoding=on na instância principal, se ela for uma instância do Cloud SQL.

Como alternativa, se a instância for externa, defina wal_level=logical.

Caso contrário, é possível ver ERROR: all replication slots are in use com a dica útil HINT: Free one or increase max_replication_slots.

Configurar a replicação lógica do PostgreSQL nativo

Desde o PostgreSQL 10, o PostgreSQL é compatível com replicação lógica nativa e integrada. Para configurar a replicação lógica nativa, a decodificação lógica precisa ser ativada na instância principal, definindo cloudsql.logical_decoding=on em uma instância do Cloud SQL ou wal_level=logical em uma instância externa. Observe que a modificação dessas sinalizações requer a reinicialização da instância principal.

Verifique se as instâncias estão configuradas corretamente (para conectividade de rede etc.) revisando as seções em Configurar a instância do PostgreSQL. Nesta página, mostramos as etapas de uma prova de conceito. Se você encontrar problemas ao seguir as etapas nestas seções, consulte Resolver problemas pglogical. Para mais informações, consulte Replicação lógica na documentação do PostgreSQL.

Criar uma tabela com dados a serem replicados

A replicação lógica nativa do PostgreSQL é compatível com um banco de dados inteiro ou apenas tabelas individuais. Por exemplo, criaremos uma tabela fictícia na instância principal e a preencheremos com dados para testar.

CREATE TABLE native_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO native_test (data) VALUES ('apple'), ('banana'), ('cherry');

A tabela também precisa ser criada na instância de réplica.

Criar uma publicação na instância principal

A replicação lógica nativa do PostgreSQL lida com editores e assinantes. Para criar uma publicação dos dados em native_test:

CREATE PUBLICATION pub FOR TABLE native_test;

Criar uma assinatura na instância de réplica

Veja um exemplo de como criar uma assinatura na instância de réplica:

CREATE SUBSCRIPTION sub
    CONNECTION 'host=<primary-ip> port=5432 dbname=postgres user=replication_user password=replicapassword'
    PUBLICATION pub;

A criação da assinatura na instância de réplica requer o papel cloudsqlsuperuser. Depois de criar a assinatura, consulte a tabela native_test para verificar se os dados apareceram na instância de réplica.

Na principal, é possível consultar a tabela pg_replication_slots para ver o slot de replicação criado pela assinatura.

Limpeza

Quando o teste for bem-sucedido, solte a assinatura na réplica usando DROP SUBSCRIPTION sub;. Verifique se o slot de replicação também é descartado na principal. Caso contrário, os segmentos WAL continuarão sendo acumulados na instância principal.

Limitações na replicação lógica nativa do PostgreSQL

O acesso à coluna subconninfo da tabela do sistema pg_subscription está indisponível.

A execução de pg_dump não pode despejar informações sobre assinaturas porque verifica se o usuário conectado tem permissões de superusuário.

Receber alterações WAL decodificadas para captura de dados de alterações (CDC, na sigla em inglês)

Como um caso de uso alternativo da CDC, a decodificação lógica pode fazer streaming de alterações de uma instância do PostgreSQL. A ferramenta padrão usada para isso é pg_recvlogical.

Use a ferramenta pg_recvlogical para criar um slot de replicação e fazer streaming das alterações rastreadas por ele. O formato das alterações é determinado pela escolha do plug-in de decodificação. Você pode usar:

• wal2json, para fazer streaming das alterações formatadas como JSON ou

• test_decoding, para transmitir alterações formatadas com o formato de texto básico

Criar slot de replicação

Para criar um slot de replicação, execute:

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --create-slot \
  -P <decoder_plugin>

Alterações no streaming

Em um terminal do Cloud Shell, execute:

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --start \
  -f -

Em outro terminal do Cloud Shell, conecte-se ao banco de dados e execute os comandos a seguir:

CREATE TABLE cdc_test (id SERIAL PRIMARY KEY, data text);
INSERT INTO cdc_test (data) VALUES ('apple', 'banana');
UPDATE cdc_test SET data = 'cherry' WHERE id = 2;
DELETE FROM cdc_test WHERE id = 1;
DROP TABLE cdc_test;

Se você estiver usando o plug-in decodificador wal2json, uma saída semelhante à seguinte será exibida no primeiro terminal do Cloud Shell:

{"change":[]}
{"change":[{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[1,"apple"]},{"kind":"insert","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"banana"]}]}
{"change":[{"kind":"update","schema":"public","table":"cdc_test","columnnames":["id","data"],"columntypes":["integer","text"],"columnvalues":[2,"cherry"],"oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[2]}}]}
{"change":[{"kind":"delete","schema":"public","table":"cdc_test","oldkeys":{"keynames":["id"],"keytypes":["integer"],"keyvalues":[1]}}]}
{"change":[]}

Se você estiver usando o plug-in decodificador test_decoding, uma saída semelhante à seguinte será exibida no primeiro terminal do Cloud Shell:

BEGIN 19460
COMMIT 19460
BEGIN 19461
table public.cdc_test: INSERT: id[integer]:1 data[text]:'apple'
table public.cdc_test: INSERT: id[integer]:2 data[text]:'banana'
COMMIT 19461
BEGIN 19462
table public.cdc_test: UPDATE: id[integer]:2 data[text]:'cherry'
COMMIT 19462
BEGIN 19463
table public.cdc_test: DELETE: id[integer]:1
COMMIT 19463
BEGIN 19464
COMMIT 19464

O ID das transações pode ser diferente.

Limpeza

Depois de concluir o teste, execute o comando a seguir para descartar o slot de replicação criado:

pg_recvlogical
  -h <instance_ip> \
  -U <replication_user> \
  -p 5432 \
  -d postgres \
  --slot test_slot \
  --drop-slot

Observações e limitações:

As limitações nesta seção se aplicam aos recursos de replicação e decodificação lógicas do Cloud SQL para PostgreSQL.

• Ao restaurar uma instância que tenha o cloudsql.logical_decoding ou cloudsql.enable_pglogical ativado e que esteja agindo como editor para replicação lógica, desative primeiro a replicação para todas as instâncias de destino. Caso contrário, a restauração para a instância falhará com um erro, mas atualmente os detalhes do erro não estão visíveis.

• Quando você restaura um backup de uma instância que tem cloudsql.logical_decoding ou cloudsql.enable_pglogical ativado (no momento do backup) e você o restaura para uma nova instância, o estado de replicação não é restaurado para a nova instância. É necessário reconfigurar a replicação manualmente depois.

• Em uma instância do Cloud SQL com uma ou mais réplicas de leitura do Cloud SQL (usando replicação física), se você ativar cloudsql.logical_decoding ou cloudsql.enable_pglogical, essas sinalizações também serão ativadas na réplica de leitura.

  • As instâncias de réplica de leitura do Cloud SQL não podem atuar como editores de replicação lógica porque o PostgreSQL não é compatível com a decodificação lógica em réplicas de leitura. No entanto, as sinalizações são ativadas na instância da réplica de leitura para garantir que possam servir como substitutas para a instância principal se e quando ela for promovida.

  • Ativar cloudsql.logical_decoding ou cloudsql.enable_pglogical na instância principal faz com que as sinalizações sejam ativadas em todas as réplicas de leitura, e isso faz com que as réplicas primárias e de leitura sejam reiniciadas em sucessão. Para evitar essa situação e controlar quando cada instância é reiniciada, é possível (1) definir as sinalizações em cada réplica de leitura por vez e depois (2) definir as sinalizações na instância principal.

  • Desativar cloudsql.logical_decoding ou cloudsql.enable_pglogical na instância principal não faz com que as sinalizações sejam desativadas em todas as réplicas de leitura. Para desativar as sinalizações nas instâncias, execute o inverso das etapas descritas acima: (1) desative as sinalizações na instância principal e, em seguida, (2) desative as sinalizações em cada réplica de leitura.