Principaux maux de tête Redis pour Devops – Délais de réplication

Principaux maux de tête Redis pour Devops – Délais de réplication

Redis fournit une grande variété d’outils destinés à améliorer et à maintenir une utilisation efficace des bases de données en mémoire. Alors que ses types de données et ses commandes uniques permettent d’affiner les bases de données pour répondre aux demandes des applications sans aucun traitement supplémentaire au niveau de l’application, une configuration incorrecte, ou plutôt l’utilisation d’une configuration prête à l’emploi, peut entraîner (et entraîne) des défis opérationnels et des performances. problèmes. Malgré les déboires qui ont été la cause de pas mal de maux de tête, des solutions existent, et peut-être même plus simples que prévu. Cette série d’articles mettra en évidence certains des problèmes les plus irritants qui surviennent lors de l’utilisation de Redis, ainsi que des conseils sur la façon de les résoudre. Ils sont basés sur notre expérience réelle de l’exécution de milliers d’instances de base de données Redis.

Suite à notre précédent épisode de la série, le tampon de réplication, le prochain casse-tête sur notre liste continuera avec le sujet de la réplication maître-esclave. Nous allons notamment nous intéresser un peu plus à la durée nécessaire à la réalisation du processus ainsi qu’à certains problèmes de configuration pouvant occasionner des désagréments majeurs.

Délais de réplication

Comme nous en avons discuté précédemment dans le Article sur la boucle de réplication sans fin, le processus de réplication de Redis est composé de deux étapes de synchronisation : initiale et continue. Alors que la phase en cours est assez stable (tant que le lien entre le maître et l’esclave est conservé), la phase initiale est un peu plus délicate à réaliser. La réussite de la synchronisation initiale dépend non seulement de la quantité de mémoire allouée au tampon de réplication (voir mal de tête précédent) mais aussi du temps que prend cette étape.

Rappelons que l’étape de synchronisation initiale consiste en une sauvegarde en arrière-plan et la transmission de l’intégralité de la base de données du maître vers l’esclave. En fonction de la taille de l’ensemble de données et de la qualité de la connexion réseau, cela peut s’avérer long à réaliser. Si cette phase prend trop de temps, le paramètre de délai de réplication de Redis peut être atteint, ce qui entraîne la répétition incessante de la phase initiale, jusqu’à la nausée. Dans de tels cas, vous trouverez le journal Redis de votre esclave truffé de messages tels que :

[28618] 21 Jul 00:33:36.031 * Connecting to MASTER 10.60.228.106:25994
[28618] 21 Jul 00:33:36.032 * MASTER <-> SLAVE sync started
[28618] 21 Jul 00:33:36.032 * Non blocking connect for SYNC fired the event.
[28618] 21 Jul 00:33:36.032 * Master replied to PING, replication can continue...
[28618] 21 Jul 00:33:36.032 * Partial resynchronization not possible (no cached master)
[28618] 21 Jul 00:33:36.032 * Full resync from master: 549907b03661629665eb90846ea921f23de6c961:2537453

Le délai de réplication de Redis est défini sur 60 secondes par défaut (voir la directive repl-timeout dans votre fichier redis.conf ou faire un config get repl-timeout en utilisant redis-cli). Cette période de temps peut être beaucoup trop courte, surtout lorsque vous avez :

  • Stockage lent : si le maître et/ou l’esclave sont attachés à un stockage lent, le processus d’enregistrement en arrière-plan prendra beaucoup de temps dans le cas du maître. Dans le cas de l’esclave, l’écriture et le chargement des données depuis le disque peuvent être prolongés.

  • Grand jeu de données : plus la taille de l’ensemble de données est grande, plus il faudra de temps pour l’enregistrer et le transférer.

  • Performances réseau : lorsque la liaison réseau entre le maître et l’esclave a une bande passante limitée et/ou une latence élevée, cela affecte directement le taux de transfert de données.

Vous pouvez remédier à cela en définissant le délai de réplication sur une valeur plus appropriée. Commencez par travailler sur une estimation acceptable du temps nécessaire pour répliquer la base de données. Tout d’abord, vérifiez combien de temps il faut à Redis pour effectuer une sauvegarde en arrière-plan en exécutant le BGSAVE commande et en examinant le fichier journal pour les lignes pertinentes (c’est-à-dire * L’enregistrement en arrière-plan a commencé par le pid nnn * indique que le processus a commencé, alors que * L’enregistrement en arrière-plan s’est terminé avec succès * indique sa fin). Ensuite, chronométrez le temps qu’il vous faut pour copier le fichier RDB résultant du maître sur le disque de l’esclave. Enfin, vous devrez chronométrer le temps qu’il faut pour charger réellement les données à partir du disque (par exemple en redémarrant Redis et en recherchant le * DB chargé à partir du disque ligne dans le fichier journal). La somme de ces mesures peut servir d’estimation approximative de la valeur de délai d’attente de réplication souhaitée, mais vous voudrez probablement y ajouter 10 à 20 % pour des raisons de sécurité.

Une fois que vous avez configuré le délai d’attente en fonction de l’estimation, vous pouvez tester la durée réelle de la réplication en demandant à l’esclave d’effectuer une synchronisation complète plusieurs fois et en examinant le fichier journal. Si possible, essayez de répéter cet exercice à différents moments de la journée pour mieux évaluer le comportement du système sous différentes charges. Enfin, gardez à l’esprit que la valeur du paramètre de délai d’attente doit être revue périodiquement en fonction de la croissance de votre base de données.

Ceci conclut notre examen des maux de tête de réplication de Redis. La réplication est un outil puissant pour garder votre base de données disponible et mettre à l’échelle son débit de lecture, mais faites attention aux paramètres par défaut et assurez-vous que vous avez configuré la base de données en fonction de votre cas d’utilisation.

Si vous avez fini de lire cet article et que vous souhaitez vous plonger dans la prochaine cause commune des maux de tête de Devops, continuez à lire sur les tampons clients.

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *