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 os grupos de disponibilidade AlwaysOn do SQL Server para a replicação. As alterações são escritas no registo de transações na instância principal. A instância principal encaminha as transações para quaisquer instâncias de réplica secundárias, onde as alterações são aplicadas. O modo de disponibilidade usado é o modo de confirmação assíncrono.

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 o network_lag metric. O terceiro motivo é observado através da métrica seconds_behind_master. Uma métrica seconds_behind_master elevada significa que a réplica não consegue aplicar as alterações de replicação com rapidez suficiente. 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.

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.

Além disso, as declarações DDL, como CREATE INDEX, ALTER INDEX e INDEX MAINTENANCE, podem causar um intervalo de tempo da replicação devido ao grande número de registos do registo de transações que estas declarações podem gerar.

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/seconds_behind_master)

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 data/hora do último registo de registo refeito no secundário e a data/hora do último registo de registo enviado no principal.
Atraso da rede
(cloudsql.googleapis.com/database/replication/network_lag)

A diferença entre a data/hora da última entrada de registo recebida na réplica e a data/hora da última entrada de registo enviada no servidor principal.

Valide a replicação

Para verificar se a replicação está a funcionar, verifique o valor da métrica cloudsql.googleapis.com/database/replication/state na instância principal. Se o estado for Running, a replicação está em bom estado.

O que se segue: