Comprendre le backlog de réplication Redis : PSYNC, taille et limites de haute disponibilité

Le Arriéré de réplication Redis détermine notamment si, après une interruption de connexion, une réplique ne récupère que les modifications manquantes ou si elle reçoit à nouveau l'intégralité des données. En dimensionnant la mémoire tampon en fonction du volume réel de réplication, il est possible d’éviter des synchronisations complètes inutiles. Pour cela, l’historique de réplication, le budget de stockage et les processus opérationnels doivent toutefois être cohérents : un important arriéré ne remplace ni la persistance ni un concept de basculement robuste.

Ce que le backlog stocke réellement

À l'adresse suivante : Réplication Redis Le serveur principal traite les modifications apportées à la base de données et transmet un flux continu de commandes à ses répliques. Cela ne concerne pas uniquement les valeurs écrites directement par les clients. Les clés expirées ou supplantées peuvent également déclencher des modifications qui doivent être transmises. Le backlog conserve en mémoire une partie récente et limitée de ce flux de réplication. Il ne contient donc pas de copie complète supplémentaire de la base de données et ne constitue pas non plus une archive des opérations d'écriture, quelle que soit leur ancienneté.

En fonctionnement normal, les répliques suivent le flux de données en cours. Si une connexion est interrompue, l'historique continue de s'enrichir sur le serveur principal. Une fois la connexion rétablie, la réplique tente de se synchroniser à partir de son état précédent. Il est alors essentiel de savoir si les octets nécessaires sont encore conservés. Si tel est le cas et que l'historique de réplication correspond, Redis peut combler le vide. Les données déjà présentes sur la réplique n'ont pas besoin d'être entièrement remplacées pour cela.

Son intérêt réside notamment dans les cas de brèves perturbations du réseau, de changements de connexion et d'opérations de maintenance planifiées. Une synchronisation complète d'un volumineux ensemble de données mobilise de la capacité de transmission et de la puissance de calcul ; selon la configuration, cela s'accompagne de charges supplémentaires sur la mémoire et les supports de données. Le backlog peut réduire cet effort, mais il ne peut pas compenser toutes les formes d’interruption. Un redémarrage de processus ou une modification de l’historique nécessite une approche différente de celle d’une connexion TCP brièvement interrompue.

Quand PSYNC suffit-il et quand une resynchronisation complète est-elle nécessaire ?

A Resynchronisation partielle avec PSYNC nécessite deux informations liées : l'ID de réplication et l'offset. L'ID identifie un historique de données spécifique. L'offset décrit une position en octets au sein du flux de réplication. Deux décalages de même taille provenant d’historiques différents ne sont donc pas automatiquement comparables. À l’inverse, un léger retard au sein d’un même historique peut déjà se situer en dehors du backlog disponible si la capacité de ce dernier est limitée.

En termes simples, lors de la reconnexion, la réplique indique jusqu'à quel point elle est parvenue. Le serveur principal vérifie s'il est en mesure de fournir les données nécessaires par la suite. Si l'historique est inconnu ou s'il manque la partie requise, un Resynchronisation complète nécessaire. La réplique reçoit alors l'intégralité de la base de données, puis les modifications survenues pendant la synchronisation. Selon la configuration, le transfert peut s'effectuer avec une étape intermédiaire RDB sur un support de données ou sans cette étape intermédiaire.

Après un basculement, une resynchronisation complète n'est pas inévitable dans tous les cas. Une réplique transférée peut en outre mémoriser l'ID de réplication précédent et sa plage de décalage valide. Cela permet à d'autres répliques de se raccorder à l'historique connu si les conditions requises sont réunies. Cela n'offre toutefois aucune garantie pour la planification : la plage concernée doit rester disponible, et la reconnexion effective doit correspondre aux ID enregistrés.

Mesurer le taux de réplication plutôt que d'estimer la taille de la base de données

La taille même de la base de données suffit à Dimensionnement du carnet de commandes pas. Une grande base de données, principalement en lecture, peut générer peu de trafic de réplication. En revanche, un petit cache dont les valeurs changent fréquemment et qui génère de nombreux événements d’expiration peut transférer en continu des volumes de données considérables. Même un nombre fixe d’opérations par seconde ne suffit pas à décrire la mémoire nécessaire : de petites modifications de clés et d’importants écrasements de valeurs n’entraînent pas le même volume d’octets.

Une approximation pratique découle de l'augmentation au fil du temps de master_repl_offset. Enregistre la valeur deux fois sur le même serveur principal et divise la différence par le nombre de secondes écoulées. Vérifie également l'ID de réplication. Après un changement de rôle ou un redémarrage, tu ne dois pas simplement soustraire deux points de mesure non apparentés l'un de l'autre. De plus, un seul intervalle de mesure ne fournit qu'un taux moyen au sein de cet intervalle, et non une limite supérieure garantie en permanence.

La requête suivante permet de lire des informations de diagnostic. Elle ne modifie en rien la configuration de Redis. Exécute-la en spécifiant les options de connexion et d'authentification requises dans ton environnement. L'appel présenté ci-dessous utilise la connexion par défaut de redis-cli; il faut configurer explicitement un autre serveur, port ou accès TLS.

redis-cli INFO replication

Effectuez des mesures sur différentes phases de charge, par exemple lors des activités quotidiennes normales, lors des importations et pendant les renouvellements importants du cache. Consignez aussi bien les débits habituels que les pics de courte durée. Si de nombreuses modifications surviennent en raison de clés arrivant à expiration, l'article interne constitue une source d'approfondissement sur ce sujet. Analyser l'expiration des clés Redis. Ce lien est important pour la planification, car toutes les impulsions d'écriture pertinentes ne découlent pas nécessairement directement d'une nouvelle requête utilisateur.

Calculer de manière transparente le volume du carnet de commandes

Comme approximation de planification tu peux multiplier le taux de réplication pertinent par la durée de l'interruption à pallier, puis ajouter une marge de sécurité justifiée. La durée ne doit pas seulement tenir compte de l'interruption de réseau proprement dite. La détection, les tentatives de reconnexion et le rétablissement de la liaison peuvent également prendre du temps. La réserve appropriée dépend des fluctuations observées et de l'objectif opérationnel souhaité, et non d'un pourcentage universel.

Prenons un exemple de calcul volontairement simplifié : pour une phase de charge donnée, tu prévois 12 MiB par seconde. La connexion pourrait être interrompue pendant 90 secondes ; 30 secondes supplémentaires sont prévues à titre de réserve. Il en résulte donc 12 MiB/s × 120 s = 1.440 MiB, soit environ 1,41 GiB. Ces chiffres sont des estimations fournies à titre d'illustration et ne constituent pas un benchmark Redis. Avant toute mise en production, ils doivent être remplacés par les mesures réelles de votre application.

Le calcul inverse permet de situer un tampon existant. Un backlog entièrement rempli de 256 Mio correspond, à un débit constant de 12 Mio par seconde, à environ 21 secondes d'historique. À un débit de 2 Mio par seconde, cela représenterait environ 128 secondes. Dans une application réelle, cependant, les débits varient. Une telle autonomie ne constitue donc qu’un instantané et ne garantit pas que toute perturbation de cette durée puisse être partiellement synchronisée.

Vérifie également si, une fois reconnectée, la réplique parvient à rattraper son retard plus rapidement que les nouvelles modifications ne sont effectuées. Augmenter l'historique ne résout ni un réseau chroniquement trop lent, ni un destinataire chroniquement surchargé. Si le retard persiste ou continue de s'accumuler, il faut en rechercher la cause. Sinon, prévoir toujours plus de mémoire ne fait que repousser le problème et peut mettre l'ensemble du système sous pression en termes de mémoire.

Modifier la configuration de Redis de manière claire et contrôlée

Les paramètres repl-backlog-size et repl-backlog-ttl contrôlent des éléments différents. Le premier décrit la taille prévue du backlog. Le second détermine, sur le serveur principal, après combien de temps sans répliques connectées le backlog peut être libéré. Il est pas de durée maximale d'interruption pour PSYNC. Tant que la mémoire tampon est écrasée ou qu'une autre condition préalable n'est pas remplie, un TTL long ne suffit pas à lui seul.

Les lignes suivantes sont extraites du modèle de configuration de Redis 7.2.0 sous forme de paramètres commentés. Les caractères de commentaire ont été conservés intentionnellement. Le simple fait de copier ces lignes n'active aucun paramètre ; par ailleurs, les valeurs indiquées ne constituent pas une recommandation générale en matière de capacité pour les systèmes en production.

# Redis 7.2.0: auskommentierte Vorgaben aus redis.conf
# repl-backlog-size 1mb
# repl-backlog-ttl 3600

Avec repl-backlog-ttl 0 la validation temporisée est désactivée une fois toutes les répliques déconnectées. Cela ne permet pas de conserver un historique illimité : la mémoire tampon existante peut toujours être écrasée par de nouvelles données de réplication. De même, cela n'assure pas la persistance au-delà de redémarrages éventuels du processus. Évaluez donc soigneusement si la consommation de mémoire supplémentaire correspond au comportement de reconnexion attendu.

Avant d'effectuer une modification, tu dois vérifier les valeurs effectivement en vigueur et clarifier la procédure de déploiement. Une variable d'environnement de conteneur, un fichier de configuration géré et un paramètre modifié lors de l'exécution ne sont pas la même chose. Si une instance est recréée ultérieurement, seules les modifications effectuées lors de l'exécution risquent d'être perdues. Les requêtes suivantes sont en lecture seule ; elles nécessitent néanmoins des droits d'accès appropriés.

redis-cli CONFIG GET repl-backlog-size
redis-cli CONFIG GET repl-backlog-ttl

Avec Managed Redis, le fournisseur peut restreindre l'accès à CONFIG limiter ou gérer les paramètres via une interface dédiée. Ce n’est pas une raison pour contourner les mécanismes de protection. Utilise alors les canaux d’administration autorisés et documente la taille choisie ainsi que le volume de réplication sous-jacent. Le plan de modification doit également mentionner les valeurs actuelles et prévoir un retour en arrière réaliste.

Suivi : quelles valeurs vont de pair ?

Pour la Surveillance de la réplication Redis Un simple indicateur vert de l'état de la connexion n'est pas suffisant. Une connexion peut être rétablie alors que la réplique est encore en train de rattraper son retard ou de charger un ensemble complet de données. À l'inverse, une brève interruption de connexion n'est pas nécessairement critique si l'historique et la capacité de rattrapage sont suffisants. Évaluez donc conjointement la connexion, l'état de synchronisation, l'évolution du décalage et l'historique disponible.

Les champs d'une INFOLes réponses peuvent varier selon les versions de Redis et entre le serveur principal et les répliques. Une analyse doit donc traiter explicitement les champs manquants, au lieu de les interpréter tacitement comme étant nuls ou comme indiquant un état correct. De même, les désignations master et slave continuent d'apparaître dans les noms de champs pour des raisons de compatibilité ; ils ne doivent pas être librement traduits dans le code exécutable.

Pour l'interprétation du retard, il convient de se référer au guide interne Analyser l'offset de réplication Redis un complément pertinent. Dans le cadre du suivi continu, tu dois tenir compte des tendances historiques, et pas seulement de deux chiffres relevés manuellement. Un écart qui se creuse exige une réaction différente de celle requise par un écart qui ne cesse de se réduire après une brève interruption.

Des alertes pertinentes s'alignent sur vos objectifs opérationnels : pendant combien de temps une réplique peut-elle rester inaccessible ? À quelle vitesse doit-elle rattraper son retard ? Quelle fréquence de synchronisations complètes est considérée comme inhabituelle ? Des seuils rigides, sans prise en compte du profil de charge et du volume de données, entraînent souvent des alertes inutiles ou ne permettent pas de détecter de véritables dégradations. Outre les indicateurs de réplication, surveillez également l'utilisation de la mémoire vive (RAM), la charge réseau et les indications de redémarrages de processus.

Bien évaluer le budget de stockage et les répliques lentes

Le carnet de commandes ne représente qu'une partie de l'ensemble Besoins en mémoire de Redis. À cela s'ajoutent les données stockées, les structures administratives, les tampons client et, selon l'état de fonctionnement, de la mémoire supplémentaire pendant les opérations de persistance ou de synchronisation. Ne prévoyez donc pas la totalité de la mémoire vive disponible pour les données utiles et le backlog calculé avec précision. La réserve nécessaire doit être déterminée en fonction de l’environnement concret et des pics de charge qui y surviennent.

Depuis Redis 7.0, le tampon de réplication et la file d'attente de réplication partagent la même mémoire. La documentation INFO précise donc, entre autres, que mem_clients_slaves peut être nul si les tampons de réplication ne dépassent pas la capacité du backlog. Cela ne signifie pas pour autant que la réplication ne consomme pas de mémoire. Considérez les valeurs prévues à cet effet, telles que mem_replication_backlog et mem_total_replication_buffers en tenant compte du contexte et sans additionner aveuglément les grandeurs qui se recoupent.

Une erreur de diagnostic courante consiste à considérer que toute synchronisation interrompue est due à un retard important. La lenteur des répliques, une bande passante réseau limitée ou le dépassement des limites du tampon de sortie peuvent avoir d'autres causes. Le paramètre client-output-buffer-limit replica concerne la classe de client en question et ne doit pas être confondue avec repl-backlog-size être considérées comme équivalentes. Avant de modifier les limites, consultez les journaux, la documentation relative aux versions et évaluez les répercussions prévisibles sur les autres connexions.

Pourquoi un important carnet de commandes ne garantit pas pour autant une haute disponibilité

Le backlog améliore la reconnexion, mais ne rend pas la réplication, asynchrone par défaut, exempte de pertes. Un serveur principal peut avoir déjà confirmé une opération d’écriture au client avant qu’un serveur répliqué ne l’ait traitée. Si le serveur principal tombe en panne pendant ce laps de temps, l’opération en question risque de ne pas être présente sur le système de secours sélectionné ultérieurement. La taille de la mémoire tampon à elle seule ne résout pas ce Risque de perte de données en cas de basculement pas.

Voir aussi WAIT ne transforme pas une topologie Redis en un système garantissant une forte cohérence. La commande peut attendre les confirmations des répliques ; la sécurité effective des données continue de dépendre d'autres facteurs, notamment du comportement en matière de persistance et de basculement. De même, min-replicas-to-write et min-replicas-max-lag d'accepter, selon leurs conditions respectives, de nouvelles opérations d'écriture, sans sauvegarder automatiquement et de manière permanente chaque opération sur plusieurs instances.

Pour Haute disponibilité Vous devez donc prendre une décision globale : perte de données tolérée, temps d'indisponibilité admissible, persistance, détection des dysfonctionnements, sélection du nouveau serveur principal et restauration. Sentinel ou Redis Cluster peuvent prendre en charge d’autres tâches que le backlog. Se contenter d’augmenter la taille d’un tampon tout en laissant toutes les autres hypothèses inchangées ne suffit pas pour disposer d’un plan de reprise fiable.

Tester les modifications et identifier les problèmes récurrents

Lancez un test contrôlé dans un environnement isolé, avec une version comparable de Redis et une charge d'écriture reproductible. Avant l'interruption, notez les ID de réplication, les décalages, l'occupation du backlog et la consommation de mémoire. Simule ensuite une interruption de connexion limitée, sans modifier les pare-feu ou les processus de production sans les avoir préalablement testés. Une fois la connexion rétablie, observe si une synchronisation partielle ou complète a lieu et combien de temps dure le rattrapage.

Dans la mesure du possible, ne modifiez qu'un seul paramètre pertinent par essai. Si le backlog, la charge d'écriture et les conditions réseau varient simultanément, il est difficile d'attribuer l'effet à un facteur précis. Répétez l'essai avec des durées d'interruption différentes et des phases de charge variées. Ainsi, une simple reconnexion réussie permet d'obtenir une évaluation fiable du comportement. Les limites observées doivent être documentées, sans pour autant en déduire une garantie pour toute perturbation future.

En cas de resyncs complètes répétées, vérifie d'abord si l'historique est compatible. Viennent ensuite les octets encore présents, la durée sans réplique, les indications de redémarrages et la vitesse réelle de rattrapage. Une mémoire tampon trop petite est une cause possible, mais ce n’est pas la seule. Il est particulièrement important de faire la distinction entre un écart ponctuel trop long et une réplique qui accuse un retard permanent, même lorsque la connexion est établie.

Au final, le bon réglage est celui qui couvre la fenêtre de défaillance que vous avez définie avec une charge réaliste, tout en laissant suffisamment de mémoire pour le reste du fonctionnement. Consignez ensemble la base de mesure, la source de configuration et la date de vérification. Après des modifications importantes apportées au comportement d'écriture, à la topologie ou à la version de Redis, le dimensionnement doit être réexaminé. Ainsi, le backlog reste une décision opérationnelle fondée plutôt qu'un chiffre adopté une fois pour toutes.