Délai de réplication

Cette page explique comment résoudre les problèmes de délai avant réplication pour les instances dupliquées avec accès en lecture de Cloud SQL.

Présentation

Les instances dupliquées avec accès en lecture de Cloud SQL utilisent des groupes de disponibilité Always On SQL Server pour la réplication. Les modifications sont écrites dans le journal des transactions de l'instance principale. L'instance principale transfère les transactions à toutes les instances dupliquées secondaires sur lesquelles les modifications sont appliquées. Le mode de disponibilité utilisé est le mode de commit asynchrone.

Le délai avant réplication peut se produire dans plusieurs scénarios, par exemple :

  • L'instance principale ne peut pas envoyer les modifications suffisamment rapidement à l'instance dupliquée.
  • L'instance dupliquée ne peut pas recevoir les modifications suffisamment rapidement.
  • L'instance dupliquée ne peut pas appliquer les modifications suffisamment rapidement.
Vous pouvez surveiller les deux premières raisons mentionnées ci-dessus avec la métrique network_lag metric. La troisième est observée via la métrique seconds_behind_master. Une valeur seconds_behind_master élevée signifie que l'instance dupliquée ne peut pas appliquer les modifications de réplication suffisamment rapidement. Ces métriques sont décrites dans la section Surveiller le délai avant réplication ci-dessous.

Optimiser les requêtes et le schéma

Cette section fournit des suggestions d'optimisations courantes de requêtes et de schémas que vous pouvez appliquer pour améliorer les performances de réplication.

Requêtes de longue durée dans l'instance dupliquée avec accès en lecture

Les requêtes de longue durée effectuées dans l'instance dupliquée peuvent bloquer la réplication pour Cloud SQL. Vous pouvez souhaiter disposer d'instances dupliquées distinctes pour le traitement des transactions en ligne (OLTP) et le traitement analytique en ligne (OLAP), et n'envoyer que les requêtes de longue durée à l'instance dupliquée OLAP.

Verrous exclusifs en raison de LDD

Les commandes LDD (langage de définition de données), telles que ALTER TABLE et CREATE INDEX peuvent entraîner un délai avant réplication dans l'instance dupliquée en raison de verrous exclusifs. Pour éviter les conflits de verrouillage, envisagez de planifier l'exécution LDD pendant les périodes où la charge de la requête est inférieure sur les instances dupliquées.

En outre, les instructions LDD telles que CREATE INDEX, ALTER INDEX et INDEX MAINTENANCE peuvent allonger le délai de duplication en raison du grand nombre d'enregistrements de journaux de transactions pouvant être générés.

Instance dupliquée surchargée

Si une instance dupliquée avec accès en lecture reçoit trop de requêtes, la réplication peut être bloquée. Envisagez de répartir les lectures entre plusieurs instances dupliquées pour réduire la charge sur chacune d'entre elles.

Pour éviter les pics de requêtes, envisagez de limiter les requêtes de lecture des instances dupliquées dans votre logique d'application ou dans une couche de proxy, si vous en utilisez une.

En cas de pics d'activité sur l'instance principale, envisagez de répartir les mises à jour.

Base de données principale monolithique

Envisagez de segmenter la base de données principale verticalement (ou horizontalement) pour éviter qu'une ou plusieurs tables en retard ne retiennent toutes les autres tables.

Surveiller le délai avant réplication

Vous pouvez utiliser les métriques replica_lag et network_lag pour surveiller le délai avant réplication et déterminer si la cause de ce délai se trouve dans la base de données principale, le réseau ou l'instance dupliquée.

MétriqueDescription
Délai avant réplication
(cloudsql.googleapis.com/database/replication/seconds_behind_master)

Nombre de secondes de retard de l'état de l'instance dupliquée par rapport à l'état de l'instance principale. Il s'agit de la différence entre l'horodatage du dernier enregistrement de journal répété sur le serveur secondaire et l'horodatage du dernier enregistrement de journal envoyé sur le serveur principal.

Latence du réseau
(cloudsql.googleapis.com/database/replication/network_lag)

Différence entre l'horodatage de la dernière entrée de journal reçue sur l'instance dupliquée et la dernière entrée de journal envoyée sur l'instance principale.

Vérifier la réplication

Pour vérifier que la réplication fonctionne, vérifiez la valeur de la métrique cloudsql.googleapis.com/database/replication/state sur l'instance principale. Si l'état est Running, la réplication est opérationnelle.