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

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

Você pode usar recursos de replicação lógica e decodificação no Cloud SQL para PostgreSQL. Esses recursos permitem fluxos de trabalho de replicação lógica e fluxos de trabalho de captura de dados alterados (CDC).

Para obter 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 para as réplicas são extraídas dos logs do WAL usando 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 do nível SQL, em termos de INSERTs, UPDATEs e DELETEs. Essa independência da camada de armazenamento proporciona grande flexibilidade e permite uma ampla gama de funcionalidades para os consumidores dos fluxos de alterações.

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

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

O formato no qual as alterações são transmitidas pode ser configurado com diferentes plugins. Isso permite arquiteturas flexíveis de captura de dados alterados (CDC). Por exemplo, a extensão wal2json permite transmitir todas as alterações em um banco de dados para um consumidor, formatadas como JSON. O Cloud SQL oferece suporte ao decodificador pgoutput integrado, ao módulo contrib test_decoding e wal2json . Atualmente, o Cloud SQL oferece suporte a ambas as variantes wal2json de 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 plugins permitem a replicação para bancos de dados não PostgreSQL.

Configure sua instância do PostgreSQL

O PostgreSQL oferece suporte à decodificação lógica gravando informações adicionais em seu log de gravação antecipada (WAL).

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

Se você planeja usar a extensão pglogical, adicione-a shared_preload_libraries . Como o Cloud SQL não permite a modificação direta deste sinalizador, o pglogical é habilitado definindo cloudsql.enable_pglogical como on . (Em uma VM, use sudo apt-get install postgresql-13-pglogical ) e reinicie o banco de dados.

Se você estiver usando o pglogical para replicar entre duas instâncias do PostgreSQL, a decodificação lógica só precisará ser habilitada na instância primária , e não na instância de réplica (a menos que essa instância seja primária para outras réplicas). No entanto, a extensão pglogical deve ser habilitada em ambas as instâncias. Para obter exemplos de como os termos "primário" e "réplica" são usados ​​e seus significados, consulte Sobre replicação no Cloud SQL .

Habilitar conectividade de rede

Certifique-se de que suas instâncias primárias aceitem conexões da instância de réplica.

Obtenha 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, execute as seguintes etapas para obter seu endereço IP de saída.

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

Permitir conexões

Se a instância primária for uma instância do Cloud SQL, você poderá permitir o acesso do endereço IP de saída da réplica adicionando-a como uma rede autorizada .

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

Se a sua instância primária não estiver em execução no Cloud SQL e estiver executando o PostgreSQL 9.6 ou anterior, você precisará garantir que o arquivo pg_hba.conf da instância esteja configurado para aceitar conexões de replicação. Adicione a seguinte linha a esse arquivo, usando all all apenas para testes iniciais. Para maior segurança, limite os usuários e endereços IP apenas aos necessários, como neste exemplo:

host replication all all md5

Para obter informações adicionais, consulte o arquivo pg_hba.conf .

Criar um usuário de replicação

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

Exemplos

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

Como alternativa, você pode definir este atributo em um usuário existente:

ALTER USER existing_user WITH REPLICATION;

Recursos do PostgreSQL

Quando a decodificação lógica é usada, um processo em segundo plano na instância primária do PostgreSQL transforma as alterações do WAL em alterações lógicas, usando o plugin de decodificação selecionado, e as retransmite para um consumidor (que pode até ser uma instância não PostgreSQL). Esse processo em segundo plano é chamado de remetente do WAL. O número de remetentes do WAL simultâneos que podem estar ativos em uma instância do PostgreSQL é limitado pelo sinalizador max_wal_senders . O padrão desse sinalizador é 10 e seu limite aumenta linearmente com a memória da sua instância do Cloud SQL, permitindo 8 remetentes do WAL por GB de memória.

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ísica para réplicas de leitura). O número de slots de replicação que você pode criar para uma instância do PostgreSQL é limitado pelo sinalizador max_replication_slots . O padrão desse sinalizador é 10 e seu limite aumenta com a memória da sua instância do Cloud SQL, permitindo entre 2 e 8 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 para a instância.

Geralmente, há um slot de replicação e um remetente WAL por consumidor, portanto, esses sinalizadores devem ser definidos com valores aproximadamente iguais. No entanto, o PostgreSQL recomenda fornecer um pequeno buffer para max_wal_senders para lidar com conexões que falham inesperadamente e novas conexões são estabelecidas. A replicação física, como a usada pelas réplicas de leitura do Cloud SQL, também usa um slot de replicação e um remetente WAL, portanto, considere-os ao calcular a quantidade de cada recurso necessária.

A replicação lógica nativa do PostgreSQL e o pglogical exigem processos em segundo plano adicionais para execução, tanto nas instâncias primárias quanto nas réplicas. O número de processos em segundo plano que podem ser executados é limitado pelo sinalizador max_worker_processes . O padrão é oito, e esse limite aumenta linearmente com a memória da sua instância do Cloud SQL, permitindo dois processos adicionais por GB de memória. O número exato de processos de trabalho usados ​​com essas abordagens é explicado em suas respectivas seções.

Se esse sinalizador estiver definido com um valor muito baixo e a replicação falhar com a mensagem de erro worker registration failed nos seus logs, provavelmente você precisará aumentar a configuração max_worker_processes .

Observe que remetentes WAL não contam como processos de trabalho. Trabalhadores gerados para execução de consultas paralelas contam, portanto, se o valor de max_worker_processes for definido com um valor muito baixo, você poderá ter um desempenho ruim, pois o PostgreSQL não consegue aproveitar a execução de consultas paralelas.

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

Para calcular o uso total do disco WAL:

postgres=> select * from pg_ls_waldir();

(2 linhas)

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

(1 linha)

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

Consulte Configurando réplicas externas para um exemplo completo usando decodificação lógica e pglogical.

Configurar replicação lógica com pglogical

Para configurar a replicação lógica com pglogical, a decodificação lógica deve estar habilitada na instância primária. Defina cloudsql.logical_decoding=on na instância do Cloud SQL ou wal_level=logical em uma instância externa. Além disso, pglogical deve estar habilitado tanto na instância primária quanto na instância de 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 desses sinalizadores requer a reinicialização das instâncias primária e de réplica.

Se você encontrar problemas com essas etapas, consulte Solucionar problemas do pglogical .

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

Você precisa de um usuário com privilégios de replicação e a função cloudsqlsuperuser nas instâncias primária e de réplica ao usar o pglogical. Todos os comandos descritos abaixo devem ser executados por esse usuário.

Instalar a extensão pglogical

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

CREATE EXTENSION pglogical;

Crie um nó pglógico em cada instância

Um nó pglogical representa uma instância física do PostgreSQL e armazena detalhes de conexão para essa instância. Tanto a instância primária quanto a réplica devem 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'
);

Crie uma tabela com dados para replicar

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

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

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

Adicionar a tabela a um conjunto de replicação

Para oferecer suporte à replicação de diferentes conjuntos de dados para diferentes destinos, o pglogical utiliza o conceito de conjunto de replicação. Podemos adicionar nossa tabela de teste ao conjunto de replicação padrão.

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

Crie a assinatura pglogical

Crie a assinatura pglogical na instância de destino fornecendo detalhes de conexão à instância primária.

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 foram replicados. Insira e modifique registros na instância primária e verifique se eles aparecem na instância de réplica.

No primário, consulte a tabela pg_replication_slots para ver o slot de replicação criado pela assinatura.

Limpar

Após o teste ser bem-sucedido, descarte a assinatura na réplica usando pglogical.drop_subscription('test_sub') . Verifique se o slot de replicação também foi descartado no primário. Caso contrário, os segmentos WAL continuarão a se acumular na instância da réplica.

Para mais informações sobre conjuntos de replicação, replicação parcial de dados, replicação DDL, outras configurações avançadas e limitações, consulte a documentação do pglogical .

Uso de recursos

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

Em estado estável, ele executa um processo "supervisor" quando habilitado, um processo "gerenciador" por banco de dados PostgreSQL que tenha a extensão instalada (por exemplo, pode haver D desses processos) e um processo "apply" por assinatura pglogical na instância de réplica (por exemplo, pode haver S desses processos). A extensão, no entanto, pode gerar processos de trabalho adicionais ao realizar uma sincronização inicial e, na verdade, gera processos "gerenciadores" para cada banco de dados na instância, mas se o banco de dados não tiver a extensão instalada, ela sai imediatamente.

Portanto, aloque um pouco mais de processos de trabalho do que o necessário no estado estável. Os processos de trabalho são usados ​​pelo PostgreSQL para outros propósitos, como processamento paralelo de consultas. Se max_worker_processes for definido com um valor muito baixo, a replicação poderá falhar silenciosamente ou o PostgreSQL poderá não conseguir executar 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)

Solucionar problemas do pglogical

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

Ao tentar instalar a extensão pglogical, você pode ver o erro:

ERROR:  pglogical is not in shared_preload_libraries

Ao instalar o pglogical em uma instância do Cloud SQL, certifique-se de ter definido cloudsql.enable_pglogical=on . Se estiver usando uma instância externa, adicione-a diretamente ao sinalizador shared_preload_libraries , por exemplo, shared_preload_libraries=pg_stat_statements,pglogical . Essas modificações exigem a reinicialização da instância primária.

Não é possível criar uma assinatura pglogical

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

Se esse erro ocorrer, certifique-se de que a instância primária esteja configurada para permitir conexões da instância de réplica e de que os detalhes de conexão fornecidos estejam corretos. Detalhes adicionais serão fornecidos sobre o motivo pelo qual o PostgreSQL não conseguiu estabelecer uma conexão.

Após criar uma conexão regular, o pglogical tenta estabelecer uma conexão de replicação especial. No PostgreSQL 9.6 e versões anteriores, esse tipo de conexão podia ter uma configuração de autenticação diferente. Você precisa atualizar o arquivo pg_hba.conf na instância de origem se 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 conectar a uma instância externa que não é gerenciada pelo Cloud SQL.

Como alternativa, a conexão no modo de replicação pode 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 o número de max_wal_senders na instância primária.

a assinatura do pglogical está inativa

Uma assinatura pglogical pode falhar na replicação. Para resolver esse problema, primeiro certifique-se de que um processo em segundo plano esteja 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 logs no nó de destino. Se você vir a mensagem " worker registration failed, poderá aumentar a configuração max_worker_processes .

Em seguida, certifique-se de que um slot de replicação foi criado na instância primária. Na instância de réplica, a linha em pglogical.subscription contém o nome do slot que a assinatura tenta criar e, na instância primária, você pode consultar pg_replication_slots para verificar se o slot foi criado com sucesso.

Se nenhum slot de replicação foi criado, verifique os logs na instância primária.

Um erro de ERROR: logical decoding requires wal_level >= logical implica que o sinalizador wal_level não foi definido como logical . Resolva isso definindo cloudsql.logical_decoding=on na instância primária, se for uma instância do Cloud SQL.

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

Caso contrário, você poderá ver ERROR: all replication slots are in use , junto com a HINT: Free one or increase max_replication_slots .

Configurar replicação lógica nativa do PostgreSQL

Desde o PostgreSQL 10, o PostgreSQL oferece suporte à replicação lógica nativa integrada. Para configurar a replicação lógica nativa, a decodificação lógica deve ser habilitada na instância primária, 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 desses sinalizadores requer a reinicialização da instância primária.

Certifique-se de que suas instâncias estejam configuradas corretamente (para conectividade de rede, etc.) revisando as seções em Configurar sua instância do PostgreSQL . Esta página fornece etapas para uma prova de conceito. Se você encontrar algum problema ao seguir as etapas nessas seções, consulte Solucionar problemas do pglogical . Para obter mais informações, consulte Replicação Lógica na documentação do PostgreSQL.

Crie uma tabela com dados para replicar

A replicação lógica nativa do PostgreSQL suporta um banco de dados inteiro ou apenas tabelas individuais. Como exemplo, criaremos uma tabela fictícia na instância primária e a preencheremos com dados para teste.

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

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

Crie uma publicação na instância primária

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

CREATE PUBLICATION pub FOR TABLE native_test;

Crie uma assinatura na instância de réplica

Aqui está um exemplo de criação de 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 a função cloudsqlsuperuser . Após criar a assinatura, consulte a tabela native_test para verificar se os dados apareceram na instância de réplica.

No primário, você pode consultar a tabela pg_replication_slots para ver o slot de replicação criado pela assinatura.

Limpar

Após o teste ser bem-sucedido, descarte a assinatura na réplica usando DROP SUBSCRIPTION sub; . Verifique se o slot de replicação também foi descartado na instância primária. Caso contrário, os segmentos WAL continuarão a se acumular na instância primária.

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

O acesso à coluna subconninfo da tabela do sistema pg_subscription não está disponível.

A execução 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 alterados (CDC)

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

Você pode usar a ferramenta pg_recvlogical para criar um slot de replicação e transmitir as alterações rastreadas por esse slot. O formato das alterações é determinado pela sua escolha do plugin de decodificação. Você pode usar:

• wal2json , para transmitir alterações formatadas como JSON, ou

• test_decoding , para transmitir alterações formatadas com um 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>

Mudanças no fluxo

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 seu banco de dados e execute os seguintes comandos:

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 plugin 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

(Seus IDs de transação podem ser diferentes.)

Limpar

Após concluir o teste, descarte o slot de replicação que você criou executando:

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

Notas e limitações

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

• A extensão pglogical não funciona em instâncias com a imposição do conector habilitada. Essa limitação não se aplica a instâncias com acesso a serviços privados configurado.

• Ao restaurar uma instância com cloudsql.logical_decoding ou cloudsql.enable_pglogical habilitado e que atualmente atua como publicador para replicação lógica, você deve desabilitar a replicação para todas as instâncias de destino primeiro. Caso contrário, a restauração para a instância falhará com um erro, mas os detalhes do erro não estão visíveis no momento.

• Ao restaurar um backup de uma instância que tinha cloudsql.logical_decoding ou cloudsql.enable_pglogical habilitado (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. Você deve reconfigurar a replicação manualmente posteriormente.

• 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ê habilitar cloudsql.logical_decoding ou cloudsql.enable_pglogical , esses sinalizadores também serão habilitados na réplica de leitura.

  • Para o Cloud SQL para PostgreSQL versões 15 e anteriores, as instâncias de réplica de leitura do Cloud SQL não podem atuar como publicadoras para replicação lógica, pois o PostgreSQL não oferece suporte à decodificação lógica em réplicas de leitura para essas versões mais antigas. No entanto, para garantir que as instâncias possam servir como substitutas da instância primária em caso de promoção, os sinalizadores lógicos ainda são habilitados nas instâncias de réplica de leitura para essas versões anteriores.

  • A partir do Cloud SQL para PostgreSQL versão 16, as instâncias de réplica de leitura do Cloud SQL podem atuar como publicadores para replicação lógica, se a instância primária tiver os sinalizadores lógicos definidos. O assinante lógico pode ser uma instância do Cloud SQL ou uma instância externa. No entanto, operações de exclusão de linha e de vácuo na instância primária podem excluir tuplas que ainda são necessárias para a decodificação lógica na réplica de leitura. Nesses casos, o slot de replicação lógica na réplica de leitura é invalidado para evitar inconsistências.

  • Habilitar cloudsql.logical_decoding ou cloudsql.enable_pglogical na instância primária faz com que os sinalizadores sejam habilitados em todas as réplicas de leitura, o que faz com que as réplicas primária e de leitura sejam reiniciadas em sucessão próxima. Para evitar essa situação e controlar quando cada instância é reiniciada, você pode (1) definir os sinalizadores em cada réplica de leitura por vez e, somente então, (2) definir os sinalizadores na instância primária.

  • Desabilitar cloudsql.logical_decoding ou cloudsql.enable_pglogical na instância primária não faz com que os sinalizadores sejam desabilitados em todas as réplicas de leitura. Para desabilitar os sinalizadores em todas as instâncias, você deve executar o inverso das etapas descritas acima: (1) desabilitar os sinalizadores na instância primária e, em seguida, (2) desabilitar os sinalizadores em cada réplica de leitura por vez.