Résoudre les problèmes de réplication

L'architecture d'AlloyDB sépare le calcul et le stockage, ce qui permet à chacun d'évoluer indépendamment. Bien que les instances du pool principal 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 l'actualisation des données sur 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 WAL. Ces modifications sont ensuite répliquées sur les nœuds du pool de lecture. Pour résoudre les problèmes, il est essentiel de comprendre les deux principales étapes de ce processus de réplication :

• Vidage du journal WAL : le journal WAL, qui contient les modifications apportées à la base de données, est envoyé de l'instance principale à l'instance répliquée. L'instance répliquée conserve alors immédiatement le WAL sur le disque.
• Application (ou relecture) du WAL : le WAL persistant est relu sur l'instance répliquée, ce qui signifie que les modifications sont appliquées aux caches de l'instance répliquée.

Les retards dans l'une de ces étapes contribuent à ce que l'on appelle le délai de réplication. Toutefois, ce terme peut être ambigu. Pour être plus précis, nous pouvons décomposer le délai de réplication en deux composants :

• Latence de vidage ou de 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.
• Retard de relecture : 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.

Le fait que vous deviez vous préoccuper davantage du délai de vidage ou du délai de relecture dépend de votre cas d'utilisation :

• Si vous craignez de perdre des données, par exemple avec des clusters secondaires, vous devez prêter une attention particulière au délai de vidage. Si le WAL n'est pas encore conservé sur l'instance répliquée et que l'instance principale plante, les modifications sont perdues du point de vue de l'instance répliquée.
• Si vous vous inquiétez de la fraîcheur des données sur vos instances dupliquées avec accès en lecture, vous devez prêter une attention particulière au délai de vidage et au délai de relecture. Un retard dans l'une ou l'autre de ces étapes (transmission du WAL ou application de celui-ci) entraîne l'obsolescence des données sur vos instances répliquées avec accès en lecture.

Vérifier le délai avant 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 des instances. Vous pouvez également surveiller le délai 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 avant réplication

Voici quelques causes courantes de latence de réplication et comment les résoudre.

Conflit de ressources

La réplication peut également être ralentie par des conflits d'accès aux 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 augmenter la capacité ou effectuer 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 pool 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 instances répliquées.

Conflits de réplication

Les requêtes de lecture peuvent parfois bloquer le processus de réplication, car elles conservent les ressources que le processus de réplication attend. Si une requête de lecture détient un verrou sur un objet de base de données que le processus de relecture doit mettre à jour, cela entraîne un conflit de verrouillage. Si une requête contient un code d'accès sur un tampon de données que la relecture doit modifier, cela entraîne un conflit de code d'accès au tampon. Dans les deux cas, la relecture est bloquée jusqu'à ce que la requête libère la ressource.

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 limiter les conflits de réplication, vous pouvez :

• max_standby_streaming_delay de réduction : ce paramètre détermine la durée pendant laquelle le processus de relecture attend avant d'annuler les requêtes qui le bloquent. La valeur par défaut est de 30 secondes. Réduire cette valeur peut aider à réduire le délai de réplication, mais cela peut également entraîner l'annulation d'un plus grand nombre de requêtes de 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 la probabilité 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.

• Vérifiez que alloydb.promote_cancel_to_terminate est actif : ce flag, activé par défaut, permet à AlloyDB de forcer l'arrêt des backends de requête qui ne répondent pas aux demandes d'annulation. Cela peut aider à empêcher les backends qui ne répondent pas de bloquer la réplication pendant de longues périodes.

Limitation des requêtes de lecture basée sur le décalage

AlloyDB vous permet également d'activer ou non la limitation basée sur le décalage des requêtes de lecture sur les nœuds de lecture à l'aide de l'option google_storage.log_replay_throttle_read_transactions. Si le paramètre est défini sur sa valeur par défaut on, les requêtes de lecture sont limitées en mettant en pause le démarrage de nouvelles requêtes et la lecture de nouveaux tampons pendant une minute maximum lorsque le délai de réplication dépasse une seconde. Cette fonctionnalité fait un compromis qui améliore le délai de réplication en donnant plus de ressources à la relecture pour rattraper le retard plus rapidement, au détriment d'une augmentation potentielle de la latence des requêtes de lecture. Si votre application n'est pas sensible au délai de réplication, vous pouvez donner la priorité à l'amélioration de la latence des requêtes de 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 moments où les requêtes sont retardées en raison d'un décalage de l'instance répliquée.

• Cloud Monitoring : utilisez la métrique alloydb.googleapis.com/instance/postgresql/wait_count pour voir combien de requêtes ont été limitées. Pour ce faire, filtrez la métrique par wait_event_name et recherchez HighLagThrottle. Pour afficher la durée totale de limitation des requêtes, 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 d'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élai de réplication. Pour en savoir plus, consultez Surveiller les requêtes actives.

Charge de travail importante

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 surcharger les instances du 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 .

Volume important de journaux WAL en raison de la compilation de l'index ScaNN

La création de l'index ScaNN peut générer de grandes quantités d'enregistrements WAL d'écriture de page complète. Cela peut entraîner un retard dans l'envoi des enregistrements WAL de votre instance principale vers les instances de lecture. Si le délai de réplication correspond à la création de l'index ScaNN sur un grand nombre d'embeddings, vous pouvez activer wal_compression sur l'instance principale pour économiser les E/S réseau et disque, et réduire le délai de réplication. Cela peut entraîner une légère augmentation de la charge de processeur.

wal_compression ne compresse que les enregistrements d'écriture de page complète et n'a aucun effet sur la plupart des enregistrements WAL. La modification de cette option ne nécessite pas de redémarrage et n'entraîne aucun temps d'arrêt.

Transactions importantes

Les transactions qui modifient un grand nombre de lignes (par exemple, en supprimant plusieurs tables ou des tables volumineuses) génèrent des enregistrements COMMIT ou ABORT exceptionnellement volumineux dans le journal WAL. La relecture de ces enregistrements sur les nœuds du pool de lecture peut prendre beaucoup de temps, ce qui entraîne une augmentation temporaire du délai de réplication.

Pour limiter ce problème, évitez d'effectuer des opérations par lot très volumineuses, telles que des suppressions, dans une seule transaction. Divisez plutôt ces opérations en transactions plus petites et plus fréquentes. Cela réduit la taille des enregistrements COMMIT et ABORT individuels, ce qui permet au flux de réplication de rester plus fluide et de réduire le délai de réplication maximal.

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

Pour qu'il y ait un délai de réplication, vous devez disposer d'un pool de lecture fonctionnel. Les problèmes suivants peuvent empêcher complètement la réplication, 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.

Plantages d'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 provoquer le plantage de l'instance du pool de lecture.

Pour résoudre 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 AlloyDB garantit que le délai de vidage du pool de lecture n'est pas affecté par le redimensionnement de l'instance. Cependant, ce n'est pas le cas pour la rediffusion. La capacité de l'instance répliquée à rejouer dépend de la charge qu'elle subit. Si vous mettez à jour la configuration de votre instance, par exemple en la redimensionnant, selon la charge de travail, il est possible que le cache de l'instance répliquée ne soit pas entièrement préchauffé une fois l'opération terminée. Cela signifie qu'il est plus lent de rejouer ou de traiter des enregistrements qu'il n'a pas encore mis en cache. Dans ce cas, cela peut signifier que le délai de relecture augmente temporairement.