É 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).
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_deencoding
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
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.
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:
|
| 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.
Console
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.
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.
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.
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;
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.
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_deencoding, 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.
A extensão
pglogicalnão funciona em instâncias com a aplicação de conector ativada. Essa limitação não se aplica às instâncias com acesso a serviços particulares configurado.Ao restaurar uma instância que tenha o
cloudsql.logical_decodingoucloudsql.enable_pglogicalativado 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_decodingoucloudsql.enable_pglogicalativado (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_decodingoucloudsql.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_decodingoucloudsql.enable_pglogicalna 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_decodingoucloudsql.enable_pglogicalna 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.