Atraso da replicação

Esta página descreve como resolver problemas e corrigir o atraso de replicação para 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 antecipação (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.

Certifique-se de que a réplica tem aprovisionamento adequado

Uma instância de réplica inferior à instância principal (por exemplo, com menos vCPUs e memória) pode sofrer um atraso na replicação. Uma réplica mais pequena também pode ter flags de configuração predefinidas diferentes em comparação com uma instância principal maior. Recomendamos que a instância da réplica seja, pelo menos, tão grande quanto a instância principal para ter recursos suficientes para processar a carga de replicação.

A utilização elevada da CPU na réplica também pode causar um atraso na replicação. Se a utilização da CPU da réplica for elevada (por exemplo, superior a 90%), pondere aumentar a capacidade da CPU da réplica.

Pode usar o comando SHOW ALL para ver a configuração da instância principal e da réplica, e compará-las para verificar se existem diferenças.

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. Isto pode acontecer quando a replicação está a tentar aplicar alterações (como uma operação VACUUM) a linhas que estão a ser lidas por uma consulta na réplica.

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.

Para ajudar a resolver atrasos ou bloqueios de replicação causados por transações de longa duração, recomendamos o seguinte:

  • Ajuste as flags de atraso em modo de espera. Os flags max_standby_archive_delay e max_standby_streaming_delay controlam o tempo que uma réplica aguarda antes de cancelar as consultas em espera que entram em conflito com a replicação. Os valores razoáveis situam-se frequentemente entre 30 e 60 segundos. Pode consultar a vista pg_stat_database_conflicts para ver estatísticas sobre conflitos de consultas.
  • Ative o sinalizador hot_standby_feedback. A definição da flag hot_standby_feedback para on na réplica pode ajudar a atrasar as operações de vácuo no primário. No entanto, isto pode causar um aumento excessivo da tabela no servidor principal, pelo que é uma troca.

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

Atraso elevado na rede

O elevado atraso da rede indica que os registos WAL não estão a ser enviados pela base de dados primária ou recebidos pela réplica com rapidez suficiente. Isto pode dever-se ao seguinte:

  • Replicação entre regiões. A replicação entre diferentes regiões pode introduzir uma latência de rede mais elevada.
  • Utilização elevada da CPU principal. Se a CPU do nó principal estiver acima de 90%, o processo de envio de WAL pode não ter tempo de CPU suficiente. Considere reduzir a carga no servidor principal ou aumentar a respetiva CPU.
  • Utilização elevada da CPU da réplica. Se a CPU da réplica for superior a 90%, o processo do recetor WAL pode não ter tempo de CPU suficiente. Pondere reduzir a carga na réplica ou aumentar a respetiva CPU.
  • Problemas de largura de banda da rede ou restrições de E/S de disco. Uma região mais próxima ou uma configuração de disco com maior débito podem ajudar. Considere modificar o valor da flag wal_compression na instância principal para ajudar a reduzir o tráfego entre regiões.
Pode monitorizar o atraso da rede com a métrica cloudsql.googleapis.com/database/replication/network_lag. Esta métrica tem um limite máximo de 25 segundos, mesmo que o atraso real seja superior.

Esta métrica network_lag é semelhante à métrica cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag, que mede o atraso sent_location em termos de bytes indicado pela respetiva etiqueta replica_lag_type.

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 nas réplicas seja inferior.

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 delas.

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 na 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 escrita 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 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)

A quantidade de 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 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: