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.
network_lag
.
Le troisième est observé via 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 temps de latence total peut être observé via la métrique replica_byte_lag
, qui possède des libellés pour indiquer plus de détails. 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.
Envisagez d'ajuster les indicateurs max_standby_archive_delay
et max_standby_streaming_delay
pour votre instance dupliquée.
Si vous pensez que le problème est lié à VACUUM et que l'annulation de la requête n'est pas acceptable, envisagez de définir l'option hot_standby_feedback
dans l'instance dupliquée.
Pour en savoir plus, consultez la documentation PostgreSQL sur les systèmes de secours à chaud.
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.
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étrique | Description |
---|---|
Délai avant réplication ( cloudsql.googleapis.com ) |
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 |
Octets de latence ( cloudsql.googleapis.com ) |
Quantité d'octets de retard de l'état de l'instance dupliquée par rapport à l'état de la base de données principale.
|
Latence du réseau ( cloudsql.googleapis.com ) |
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 |
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)