Le tampon de réplication – Comment éviter les maux de tête Devops

Le tampon de réplication – Comment éviter les maux de tête Devops

devop headaches art

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.

La limite du tampon de réplication

Les tampons de réplication sont des tampons de mémoire qui conservent les données pendant qu’un serveur Redis esclave se synchronise avec le serveur maître. Dans une synchronisation maître-esclave complète, les modifications apportées aux données pendant la phase initiale de la synchronisation sont conservées dans le tampon de réplication par le serveur maître. Après l’achèvement de la phase initiale, le contenu du tampon est envoyé à l’esclave. Il y a une limite à la taille du tampon qui peut être utilisé dans cette procédure, provoquant le démarrage de la réplication depuis le début lorsque le maximum est atteint, comme mentionné dans notre article sur boucles de réplication Redis sans fin. Afin d’éviter que cela ne se produise, une configuration initiale du tampon doit avoir lieu en fonction de la quantité et des types de modifications attendues au cours du processus de réplication. Par exemple, un faible volume de changements et/ou des données plus petites dans les changements peuvent se débrouiller avec un tampon plus petit, alors que s’il y a beaucoup de changements et/ou que les changements sont importants, un grand tampon est nécessaire. Une solution plus complète consiste à régler les tampons à un niveau très élevé pour compenser la possibilité d’un processus de réplication long ou lourd qui finira par épuiser le tampon (si celui-ci est trop petit). En fin de compte, cette solution nécessite un réglage fin de la base de données spécifique à portée de main.

Paramètre par défaut de Redis :

> config get client-output-buffer-limit
1) "client-output-buffer-limit"
2) "normal 1073741824 536870912 30 slave 268435456 67108864 60 pubsub 33554432 8388608 60"

Comme expliqué ici, ce lien de réplication de configuration par défaut sera rompu (entraînant le démarrage de la synchronisation depuis le début) une fois que la limite stricte de 256 Mo est atteinte, ou si une limite souple de 67 Mo est atteinte et maintenue pendant 60 secondes continues. Dans de nombreux cas, en particulier avec une charge “d’écriture” élevée et une bande passante insuffisante vers le serveur esclave, le processus de réplication ne se terminera jamais. Cela peut conduire à une situation de boucle infinie où le maître Redis est constamment en train de bifurquer et de prendre un instantané de l’ensemble de données sur le disque, ce qui peut tripler la quantité de mémoire supplémentaire à utiliser avec un taux élevé d’opérations d’E/S. De plus, cette situation de boucle infinie fait que l’esclave ne peut jamais rattraper son retard et se synchroniser complètement avec le serveur maître Redis.

Une solution simple qui offre une amélioration immédiate résulte de l’augmentation de la taille du tampon esclave de sortie en définissant les limites matérielles et logicielles à 512 Mo :

> config set client-output-buffer-limit "slave 536870912 536870912 0"

Comme pour de nombreuses reconfigurations, il est important de comprendre que :

  1. Avant d’augmenter la taille des buffers de réplication vous devez vous assurer que vous disposez de suffisamment de mémoire sur votre machine.
  2. Le calcul de l’utilisation de la mémoire Redis ne tient pas compte de la taille du tampon de réplication.

Cela nous amène à la fin de notre premier épisode des principaux maux de tête opérationnels de Redis. Comme indiqué ci-dessus, en termes de limites de tampon de réplication, une configuration appropriée peut aller très loin. Assurez-vous de garder un œil sur le prochain article de cette compilation traitant des délais de réplication et de la manière de les gérer en conséquence.

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 *