Délai avant 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 la réplication par flux PostgreSQL. Les modifications sont écrites dans le journal de transaction dans l'instance principale. L'émetteur WAL envoie l'enregistrement WAL au destinataire WAL dans l'instance dupliquée, où ils sont appliqués.

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.
Les deux premiers scénarios listés peuvent être surveillés à l'aide de la métrique network_lag. Le troisième est observé à l'aide de la métrique replica_lag. Une valeur replica_lag élevée signifie que l'instance dupliquée ne peut pas appliquer les modifications de réplication suffisamment rapidement. Le délai total peut être observé à l'aide de la métrique replica_byte_lag, qui comporte des libellés indiquant des informations supplémentaires. Pour en savoir plus sur ces métriques, consultez Surveiller le délai avant réplication.

S'assurer que l'instance dupliquée est correctement provisionnée

Une instance dupliquée plus petite que l'instance principale (par exemple, avec moins de processeurs virtuels et de mémoire) peut subir un délai avant réplication. Une instance dupliquée plus petite peut également avoir des indicateurs de configuration par défaut différents de ceux d'une instance principale plus grande. Nous vous recommandons que l'instance dupliquée soit au moins aussi grande que l'instance principale pour disposer de suffisamment de ressources pour gérer la charge de réplication.

Une utilisation élevée du processeur sur l'instance dupliquée peut également entraîner un délai avant réplication. Si l'utilisation du processeur de l'instance dupliquée est élevée (par exemple, supérieure à 90%), envisagez d'augmenter la capacité du processeur de l'instance dupliquée.

Vous pouvez utiliser la commande SHOW ALL pour afficher la configuration de l'instance dupliquée et de l'instance principale, et les comparer pour identifier les différences.

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. Cela peut se produire lorsque la réplication tente d'appliquer des modifications (comme celles d'une opération VACUUM) à des lignes lues par une requête sur l'instance dupliquée.

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.

Pour résoudre les problèmes de délai ou de blocage de la réplication causés par des transactions de longue durée, nous vous recommandons de procéder comme suit :

  • Ajustez les indicateurs de délai d'attente. Les indicateurs max_standby_archive_delay et max_standby_streaming_delay contrôlent la durée pendant laquelle une instance dupliquée attend avant d'annuler les requêtes en attente qui sont en conflit avec la réplication. Les valeurs raisonnables se situent souvent entre 30 et 60 secondes. Vous pouvez consulter la pg_stat_database_conflicts vue pour obtenir des informations sur les conflits de requêtes.
  • Activez l'indicateur hot_standby_feedback. Définir l'indicateur hot_standby_feedback sur on dans l'instance dupliquée peut aider à retarder les opérations de nettoyage sur l'instance principale. Toutefois, cela peut entraîner un gonflement de la table sur l'instance principale. Il s'agit donc d'un compromis.

Pour en savoir plus, consultez la documentation PostgreSQL.

Latence réseau élevée

Une latence réseau élevée indique que les enregistrements WAL ne sont pas envoyés par l'instance principale ou reçus par l'instance dupliquée assez rapidement. Cela peut être dû aux causes suivantes :

  • Réplication interrégionale. La réplication entre différentes régions peut entraîner une latence réseau plus élevée.
  • Utilisation élevée du processeur principal. Si le processeur principal est supérieur à 90%, le processus d'envoi WAL peut ne pas disposer de suffisamment de temps CPU. Envisagez de réduire la charge sur l'instance principale ou d'augmenter son processeur.
  • Utilisation élevée du processeur de l'instance dupliquée. Si le processeur de l'instance dupliquée est supérieur à 90%, le processus de réception WAL peut ne pas disposer de suffisamment de temps CPU. Envisagez de réduire la charge sur l'instance dupliquée ou d'augmenter son processeur.
  • Problèmes de bande passante réseau ou goulots d'étranglement des E/S du disque. Une région plus proche ou une configuration de disque à débit plus élevé peuvent être utiles. Envisagez de modifier la valeur de l'indicateur wal_compression dans l'instance principale pour réduire le trafic interrégional.
Vous pouvez surveiller la latence réseau à l'aide de la métrique cloudsql.googleapis.com/database/replication/network_lag. Cette métrique a une limite maximale de 25 secondes, même si la latence réelle est plus élevée.

Cette métrique network_lag est semblable à la métrique cloudsql.googleapis.com/database/postgresql/replication/replica_byte_lag, qui mesure la latence sent_location en termes d'octets indiqués par son libellé replica_lag_type.

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.

Pour en savoir plus, consultez la documentation PostgreSQL.

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

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'heure actuelle et l'horodatage d'origine auquel la base de données principale a validé la transaction actuellement appliquée sur l'instance dupliquée. En particulier, les écritures peuvent être considérées comme retardées même si elles ont été reçues par l'instance dupliquée, si celle-ci n'a pas encore appliqué l'écriture à la base de données.

Cette métrique est calculée à l'aide de now() - pg_last_xact_replay_timestamp() dans l'instance dupliquée. Il s'agit d'une approximation. Si la réplication est interrompue, l'instance dupliquée ne sait pas où se situe la base de données principale et cette métrique n'indique pas le délai total de latence.
Octets de latence
(cloudsql.googleapis.com/database/postgres/replication/replica_byte_lag)

Quantité d'octets de retard de l'état de l'instance dupliquée par rapport à l'état de la base de données principale. replica_byte_lag exporte quatre séries temporelles et le libellé replica_lag_type peut indiquer l'un des éléments suivants :

  • sent_location : indique le nombre d'octets WAL générés, mais qui n'ont pas encore été envoyés à l'instance dupliquée.
  • write_location : la latence d'écriture moins envoyée affiche les octets WAL dans le réseau qui ont été envoyés, mais pas encore écrits dans l'instance dupliquée.
  • flush_location : le vidage de l'écriture moins le nombre d'octets WAL écrits dans l'instance dupliquée s'affiche, mais pas encore vidé dans l'instance dupliquée.
  • replay_location : affiche le décalage total en octets. Le délai de répétition des vidages indique un délai de répétition.
Latence du réseau
(cloudsql.googleapis.com/database/replication/network_lag)

Durée, en secondes, nécessaire après le commit dans la base de données principale pour atteindre le récepteur WAL dans l'instance dupliquée.

Si la valeur de network_lag est nulle ou négligeable, mais que la valeur replica_lag est élevée, cela indique que le récepteur WAL n'est pas en mesure d'appliquer les modifications de réplication assez rapidement.

Étant donné que network_lag est arrondi à la seconde la plus proche, une valeur signalée de 1 seconde peut représenter une latence sous-jacente allant d'une milliseconde ou deux à une seconde complète.

Vérifier la réplication

Pour vérifier que la réplication fonctionne, exécutez l'instruction suivante sur l'instance dupliquée :

  select status, last_msg_receipt_time from pg_stat_wal_receiver;

Si la réplication se produit, l'état streaming s'affiche, ainsi qu'un message "ast_msg_receipt_time" récent :

  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)

Si la réplication n'a pas lieu, un résultat vide est renvoyé:

  postgres=> select status, last_msg_receipt_time from pg_stat_wal_receiver;
  status | last_msg_receipt_time
  --------+-----------------------
  (0 rows)

Étapes suivantes