Configure a replicação lógica e a descodificação

Pode usar as funcionalidades de replicação e descodificação lógica no Cloud SQL para PostgreSQL. Estas funcionalidades ativam fluxos de trabalho de replicação lógica e fluxos de trabalho de captura de dados de alterações (CDC).

Para obter informações gerais sobre a replicação, consulte o artigo Acerca da replicação no Cloud SQL.

Introdução

Quando o PostgreSQL realiza a replicação lógica, as alterações transmitidas para as réplicas são extraídas dos registos WAL através da descodificação lógica. As alterações descodificadas são independentes do formato de armazenamento físico subjacente. As alterações refletem apenas as alterações nos dados a partir de um nível SQL, em termos de INSERÇÕES, ATUALIZAÇÕES e ELIMINAÇÕES. Esta independência da camada de armazenamento oferece uma grande flexibilidade e permite uma vasta gama de funcionalidades por parte dos consumidores dos fluxos de alterações.

A replicação lógica é a funcionalidade principal criada com base na descodificação lógica.

Ao contrário da funcionalidade de replicação física do PostgreSQL, que requer que as bases de dados de origem e de 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 é 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 plug-ins. Isto permite arquiteturas de captura de dados de alterações (CDC) flexíveis. Por exemplo, a extensão permite o streaming de todas as alterações numa base de dados para um consumidor, formatadas como JSON.wal2json O Cloud SQL suporta o descodificador pgoutput incorporado, o módulo contrib test_decoding e wal2json. Atualmente, o Cloud SQL suporta ambas as variantes de saída JSON: wal2json, que codifica toda a transação como um único objeto JSON, e format-version 1, que produz um objeto JSON por comando.format-version 2 Estes plugins permitem a replicação para bases de dados que não sejam do PostgreSQL.

Configure a sua instância do PostgreSQL

O PostgreSQL suporta a descodificação lógica escrevendo informações adicionais no respetivo registo de transações (WAL).

No Cloud SQL, ativa esta funcionalidade definindo a flag cloudsql.logical_decoding como on. Esta definição é diferente da definição usada no PostgreSQL padrão. Se alterar uma instância do PostgreSQL externa, ativa esta funcionalidade ao definir o parâmetro de configuração wal_level como logical.

Se planeia usar a extensão pglogical, tem de adicionar o pglogical a shared_preload_libraries. Uma vez que o Cloud SQL não permite a modificação direta desta flag, o pglogical é ativado definindo cloudsql.enable_pglogical como on. (Numa VM, sudo apt-get install postgresql-13-pglogical) e reinicie a base de dados.

Se estiver a usar o pglogical para fazer a replicação entre duas instâncias do PostgreSQL, só tem de ativar a descodificação lógica na instância principal e não na instância de réplica (a menos que essa instância seja, em si mesma, uma principal para outras réplicas). No entanto, a extensão pglogical tem de estar ativada em ambas as instâncias. Para ver exemplos de como os termos "principal" e "réplica" são usados e os respetivos significados, consulte o artigo Acerca da replicação no Cloud SQL.

Ative a conetividade de rede

Certifique-se de que as suas instâncias principais aceitam ligaçõ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, siga os passos abaixo para obter o respetivo endereço IP de saída.

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

Permita ligações

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

Ative as ligações de replicação para o PostgreSQL 9.6 e versões anteriores

Se a sua instância principal não estiver a ser executada no Cloud SQL e estiver a executar o PostgreSQL 9.6 ou anterior, tem de garantir que o ficheiro pg_hba.conf da instância está definido para aceitar ligações de replicação. Adicione a linha seguinte a esse ficheiro, usando all all apenas para testes iniciais. Para maior segurança, limite os utilizadores e os endereços IP apenas aos necessários, como neste exemplo:

host replication all all md5

Para mais informações, consulte o artigo O ficheiro pg_hba.conf.

Crie um utilizador de replicação

Para usar funcionalidades de descodificação lógica, crie um utilizador do PostgreSQL com o atributo REPLICATION.

Exemplos

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

Em alternativa, pode definir este atributo num utilizador existente:

ALTER USER existing_user WITH REPLICATION;

Recursos do PostgreSQL

Quando a descodificação lógica é usada, um processo em segundo plano na instância principal do PostgreSQL transforma as alterações do WAL em alterações lógicas, usando o plug-in de descodificação selecionado, e retransmite-as a um consumidor (que pode até ser uma instância não PostgreSQL). Este processo em segundo plano é denominado remetente WAL. O número de remetentes WAL simultâneos que podem estar ativos numa instância do PostgreSQL está limitado pela flag max_wal_senders. Esta flag tem o valor predefinido de 10 e o respetivo limite aumenta linearmente com a memória da sua instância do Cloud SQL, o que permite 8 remetentes de WAL por GB de memória.

Para garantir que os segmentos WAL não são rejeitados antes de serem enviados para todos os consumidores, o PostgreSQL usa slots de replicação lógica para acompanhar que dados foram enviados para que consumidor (e slots de replicação física para réplicas de leitura). O número de slots de replicação que pode criar para uma instância do PostgreSQL é limitado pela flag max_replication_slots. Esta flag tem o valor predefinido de 10 e o respetivo limite aumenta com a memória da sua instância do Cloud SQL, o que permite entre 2 e 8 slots de replicação por GB de memória.

A tabela seguinte mostra a relação entre a memória máxima de uma instância do Cloud SQL e o número máximo de slots de replicação para a instância.

Geralmente, existe um espaço de replicação e um remetente de WAL por consumidor, pelo que estas flags devem ser definidas para valores aproximadamente iguais. No entanto, o PostgreSQL recomenda fornecer um pequeno buffer para o max_wal_senders processar quando as ligações terminam inesperadamente e são feitas novas ligações. A replicação física, conforme usada pelas réplicas de leitura do Cloud SQL, também usa um espaço de replicação e um remetente WAL, por isso, conte-os quando calcular quantos recursos de cada tipo precisa.

A replicação lógica nativa do PostgreSQL e o pglogical requerem processos em segundo plano adicionais para serem executados nas instâncias principal e de réplica. O número de processos em segundo plano que podem ser executados é limitado pela flag max_worker_processes. O valor predefinido é oito e o limite aumenta linearmente com a memória da sua instância do Cloud SQL, o que permite dois processos adicionais por GB de memória. O número exato de processos de trabalho usados com estas abordagens é explicado nas respetivas secções.

Se esta flag estiver definida como demasiado baixa e a replicação falhar com a mensagem de erro worker registration failed nos seus registos, é provável que tenha de aumentar a definição max_worker_processes.

Tenha em atenção que os remetentes WAL não contam como processos de trabalho. Os trabalhadores gerados para a execução de consultas paralelas contam, pelo que, se o valor de max_worker_processes estiver definido como demasiado baixo, pode ter um desempenho fraco porque o PostgreSQL não consegue tirar partido da execução de consultas paralelas.

Usando a função pg_ls_waldir (), pode determinar a utilização do disco WAL. Esta função está restrita a utilizadores cloudsqlsuperuser, como o utilizador administrador predefinido postgres. Esta função só está disponível na versão 10 e superior do PostgreSQL.

Para calcular a utilização 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)

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

Consulte o artigo Configurar réplicas externas para ver um exemplo completo que usa pglogical e descodificação lógica.

Configure a replicação lógica com o pglogical

Para configurar a replicação lógica com o pglogical, a descodificação lógica tem de estar ativada na instância principal. Defina cloudsql.logical_decoding=on na instância do Cloud SQL ou wal_level=logical numa instância externa. Além disso, o pglogical tem de estar ativado na instância principal e na réplica. Defina cloudsql.enable_pglogical=on numa instância do Cloud SQL ou adicione o pglogical a shared_preload_libraries numa instância externa. Tenha em atenção que a alteração destas flags requer o reinício das instâncias principal e de réplica.

