Atraso da replicação

MySQL | PostgreSQL | SQL Server

Nesta página, descrevemos como resolver problemas e corrigir atrasos de replicação para réplicas de leitura do Cloud SQL.

Visão geral

As réplicas de leitura do Cloud SQL usam a replicação de streaming do PostgreSQL. As alterações são gravadas no registro de gravação antecipada (WAL) na instância principal. O remetente do WAL envia o WAL para o receptor do WAL na réplica, onde são aplicados.

O atraso da replicação pode acontecer em alguns cenários, como:

A instância principal não pode enviar as alterações com rapidez suficiente para a réplica.
A réplica não recebe as alterações com rapidez suficiente.
A réplica não pode aplicar as alterações com rapidez suficiente.

Os dois primeiros motivos mencionados acima podem ser monitorados com a métrica network_lag. O terceiro é observado por meio da métrica replica_lag. replica_lag alto significa que a réplica não pode aplicar alterações de replicação com rapidez suficiente. O atraso total pode ser observado com a métrica replica_byte_lag, que tem rótulos para indicar mais detalhes. Essas métricas são descritas na seção Monitorar atraso da replicação abaixo.

Otimizar consultas e esquema

Nesta seção, sugerimos algumas otimizações comuns de consulta e esquema que podem ser feitas para melhorar o desempenho da replicação.

Consultas de longa duração na réplica de leitura

Consultas de longa duração na réplica podem bloquear a replicação para o Cloud SQL. Talvez você queira ter réplicas separadas para fins de processamento de transações on-line (OLTP, na sigla em inglês) e processamento analítico on-line (OLAP, na sigla em inglês) e enviar apenas consultas de longa duração para a réplica OLAP.

Considere ajustar as sinalizações max_standby_archive_delay e max_standby_streaming_delay para sua réplica.

Se você suspeitar que VACUUM é o culpado e o cancelamento da consulta não for aceitável, considere definir a sinalização hot_standby_feedback na réplica.

Consulte a documentação do PostgreSQL em espera ativa para mais informações.

Bloqueios exclusivos devido a DDL

Os comandos da linguagem de definição de dados (DDL), como ALTER TABLE e CREATE INDEX, podem causar atraso de replicação na réplica devido a bloqueios exclusivos. Para evitar a contenção de bloqueio, programe a execução do DDL quando a carga da consulta for menor nas réplicas.

Consulte a documentação do PostgreSQL em espera ativa para mais informações.

Réplica sobrecarregada

Se uma réplica de leitura estiver recebendo muitas consultas, a replicação poderá ser bloqueada. Divida as leituras entre várias réplicas para reduzir a carga em cada uma.

Para evitar picos de consulta, limite as consultas de leitura de réplica na lógica do aplicativo ou em uma camada de proxy, se usar uma.

Se houver picos de atividade na instância principal, considere distribuir as atualizações.

Banco de dados primário monolítico

Considere fragmentar o banco de dados primário verticalmente (ou horizontalmente) para impedir que uma ou mais tabelas atrasadas retenham todas as outras tabelas.

Monitorar atraso de replicação

Use as métricas replica_lag e network_lag para monitorar a atraso da replicação e identificar se a causa do atraso está no banco de dados principal, na rede ou na réplica.

Métrica Descrição

Métrica	Descrição
Atraso da replicação (`cloudsql.googleapis.com/database/replication/replica_lag`)	O número de segundos em que o estado da réplica está atrasado em relação ao estado da instância principal. Essa é a diferença entre o horário atual e o carimbo de data/hora original em que o banco de dados primário confirmou a transação que está sendo aplicada na réplica. Em particular, as gravações podem ser contadas com atraso, mesmo que tenham sido recebidas pela réplica, se a réplica ainda não tiver aplicado a gravação ao banco de dados. Essa métrica é calculada usando `now() - pg_last_xact_replay_timestamp()` na réplica. Isso é uma aproximação. Se a replicação estiver corrompida, a réplica não saberá o quão distante o banco de dados principal está e essa métrica não indicaria o atraso total.
Bytes de atraso (`cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag`)	A quantidade de bytes em que o estado da réplica está atrasado em relação ao estado do banco de dados principal. `replica_byte_lag` exporta quatro séries temporais, e o rótulo `replica_lag_type` pode indicar qualquer um dos seguintes itens: sent_location: indica quantos bytes do WAL foram gerados, mas ainda não foram enviados para a réplica. write_location: o atraso de gravação menos enviado mostra bytes WAL na rede que foram enviados, mas ainda não foram gravados na réplica. flush_location: o atraso na transferência menos o atraso na gravação mostra os bytes de WAL gravados na réplica, mas que ainda não foram transferidos para a réplica. replay_location: mostra o atraso total em bytes. O atraso da reprodução menos o atraso de transferência indica um atraso na repetição.
Atraso da rede (`cloudsql.googleapis.com/database/replication/network_lag`)	O tempo, em segundos, que leva da confirmação no banco de dados primário para alcançar o receptor do WAL na réplica. Se o `network_lag` for zero ou insignificante, mas o `replica_lag` for alto, isso indica que a linha de execução SQL não pode aplicar mudanças de replicação com rapidez suficiente.

Atraso da replicação
(cloudsql.googleapis.com/database/replication/replica_lag)

O número de segundos em que o estado da réplica está atrasado em relação ao estado da instância principal. Essa é a diferença entre o horário atual e o carimbo de data/hora original em que o banco de dados primário confirmou a transação que está sendo aplicada na réplica. Em particular, as gravações podem ser contadas com atraso, mesmo que tenham sido recebidas pela réplica, se a réplica ainda não tiver aplicado a gravação ao banco de dados.

Essa métrica é calculada usando now() - pg_last_xact_replay_timestamp() na réplica. Isso é uma aproximação. Se a replicação estiver corrompida, a réplica não saberá o quão distante o banco de dados principal está e essa métrica não indicaria o atraso total.

Bytes de atraso
(cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)

A quantidade de bytes em que o estado da réplica está atrasado em relação ao estado do banco de dados principal. replica_byte_lag exporta quatro séries temporais, e o rótulo replica_lag_type pode indicar qualquer um dos seguintes itens:

sent_location: indica quantos bytes do WAL foram gerados, mas ainda não foram enviados para a réplica.
write_location: o atraso de gravação menos enviado mostra bytes WAL na rede que foram enviados, mas ainda não foram gravados na réplica.
flush_location: o atraso na transferência menos o atraso na gravação mostra os bytes de WAL gravados na réplica, mas que ainda não foram transferidos para a réplica.
replay_location: mostra o atraso total em bytes. O atraso da reprodução menos o atraso de transferência indica um atraso na repetição.

Atraso da rede
(cloudsql.googleapis.com/database/replication/network_lag)

O tempo, em segundos, que leva da confirmação no banco de dados primário para alcançar o receptor do WAL na réplica.

Se o network_lag for zero ou insignificante, mas o replica_lag for alto, isso indica que a linha de execução SQL não pode aplicar mudanças de replicação com rapidez suficiente.

Verificar a replicação

Para verificar se a replicação está funcionando, execute a seguinte instrução na réplica:

select status, last_msg_receipt_time from pg_stat_wal_receiver;

Se a replicação estiver acontecendo, você verá o status streaming e um último last_msg_receipt_time:

postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
  status   |     last_msg_receipt_time
-----------+-------------------------------
 streaming | 2020-01-21 20:19:51.461535+00
(1 row)

Se a replicação não estiver acontecendo, um resultado vazio será retornado:

postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
 status | last_msg_receipt_time
--------+-----------------------
(0 rows)