Como soluciono problemas de atraso na minha réplica de leitura do RDS para SQL Server?

Data da última atualização: 14/10/2022

Tenho uma instância do Amazon Relational Database Service (Amazon RDS) para Microsoft SQL Server com réplica de leitura. Estou vendo uma das seguintes opções na minha instância de banco de dados:

  • Há um aumento repentino no atraso da réplica.
  • A modificação da instância começou a causar atraso na réplica.
  • O banco de dados na instância de réplica de leitura não está acessível.

Como posso solucionar esses problemas?

Breve descrição

O Amazon RDS para SQL Server Enterprise Edition oferece suporte à criação de uma réplica de leitura na mesma região. A replicação de dados é assíncrona e usa a tecnologia Always-On para replicar dados de uma instância mestre para uma instância de réplica. O RDS para SQL Server não intervém para mitigar o alto atraso de réplica entre uma instância de banco de dados de origem e suas réplicas de leitura.

Resolução

1.    Verifique a utilização de recursos na instância mestre e na réplica usando o Amazon CloudWatch. Use os recursos Enhanced Monitoring e Performance Insights para verificar o uso de recursos em nível granular.

Considerações importantes sobre métricas nas instâncias mestre e de réplica:

2.    É uma prática recomendada criar as instâncias mestre e de réplica com a mesma classe de instância, tipo de armazenamento e número de IOPS. Isso evita o atraso da réplica devido à falta de recursos na instância de réplica. Além disso, dependendo da workload, a réplica de leitura pode ser ampliada ou reduzida se o uso for mínimo em comparação com a instância principal.

3.    Identifique o período em que o atraso da réplica começou a aumentar e faça o seguinte:

Verifique as métricas WriteIOPS, WriteThroughput, NetworkReceiveThroughput e NetworkTrasmitThroughput na instância principal com base na hora de início do atraso da réplica. Determine se o atraso é devido à atividade de gravação. Verifique as mesmas métricas no mesmo período na réplica de leitura.

Verifique se há transações de longa duração na instância principal. Veja a seguir um exemplo de consulta ao status de verificação de transações ativas:

SELECT * FROM sys.sysprocesses WHERE open_tran = 1;

4.    Na instância de réplica, verifique se há algum bloqueio ou impasse significativo. Impasses ocorrem entre as transações Select e DDL/DML e causam atrasos na aplicação dos registros de transações da instância principal.

Veja a seguir um exemplo de consulta para verificar se há bloqueios:

SELECT * FROM sys.sysprocesses WHERE blocked > 0;

5.    Consulta para verificar o atraso da réplica e o atraso máximo da réplica.

Atraso de réplica

SELECT AR.replica_server_name
     , DB_NAME (ARS.database_id) 'database_name'
     , AR.availability_mode_desc
     , ARS.synchronization_health_desc
     , ARS.last_hardened_lsn
     , ARS.last_redone_lsn
     , ARS.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states ARS
INNER JOIN sys.availability_replicas AR ON ARS.replica_id = AR.replica_id
--WHERE DB_NAME(ARS.database_id) = 'database_name'
ORDER BY AR.replica_server_name;

Verifique se o valor “last_hardened_lsn” está progredindo na réplica de leitura.

Atraso máximo de réplica

Para o SQL Server, a métrica ReplicaLag é o atraso máximo dos bancos de dados que ficaram para trás, em segundos. Por exemplo, se você tiver dois bancos de dados com atraso de 5 segundos e 10 segundos, respectivamente, o ReplicaLag será de 10 segundos. A métrica ReplicaLag retorna o valor da consulta a seguir. Execute a consulta na instância principal.

select max(secondary_lag_seconds) max_lag  from sys.dm_hadr_database_replica_states;

6.    Depois de iniciar a criação da réplica de leitura, um snapshot é retirado da instância mestre e restaurado para criar uma instância de réplica de leitura. Os logs de transações são reproduzidos para sincronizar os dados com a instância principal. No entanto, depois de criar uma nova instância, essa instância experimenta um carregamento lento, o que causa atraso na réplica. Esse é o comportamento esperado. Para minimizar o efeito do carregamento lento, use o armazenamento do tipo IO1 durante a criação da réplica de leitura e, em seguida, converta-o novamente em GP2, se necessário.

7.    Execute transações em lotes na instância principal. Isso evita a execução de transações longas e mantém o tamanho mínimo do arquivo de log de transações. Não reinicie a instância de réplica, a menos que seja necessário durante um alto atraso de réplica, pois isso atrasa ainda mais a reprodução dos registros de transações.

8.    A modificação da classe da instância na instância mestre ou na réplica pode causar atraso temporário na réplica. Esse comportamento é esperado porque os registros são processados a partir da instância principal.

Alterar o tipo ou o tamanho do armazenamento tem um impacto maior no atraso da réplica até que a otimização do armazenamento seja concluída. Não é possível descobrir quanta porcentagem da otimização do armazenamento é concluída nas instâncias do RDS.

9.    Se a réplica de leitura atingir o estado armazenamento cheio, os logs de transações da instância mestre não serão processados, e o atraso da réplica aumentará.

Se você suspeitar que o espaço de armazenamento é devido ao TempDB ou a tabelas temporárias, reinicie a instância de réplica para liberar espaço temporariamente.

10.    Se você não estiver experimentando nenhum progresso no status de atraso da réplica, verifique o status dos bancos de dados do usuário na instância de réplica. Para reproduzir os registros, o status do banco de dados deve ser Online.

Esteja ciente do seguinte:

  • Os bancos de dados recém-criados não são incluídos no cálculo do atraso até que estejam acessíveis na réplica de leitura.
  • O ReplicaLag retornará -1 se o RDS não conseguir determinar o atraso, como durante a configuração da réplica ou quando a réplica de leitura está no estado de erro.

Este artigo foi útil?


Precisa de ajuda com faturamento ou suporte técnico?