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 cenários listados podem ser monitorados com a métrica network_lag. O terceiro é observado usando a 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 usando a métrica replica_byte_lag, que tem rótulos para indicar mais detalhes. Para mais informações sobre essas métricas, consulte Monitorar o atraso da replicação.

Verificar se a réplica está provisionada adequadamente

Uma instância de réplica menor que a instância principal (por exemplo, com menos vCPUs e memória) pode apresentar atraso de replicação. Uma réplica menor também pode ter flags de configuração padrão diferentes em comparação com uma instância principal maior. Recomendamos que a instância de 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 alta utilização da CPU na réplica também pode causar atraso de replicação. Se a utilização da CPU da réplica for alta (por exemplo, acima de 90%), considere aumentar a capacidade da CPU da réplica.

Use o comando SHOW ALL para conferir a configuração da réplica e da instância principal e compará-las para identificar diferenças.

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. Isso pode acontecer quando a replicação tenta aplicar mudanças (como de uma operação VACUUM) a linhas que estão sendo lidas por uma consulta na réplica.

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.

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

• Ajustar as flags de atraso de espera. As flags max_standby_archive_delay e max_standby_streaming_delay controlam quanto tempo uma réplica aguardará antes de cancelar consultas de espera que entrem em conflito com a replicação. Valores razoáveis geralmente ficam entre 30 e 60 segundos. Confira a pg_stat_database_conflicts visualização para insights sobre conflitos de consulta.
• Ativar a flag hot_standby_feedback. Definir a hot_standby_feedback flag como on na réplica pode ajudar a atrasar as operações de VACUUM na principal. No entanto, isso pode causar inchaço da tabela na principal, então é uma compensação.

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

Atraso de rede alto

O atraso de rede alto indica que os registros WAL não estão sendo enviados pela principal ou recebidos pela réplica com rapidez suficiente. Isso pode ser causado pelo seguinte:

• Replicação entre regiões. A replicação entre regiões diferentes pode introduzir maior latência de rede.
• Alta utilização da CPU principal. Se a CPU principal estiver acima de 90%, o processo do remetente WAL poderá não receber tempo de CPU suficiente. Considere reduzir a carga na principal ou aumentar a CPU.
• Alta utilização da CPU da réplica. Se a CPU da réplica estiver acima de 90%, o processo do receptor WAL poderá não receber tempo de CPU suficiente. Considere reduzir a carga na réplica ou aumentar a CPU.
• Problemas de largura de banda da rede ou gargalos de E/S de disco. Uma região mais próxima ou uma configuração de disco de maior capacidade pode ajudar. Considere modificar o valor da flag wal_compression na instância principal para ajudar a reduzir o tráfego entre regiões.

É possível monitorar o atraso de rede com a métrica cloudsql.googleapis.com/database/replication/network_lag. Essa métrica tem um limite máximo de 25 segundos, mesmo que o atraso real seja maior.

Observação: como network_lag é arredondado para o segundo mais próximo, um valor informado de 1 segundo pode representar um atraso subjacente de um ou dois milissegundos até um segundo inteiro.

Essa 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 indicados pelo rótulo replica_lag_type.

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 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
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 indicará 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 o receptor WAL não pode aplicar mudanças de replicação com rapidez suficiente. Como network_lag é arredondado para o segundo mais próximo, um valor informado de 1 segundo pode representar um atraso subjacente de um ou dois milissegundos até um segundo inteiro.

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)

Qual é a próxima etapa?

• Promover réplicas para migração regional ou recuperação de desastres