Résoudre les problèmes de réplication

AlloyDB dispose d'une architecture qui sépare le calcul et le stockage, ce qui permet à chacun d'évoluer indépendamment. Bien que les instances principales et du pool de lecture partagent le même stockage sous-jacent, la réplication reste un processus crucial pour maintenir la cohérence et la fraîcheur des données dans les instances répliquées avec accès en lecture. Dans un cluster AlloyDB, les écritures sont effectuées sur l'instance principale, puis enregistrées dans le journal de transaction sur le stockage partagé. Ces modifications sont ensuite répliquées dans les caches en mémoire des instances du pool de lecture. Pour résoudre les problèmes, il est essentiel de comprendre les deux étapes principales de ce processus de réplication :

  • Vidage WAL : le journal WAL (Write-Ahead Log), qui contient les modifications apportées à la base de données, est envoyé de l'instance principale à l'instance répliquée. La réplique persiste ensuite immédiatement le WAL sur le disque. Les retards dans l'une ou l'autre de ces étapes contribuent à ce que l'on appelle le délai de réplication. Toutefois, ce terme peut être ambigu. Plus précisément, nous pouvons décomposer le décalage de réplication en deux composantes :

  • Latence de vidage ou du réseau : il s'agit du délai de l'étape de vidage du fichier WAL. Il s'agit du temps nécessaire pour que le WAL soit envoyé depuis l'instance principale et conservé sur l'instance répliquée.

  • Latence de réplication : il s'agit du délai de l'étape d'application des WAL. Il s'agit du temps nécessaire à l'instance répliquée pour appliquer les modifications du WAL.

Selon votre cas d'utilisation, vous devez vous préoccuper davantage du décalage de vidage ou du décalage de relecture :

  • Si vous craignez de perdre des données (par exemple, avec des répliques multirégionales), vous devez porter une attention particulière au décalage de vidage. Si le WAL n'est pas encore conservé sur la réplique et que le serveur principal plante, les modifications sont perdues du point de vue de la réplique.
  • Si vous vous inquiétez de la fraîcheur des données sur vos répliques en lecture, vous devez porter une attention particulière au décalage de réplication. Un décalage de réplication élevé signifie que les données de vos répliques en lecture sont obsolètes.

Déterminer la latence de réplication

Vous pouvez surveiller le délai de réplication de vos instances de pool de lecture dans la console Google Cloud . Pour en savoir plus, consultez Surveiller les instances. Vous pouvez également surveiller le décalage de réplication de votre pool de lecture et recevoir des alertes à un seuil spécifié à l'aide de la procédure décrite dans Créer des règles d'alerte basées sur un seuil de métrique.

Causes courantes du délai de réplication

Voici quelques causes courantes du délai de réplication et comment les résoudre.

Conflit de ressources

La réplication peut également être ralentie par la contention des ressources système, telles que le processeur et la mémoire.

  • Pression sur le processeur et la mémoire : une charge de travail de lecture importante sur une instance de pool de lecture peut entrer en concurrence avec le processus de réplication pour les ressources de processeur et de mémoire. Vous pouvez vérifier l'utilisation du processeur et de la mémoire de vos instances dans la console Google Cloud . Si vous constatez une utilisation élevée des ressources, vous devrez peut-être effectuer un scaling à la hausse ou un scaling horizontal de vos instances de pool de lecture.
  • Taille des nœuds du pool de lecture : si votre instance principale est beaucoup plus grande que vos nœuds de lecture, elle peut générer des journaux de réplication plus rapidement que les nœuds de lecture ne peuvent les traiter. Dans ce cas, il est recommandé d'utiliser des nœuds de lecture de plus grande taille pour donner plus de ressources aux répliques.

Conflits de réplication

Les requêtes de lecture peuvent parfois bloquer le processus de réplication, car elles conservent des ressources que le processus de réplication attend. Par exemple, si une requête en lecture verrouille un objet de base de données que le processus de réplication doit mettre à jour, la réplication est bloquée jusqu'à ce que le verrou soit levé. Il s'agit de conflits de broches de tampon.

Vous pouvez identifier ces conflits en recherchant les messages canceling statement due to conflict with recovery dans le fichier postgres.log de l'explorateur de journaux.

Pour atténuer les conflits de réplication, vous pouvez effectuer les opérations suivantes :

  • Réduire max_standby_streaming_delay : ce paramètre détermine la durée pendant laquelle le processus de réplication attend avant d'annuler les requêtes qui le bloquent. La valeur par défaut est de 30 secondes. La réduction de cette valeur peut contribuer à réduire le décalage de réplication, mais peut également entraîner l'annulation d'un plus grand nombre de requêtes en lecture. Vous pouvez ajuster ce paramètre pour trouver le meilleur équilibre pour votre application.

  • Évitez les requêtes de longue durée : les requêtes de longue durée sur les pools de lecture peuvent augmenter le risque de conflits de réplication. Envisagez de déplacer les requêtes de longue durée vers un autre pool de lecture où un faible délai de réplication n'est pas aussi critique.

  • Activer alloydb.promote_cancel_to_terminate : ce signalement, activé par défaut, permet à AlloyDB de mettre fin de force aux backends de requête qui ne répondent pas aux demandes d'annulation. Cela peut aider à empêcher les backends non réactifs de bloquer la réplication pendant de longues périodes.

Limitation temporaire des requêtes de lecture

AlloyDB vous permet également de contrôler si vous souhaitez activer la limitation basée sur le décalage d'une requête de lecture sur les nœuds de lecture à l'aide de l'indicateur google_storage.log_replay_throttle_read_transactions. Si le paramètre est défini sur sa valeur par défaut de on, les requêtes de lecture sont limitées en suspendant le lancement de nouvelles requêtes et la lecture de nouveaux tampons pendant une minute maximum lorsque le décalage de réplication dépasse une seconde. Cette fonctionnalité fait un compromis qui améliore le décalage de réplication en donnant plus de ressources à la réplication pour rattraper son retard plus rapidement, au risque d'augmenter la latence de lecture. Si votre application n'est pas sensible au décalage de réplication, vous pouvez améliorer la latence des requêtes en lecture en définissant google_storage.log_replay_throttle_read_transactions sur off.

Vous pouvez surveiller l'impact de la limitation des requêtes à l'aide des méthodes suivantes :

  • Journaux : recherchez les messages Delayed.*due to replica lag dans le fichier postgres.log de l'explorateur de journaux pour identifier les requêtes retardées en raison du décalage des répliques.

  • Cloud Monitoring : utilisez la métrique alloydb.googleapis.com/instance/postgresql/wait_count pour voir le nombre de requêtes limitées. Pour ce faire, filtrez la métrique par wait_event_name et recherchez HighLagThrottle. Pour connaître la durée totale pendant laquelle les requêtes ont été limitées, vous pouvez utiliser la métrique alloydb.googleapis.com/instance/postgresql/wait_time avec le même filtre. Pour en savoir plus, consultez la documentation de référence sur les métriques des insights système.

  • Insights sur les requêtes : dans le tableau de bord Insights sur les requêtes, la vue Requêtes actives affiche l'événement d'attente HighLagThrottle dans la colonne Événement d'attente lorsqu'une requête est limitée en raison d'un décalage de réplication. Pour en savoir plus, consultez Surveiller les requêtes actives.

Charge de travail élevée

Une augmentation soudaine de la charge de travail d'écriture sur l'instance principale peut générer une grande quantité de journaux de réplication, ce qui peut submerger les instances de pool de lecture et entraîner un délai avant réplication. Vous pouvez surveiller le trafic d'écriture sur votre instance principale dans la console Google Cloud .

Transactions importantes

Les transactions volumineuses, telles que les enregistrements COMMIT ou ABORT qui affectent un grand nombre de lignes, peuvent prendre beaucoup de temps à répliquer sur les instances du pool de lecture. Dans PostgreSQL 14, une transaction de longue durée qui contient une longue liste de verrous exclusifs peut entraîner une augmentation de l'utilisation de la mémoire de l'instance répliquée en lecture, ce qui peut finir par entraîner le plantage de l'instance du pool de lecture.

Pour atténuer ce problème, vous pouvez mettre fin à la transaction de longue durée sur l'instance principale.

Résoudre les problèmes qui empêchent la réplication

Avant de pouvoir avoir un décalage de réplication, vous devez disposer d'un pool de lecture fonctionnel. Les problèmes suivants peuvent empêcher la réplication de se produire, soit en empêchant la création d'un pool de lecture, soit en provoquant le plantage d'une instance répliquée avec accès en lecture.

Problèmes de création de pools de lecture

Si un pool de lecture ne peut pas être créé, un message Failed to create read pool peut s'afficher dans les journaux AlloyDB sur Cloud Logging. Cela peut se produire si le cluster a atteint sa limite de stockage maximale, ce qui empêche l'instance principale d'allouer plus d'espace. Bien qu'AlloyDB ajuste automatiquement l'espace de stockage, vous devrez peut-être identifier ce qui consomme de l'espace de stockage et supprimer les données inutiles, ou contacter l'assistance pour demander une augmentation de votre quota de stockage.

Plantages des instances de pool de lecture

Dans PostgreSQL 14, une transaction de longue durée sur l'instance principale qui contient une longue liste de verrous exclusifs peut entraîner une augmentation de l'utilisation de la mémoire d'une instance répliquée avec accès en lecture, ce qui peut finir par entraîner le plantage de l'instance de pool de lecture.

Pour atténuer ce problème, vous pouvez mettre fin à la transaction de longue durée sur l'instance principale.

Impact du redimensionnement d'une instance sur le délai de réplication

L'architecture de stockage d'AlloyDB garantit que le décalage de vidage du pool de lecture n'est pas affecté par le redimensionnement des instances. Toutefois, il n'en va pas de même pour la rediffusion. La capacité de la réplique à rejouer dépend de sa charge. Si vous mettez à jour la configuration de votre instance, par exemple en la redimensionnant, il est possible que le cache de la réplique ne soit pas entièrement préchauffé à la fin de l'opération, en fonction de la charge de travail. Cela signifie qu'il est plus lent de relire ou de traiter les enregistrements qu'il n'a pas encore mis en cache. Dans ce cas, cela peut signifier que le décalage de la rediffusion augmente temporairement.