Atraso da replicação

Esta página descreve como resolver problemas e corrigir o atraso na replicação de réplicas de leitura do Cloud SQL.

Vista geral

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

O atraso na replicação pode ocorrer em alguns cenários, como:

  • A instância principal não consegue enviar as alterações com rapidez suficiente para a réplica.
  • A réplica não consegue receber as alterações com rapidez suficiente.
  • A réplica não consegue aplicar as alterações com rapidez suficiente.
Os dois primeiros motivos acima podem ser monitorizados com a métrica network_lag. A terceira é observada através da métrica replica_lag. Alto replica_lag significa que a réplica não consegue aplicar as alterações de replicação com rapidez suficiente. O atraso total pode ser observado através da métrica replica_byte_lag, que tem etiquetas para indicar mais detalhes. Estas métricas são descritas na secção Monitorize o atraso da replicação abaixo.

Otimize as consultas e o esquema

Esta secção sugere algumas otimizações comuns de consultas e esquemas que pode fazer para melhorar o desempenho da replicação.

Consultas de execução prolongada na réplica de leitura

As consultas de execução prolongada na réplica podem bloquear a replicação para o Cloud SQL. Pode querer ter réplicas separadas para fins de processamento de transações online (OLTP) e processamento analítico online (OLAP) e enviar apenas consultas de execução prolongada para a réplica OLAP.

Pondere ajustar os indicadores max_standby_archive_delay e max_standby_streaming_delay para a sua réplica.

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

Reveja a documentação do PostgreSQL para mais informações.

Bloqueios exclusivos devido a DDL

Os comandos de linguagem de definição de dados (LDD), como ALTER TABLE e CREATE INDEX, podem causar um intervalo de tempo de replicação na réplica devido a bloqueios exclusivos. Para evitar a contenção de bloqueios, considere agendar a execução de DDL durante períodos em que a carga de consultas seja inferior nas réplicas.

Reveja a documentação do PostgreSQL para mais informações.

Réplica sobrecarregada

Se uma réplica de leitura estiver a receber demasiadas consultas, a replicação pode ser bloqueada. Considere dividir as leituras entre várias réplicas para reduzir a carga em cada uma.

Para evitar picos de consultas, pondere limitar as consultas de leitura de réplicas na lógica da aplicação ou numa camada de proxy, se usar uma.

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

Base de dados principal monolítica

Pondere dividir a base de dados principal verticalmente (ou horizontalmente) para evitar que uma ou mais tabelas com atraso impeçam o processamento de todas as outras tabelas.

Monitorize o atraso da replicação

Pode usar as métricas replica_lag e network_lag para monitorizar o atraso na replicação e identificar se a causa do atraso está na base de dados principal, na rede ou na réplica.

MétricaDescrição
Atraso na replicação
(cloudsql.googleapis.com/database/replication/replica_lag)

O número de segundos que o estado da réplica está atrasado em relação ao estado da instância principal. Esta é a diferença entre a hora atual e a data/hora original em que a base de dados principal confirmou a transação que está a ser aplicada na réplica. Em particular, as escritas podem ser contabilizadas como atrasadas, mesmo que tenham sido recebidas pela réplica, se a réplica ainda não tiver aplicado a escrita à base de dados.

Esta métrica é calculada com base no now() - pg_last_xact_replay_timestamp() na réplica. Isto é uma aproximação. Se a replicação estiver interrompida, a réplica não sabe o quão avançada está a base de dados principal e esta métrica não indica 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 da base de dados principal. replica_byte_lag exporta 4 intervalos temporais e a etiqueta replica_lag_type pode indicar qualquer uma das seguintes opções:

  • sent_location: indica quantos bytes de WAL foram gerados, mas ainda não foram enviados para a réplica.
  • write_location: o atraso de envio de gravação mostra bytes WAL na rede que foram enviados, mas ainda não foram escritos na réplica.
  • flush_location: o atraso de gravação de descarga menos mostra os bytes WAL escritos na réplica, mas ainda não descarregados na réplica.
  • replay_location: mostra o atraso total em bytes. A repetição menos o atraso de descarga indica o atraso da repetição.
Atraso da rede
(cloudsql.googleapis.com/database/replication/network_lag)

O tempo, em segundos, que decorre desde a confirmação na base de dados principal até chegar ao recetor WAL na réplica.

Se o valor de network_lag for zero ou insignificante, mas o valor de replica_lag for elevado, indica que o recetor de WAL não consegue aplicar as alterações de replicação com rapidez suficiente.

Valide a replicação

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

  select status, last_msg_receipt_time from pg_stat_wal_receiver;

Se a replicação estiver a ocorrer, vê o estado streaming e um last_msg_receipt_time recente:

  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 a ocorrer, é devolvido um resultado vazio:

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

O que se segue: