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 grupos de disponibilidade sempre ativados do SQL Server para replicação. As alterações são gravadas no registro de transações da instância principal. A instância principal encaminha transações para qualquer instância de réplica secundária, em que as alterações são aplicadas. O modo de disponibilidade usado é o modo de confirmação assíncrona.

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 network_lag metric. O terceiro é observado por meio da métrica seconds_behind_master. Uma métrica seconds_behind_master alta significa que a réplica não pode aplicar alterações de replicação com rapidez suficiente. 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.

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.

Além disso, as instruções DDL, como CREATE INDEX, ALTER INDEX e INDEX MAINTENANCE podem causar atraso de replicação devido ao grande número de registros de transações que essas instruções podem gerar.

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/seconds_behind_master)	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 carimbo de data/hora do último registro de registros refeito na secundária e o carimbo de data/hora do último log de registros enviado na principal.
Atraso da rede (cloudsql.googleapis.com/database/replication/network_lag)	A diferença entre o carimbo de data/hora da última entrada de registro recebida na réplica e a última entrada de registro enviada na principal.

Verificar a replicação

Para verificar se a replicação está funcionando, 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á íntegra.