Se encontrar problemas com estes passos, consulte o artigo Resolva problemas com o pglogical.

Crie um utilizador com privilégios de replicação

Precisa de um utilizador com privilégios de replicação e a função cloudsqlsuperuser nas instâncias primária e de réplica quando usa o pglogical. Todos os comandos descritos abaixo devem ser executados por esse utilizador.

Instale a extensão pglogical

Tem de instalar a extensão pglogical nas instâncias principal e de réplica. No servidor principal, o utilizador de replicação (ou seja, o utilizador que se liga à base de dados) tem de instalá-lo.

CREATE EXTENSION pglogical;

Crie um nó pglogical em cada instância

Um nó pglogical representa uma instância física do PostgreSQL e armazena detalhes de ligação para essa instância. A instância principal e a réplica têm de se registar 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 os dados a replicar

A extensão pglogical permite replicar apenas um subconjunto de tabelas para um destino. Por exemplo, vamos criar uma tabela fictícia na instância principal e preenchê-la 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 tem de ser criada na instância da réplica.

Adicione a tabela a um conjunto de replicação

Para suportar a replicação de diferentes conjuntos de dados para diferentes destinos, o pglogical tem o conceito de um conjunto de replicação. Podemos adicionar a nossa tabela de teste ao conjunto de replicação predefinido.

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

Crie a subscrição pglogical

Crie a subscrição pglogical na instância de destino fornecendo detalhes de ligação à instância principal.

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 estado aparecer como "a replicar", a configuração foi bem-sucedida. Consulte a tabela replica_test para garantir que os dados foram replicados. Inserir e modificar registos na instância principal e verificar se aparecem na instância de réplica.

Na base de dados primária, consulte a tabela pg_replication_slots para ver o espaço de replicação criado pela subscrição.

Limpeza

Depois de o teste ser bem-sucedido, elimine a subscrição na réplica com o comando pglogical.drop_subscription('test_sub'). Verifique se o espaço de replicação também foi eliminado no servidor principal. Caso contrário, os segmentos WAL continuam a acumular-se na instância da réplica.

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

Utilização de recursos

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

No estado estável, executa um processo de "supervisor" quando ativado, um processo de "gestor" por base de dados PostgreSQL que tenha instalado a extensão (por exemplo, podem existir D destes) e um processo de "aplicação" por subscrição pglogical na instância da réplica (por exemplo, podem existir S destes). No entanto, a extensão pode gerar processos de trabalho adicionais quando faz uma sincronização inicial e gera efetivamente processos de "gestor" para todas as bases de dados na instância, mas se a base de dados não tiver a extensão instalada, sai imediatamente.

Por isso, atribua mais alguns processos de trabalho do que o necessário no estado estável. Os processos de trabalho são usados pelo PostgreSQL para outros fins, como o processamento de consultas paralelas. Se max_worker_processes estiver definido como um valor demasiado baixo, a replicação pode falhar silenciosamente ou o PostgreSQL pode não conseguir realizar o processamento de consultas paralelas.

Em resumo, recomendamos as seguintes definições:

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)

Resolva problemas com o pglogical

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

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

ERROR:  pglogical is not in shared_preload_libraries

Quando instala o pglogical numa instância do Cloud SQL, certifique-se de que definiu o parâmetro cloudsql.enable_pglogical=on. Se usar uma instância externa, adicione-a diretamente à flag shared_preload_libraries, por exemplo, shared_preload_libraries=pg_stat_statements,pglogical. Estas modificações requerem o reinício da instância principal.

Não é possível criar a subscrição pglogical

Quando cria uma subscrição, o pglogical verifica primeiro se pode usar os detalhes da ligação para se ligar à instância. Primeiro, tenta criar uma ligação normal e, se falhar, ocorre um erro: ERROR: could not connect to the postgresql server.

Se este erro ocorrer, certifique-se de que a instância principal está configurada para permitir ligações da instância de réplica e certifique-se de que os detalhes da ligação que forneceu estão corretos. São fornecidos detalhes adicionais sobre o motivo pelo qual o PostgreSQL não conseguiu estabelecer uma ligação.

Depois de criar uma ligação normal, o pglogical tenta fazer uma ligação de replicação especial. No PostgreSQL 9.6 e anterior, este tipo de ligação pode ter uma configuração de autenticação diferente. Tem de atualizar o ficheiro pg_hba.conf na instância de origem se vir este erro: ERROR: could not connect to the postgresql server in replication mode.

O ficheiro pg_hba.conf usado pelo Cloud SQL já tem as alterações necessárias. Este erro só ocorre quando se liga a uma instância externa que não é gerida pelo Cloud SQL.

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

A subscrição pglogical está inativa

Uma subscrição pglogical pode não ser replicada. Para resolver este problema, primeiro, certifique-se de que um processo em segundo plano está a ser executado na instância da réplica. Query pg_stat_activity para verificar se um processo pglogical apply está em execução. Caso contrário, verifique os registos no nó de destino. Se vir a mensagem worker registration failed,, pode aumentar a definição max_worker_processes.

Em seguida, certifique-se de que foi criado um espaço de replicação na instância principal. Na instância da réplica, a linha em pglogical.subscription contém o nome do intervalo que a subscrição tenta criar e, na instância principal, pode consultar pg_replication_slots para verificar se o intervalo foi criado com êxito.

Se não tiver sido criado nenhum espaço de replicação, verifique os registos na instância principal.

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

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

Caso contrário, pode ver ERROR: all replication slots are in use, juntamente com o útil HINT: Free one or increase max_replication_slots.

Configure a replicação lógica nativa do PostgreSQL

Desde o PostgreSQL 10, o PostgreSQL suporta a replicação lógica integrada nativa. Para configurar a replicação lógica nativa, a descodificação lógica tem de estar ativada na instância principal, definindo cloudsql.logical_decoding=on numa instância do Cloud SQL ou wal_level=logical numa instância externa. Tenha em atenção que a modificação destas flags requer o reinício da instância principal.

Certifique-se de que as suas instâncias estão configuradas corretamente (para a conetividade de rede, etc.) revendo as secções em Configure a sua instância do PostgreSQL. Esta página fornece passos para uma prova de conceito. Se encontrar problemas ao seguir os passos nessas secções, consulte o artigo Resolva problemas do pglogical. Para mais informações, consulte a secção Replicação lógica na documentação do PostgreSQL.

Crie uma tabela com os dados a replicar

A replicação lógica nativa do PostgreSQL suporta uma base de dados inteira ou apenas tabelas individuais. Por exemplo, vamos criar uma tabela fictícia na instância principal e preenchê-la 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 tem de ser criada na instância da réplica.

Crie uma publicação na instância principal

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

CREATE PUBLICATION pub FOR TABLE native_test;

Crie uma subscrição na instância da réplica

Segue-se um exemplo de criação de uma subscrição na instância da réplica:

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

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

Na base de dados primária, pode consultar a tabela pg_replication_slots para ver o intervalo de replicação criado pela subscrição.

Limpeza

Assim que o teste for bem-sucedido, elimine a subscrição na réplica através do comando DROP SUBSCRIPTION sub;. Verifique se o espaço de replicação também é eliminado no servidor principal. Caso contrário, os segmentos WAL continuam a acumular-se na instância principal.

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

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

A execução de pg_dump não pode transferir informações sobre subscrições porque verifica se o utilizador que está a estabelecer ligação tem autorizações de superutilizador.

Receba alterações WAL descodificadas para a captura de dados de alterações (CDC)

Como exemplo de utilização alternativo para a CDC, a descodificação lógica pode transmitir alterações a partir de uma instância do PostgreSQL. A ferramenta padrão usada para isto é o pg_recvlogical.

Pode usar a ferramenta pg_recvlogical para criar um espaço de replicação e transmitir alterações acompanhadas por esse espaço. O formato das alterações é determinado pela sua escolha do plug-in de descodificação. Pode usar:

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

• test_decoding, para transmitir alterações formatadas com um formato de texto simples

Crie um espaço de replicação

Para criar um espaço de replicação, execute o seguinte comando:

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

Alterações à stream

Num terminal do Cloud Shell, execute:

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

Enquanto estiver noutro terminal do Cloud Shell, ligue-se à sua base 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 estiver a usar o plug-in do descodificador wal2json, é apresentada uma saída semelhante à seguinte 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 estiver a usar o plug-in do descodificador test_decoding, é apresentada uma saída semelhante à seguinte 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

(Os IDs das transações podem ser diferentes.)

Limpeza

Depois de concluir os testes, elimine o espaço de replicação que criou executando o seguinte comando:

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

Notas e limitações

As notas e as limitações nesta secção aplicam-se às funcionalidades de replicação lógica e descodificação do Cloud SQL para PostgreSQL.

• A extensão pglogical não funciona em instâncias que tenham a aplicação do conetor ativada. Esta limitação não se aplica às instâncias que têm o acesso privado ao serviço configurado.

• Quando restaura uma instância que tem cloudsql.logical_decoding ou cloudsql.enable_pglogical ativado e está atualmente a atuar como publicador para replicação lógica, tem de desativar primeiro a replicação em todas as instâncias de destino. Caso contrário, a reposição na instância falha com um erro, mas atualmente os detalhes do erro não estão visíveis.

• Quando restaura uma cópia de segurança de uma instância que tinha o cloudsql.logical_decoding ou o cloudsql.enable_pglogical ativado (no momento da cópia de segurança) e a está a restaurar para uma nova instância, o estado de replicação não é restaurado para a nova instância. Posteriormente, tem de reconfigurar a replicação manualmente.

• Numa instância do Cloud SQL com uma ou mais réplicas de leitura do Cloud SQL (através da replicação física), se ativar cloudsql.logical_decoding ou cloudsql.enable_pglogical, essas flags também são ativadas 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 publicadores para replicação lógica porque o PostgreSQL não suporta descodificação lógica em réplicas de leitura para essas versões mais antigas. No entanto, para garantir que as instâncias podem servir como substituição da instância principal em caso de promoção, os indicadores lógicos continuam ativados nas instâncias de réplica de leitura para estas versões anteriores.

  • A partir da versão 16 do Cloud SQL para PostgreSQL, as instâncias de réplica de leitura do Cloud SQL podem atuar como publicadores para replicação lógica, se a instância principal tiver as flags lógicas definidas. O subscritor lógico pode ser uma instância do Cloud SQL ou uma instância externa. No entanto, a eliminação de linhas e as operações de vácuo na base de dados primária podem eliminar tuplos que ainda são necessários para a descodificação lógica na réplica de leitura. Nesses casos, o espaço de replicação lógica na réplica de leitura é invalidado para evitar inconsistências.

  • A ativação de cloudsql.logical_decoding ou cloudsql.enable_pglogical na instância principal faz com que os flags sejam ativados em todas as réplicas de leitura e isto faz com que a instância principal e as réplicas de leitura sejam reiniciadas em rápida sucessão. Para evitar esta situação e controlar quando cada instância é reiniciada, pode (1) definir os indicadores em cada réplica de leitura por sua vez e, só depois, (2) definir os indicadores na instância principal.

  • A desativação do cloudsql.logical_decoding ou do cloudsql.enable_pglogical na instância principal não faz com que as flags sejam desativadas em todas as réplicas de leitura. Para desativar as flags nas instâncias, tem de realizar o inverso dos passos descritos acima: (1) desativar as flags na instância principal e, em seguida, (2) desativar as flags em cada réplica de leitura por sua vez.