Redis est un magasin de données en mémoire à valeur fondamentale connu pour sa flexibilité, ses performances, son vaste support linguistique et ses fonctions intégrées comme la réplication. La réplication est la pratique consistant à copier régulièrement des données d’une base de données à une autre afin d’avoir une réplique qui reste toujours une copie exacte de l’instance primaire. Une utilisation courante de la réplication de Redis consiste à migrer un magasin de données Redis existant vers un nouveau serveur, comme on peut le faire lorsqu’on augmente la taille de son infrastructure pour obtenir de meilleures performances.
Ce tutoriel décrit le processus d’utilisation des fonctions de réplication intégrées de Redis pour migrer des données d’un serveur Ubuntu 18.04 (la “source”) vers un autre (la “cible”). Cela implique d’apporter quelques modifications à la configuration de chaque serveur, de définir le serveur cible pour qu’il fonctionne comme une réplique de la source, puis de promouvoir la réplique en tant que primaire une fois la migration terminée.
Pour suivre ce tutoriel, vous aurez besoin de :
ufw
. Pour mettre en place cet environnement, suivez notre guide de configuration initiale des serveurs pour Ubuntu 18.04 pour les deux serveurs.Cette étape facultative consiste à charger votre instance de Redis source avec quelques échantillons de données, afin de pouvoir expérimenter la migration des données dans votre instance cible. Si vous avez déjà des données que vous voulez migrer vers votre cible, vous pouvez passer à l’Étape 2 qui vous indiquera comment procéder.
Pour commencer, connectez-vous au serveur Ubuntu que vous utiliserez comme instance Redis source, en tant que votre utilisateur non root :
- ssh sammy@source_server_ip
Exécutez ensuite la commande suivante pour accéder à votre serveur Redis :
- redis-cli
Si vous avez configuré votre serveur Redis pour exiger une authentification par mot de passe, exécutez la commande auth
suivie de votre mot de passe Redis :
- auth source_redis_password
Ensuite, exécutez les commandes suivantes. Celles-ci créeront un certain nombre de clés contenant quelques chaînes, un hachage, une liste et un ensemble :
- mset string1 "Redis" string2 "is" string3 "fun!"
- hmset hash1 field1 "Redis" field2 "is" field3 "fast!"
- rpush list1 "Redis" "is" "feature-rich!"
- sadd set1 "Redis" "is" "free!"
En outre, exécutez les commandes expire
suivantes pour donner un délai d’attente à certaines de ces clés. Cela les rendra volatiles, ce qui signifie que Redis les supprimera après un laps de temps déterminé (7500
secondes dans ce cas) :
- expire string2 7500
- expire hash1 7500
- expire set1 7500
Avec cela, vous disposez de quelques exemples de données que vous pouvez exporter vers votre instance Redis cible. Gardez l’invite redis-cli
ouverte pour l’instant, puisque nous allons exécuter quelques commandes supplémentaires à l’étape suivante pour sauvegarder ces données.
Chaque fois que vous envisagez de transférer des données d’un serveur à un autre, il y a un risque que quelque chose tourne mal et vous pourriez perdre des données en conséquence. Même si ce risque est faible, nous utiliserons la commande bgsave
de Redis pour créer une sauvegarde de votre base de données source Redis au cas où vous rencontreriez une erreur lors du processus de réplication.
Si vous ne l’avez pas encore ouvert, commencez par ouvrir l’interface de ligne de commande Redis :
- redis-cli
Si vous avez configuré votre serveur Redis pour exiger une authentification par mot de passe, exécutez la commande auth
suivie de votre mot de passe Redis :
- auth password
Ensuite, exécutez la commande bgsave
. Cela permettra de créer un instantané de votre ensemble de données actuel et de l’exporter vers un fichier dump se trouvant dans le répertoire de travail de Redis :
- bgsave
Remarque : vous pouvez prendre un instantané de votre base de données Redis avec les commandes save
ou bgsave
. La raison pour laquelle nous utilisons la commande bgsave
ici, cependant, est que la commande save
fonctionne de manière synchrone, ce qui signifie qu’elle bloquera tout autre client connecté à la base de données. Pour cette raison, la documentation de la commande save
recommande de ne presque jamais l’exécuter dans un environnement de production.
Au lieu de cela, elle suggère d’utiliser la commande bgsave
qui fonctionne de manière asynchrone. Cela amènera Redis à diviser la base de données en deux processus : le processus parent continuera à servir les clients tandis que l’enfant enregistrera la base de données avant de quitter :
Notez que si les clients ajoutent ou modifient des données pendant que l’opération bgsave
est en cours d’exécution, ces modifications ne seront pas prises en compte dans l’instantané.
Après cela, vous pouvez fermer la connexion à votre instance Redis en exécutant la commande exit
.
- exit
Si vous en avez besoin à l’avenir, vous pouvez trouver le fichier dump de données dans le répertoire de travail de votre instance Redis. Rappelez-vous : dans le tutoriel prérequis d’installation de Redis, vous avez configuré votre instance de Redis pour utiliser /var/lib/redis
comme répertoire de travail.
Listez le contenu de votre répertoire de travail Redis pour confirmer qu’il contient le fichier dump des données :
- sudo ls /var/lib/redis
Si le fichier dump a été exporté correctement, vous le verrez dans la sortie de cette commande. Par défaut, ce fichier est nommé dump.rdb
: :
Outputdump.rdb
Après avoir confirmé que vos données ont été sauvegardées correctement, vous êtes prêt à configurer votre serveur Redis source pour accepter les connexions externes et autoriser la réplication.
Par défaut, Redis n’est pas configuré pour écouter les connexions externes, ce qui signifie que les répliques que vous configurez ne pourront pas se synchroniser avec votre instance source, à moins que vous ne mettiez à jour sa configuration. Ici, nous allons mettre à jour le fichier de configuration de l’instance source pour permettre les connexions externes et également définir un mot de passe que l’instance cible utilisera pour s’authentifier une fois la réplication commencée. Après cela, nous ajouterons une règle de pare-feu pour autoriser les connexions au port sur lequel Redis fonctionne.
Ouvrez le fichier de configuration de votre instance Redis source avec votre éditeur de texte préféré. Ici, nous utiliserons nano
:
- sudo nano /etc/redis/redis.conf
Naviguez vers la ligne qui commence par la directive bind
. Par défaut, cela ressemblera à ceci :
. . .
bind 127.0.0.1
. . .
Cette directive lie Redis à 127.0.0.1
, une adresse de loopback IPv4 qui représente le localhost
. Cela signifie que cette instance Redis est configurée pour n’écouter que les connexions qui proviennent du même serveur que celui où elle est installée. Pour autoriser votre instance source à accepter toute connexion effectuée à son adresse IP publique, par exemple celle faite à partir de votre instance cible, ajoutez l’adresse IP de votre serveur Redis source après le 127.0.0.1
. Notez que vous ne devez inclure aucune virgule après 127.0.0.1
:
. . .
bind 127.0.0.1 source_server_IP
. . .
Ensuite, si vous ne l’avez pas encore fait, utilisez la directive requirepass
pour configurer un mot de passe que les utilisateurs doivent entrer avant de pouvoir interagir avec les données sur l’instance source. Pour ce faire, il convient de décommenter la directive et de lui attribuer un mot de passe ou une phrase de passe complexe :
. . .
requirepass source_redis_password
. . .
Veillez à noter le mot de passe que vous avez défini ici, car vous en aurez besoin lorsque vous configurez le serveur cible.
Après ce changement, vous pouvez enregistrer et fermer le fichier de configuration Redis. Si vous l’avez édité avec nano
, faites-le en appuyant sur CTRL+X
, Y
, puis ENTER
.
Ensuite, redémarrez le service Redis pour mettre ces modifications en œuvre :
- sudo systemctl restart redis
C’est tout ce que vous devez faire en termes de configuration de Redis, mais si vous avez configuré un pare-feu sur votre serveur, il continuera à bloquer toute tentative de connexion de votre serveur cible avec la source. En supposant que vous avez configuré votre pare-feu avec ufw
, vous pourriez le mettre à jour pour autoriser les connexions au port sur lequel Redis fonctionne avec la commande suivante. Notez que Redis est configuré pour utiliser le port 6379
par défaut :
- sudo ufw allow 6379
Une fois ce dernier changement apporté, vous avez terminé de configurer votre serveur Redis source. Continuez à configurer votre instance Redis cible pour qu’elle fonctionne comme une réplique de la source.
À ce stade, vous avez configuré votre instance Redis source pour qu’elle accepte les connexions externes. Cependant, comme vous avez bloqué l’accès à la source en décommentant la directive requirepass
, votre instance cible ne pourra pas reproduire les données contenues dans la source. Ici, vous allez configurer votre instance Redis cible pour qu’elle puisse authentifier sa connexion à la source, permettant ainsi la réplication.
Commencez par vous connecter à votre serveur Redis cible en tant qu’utilisateur non root :
- ssh sammy@target_server_ip
Ensuite, ouvrez le fichier de configuration Redis de votre serveur cible :
- sudo nano /etc/redis/redis.conf
Si vous ne l’avez pas encore fait, vous devez configurer un mot de passe pour votre instance Redis cible avec la directive requirepass
:
. . .
requirepass target_redis_password
. . .
Ensuite, décommentez la directive masterauth
et attribuez-lui le mot de passe d’authentification de votre instance Redis source. Ce faisant, votre serveur cible sera en mesure de s’authentifier auprès de l’instance source une fois que vous aurez activé la réplication :
. . .
masterauth source_redis_password
. . .
Enfin, si vos clients écrivent des informations à votre instance source, vous voudrez les configurer pour qu’ils écrivent également des données à votre instance cible. De cette façon, si un client écrit des données une fois que vous avez redonné à la cible son statut d’instance primaire, elles ne seront pas perdues.
Pour ce faire, cependant, vous devrez ajuster la directive replica-read-only
. La valeur par défaut est yes
, ce qui signifie qu’elle est configurée pour devenir une réplique " en lecture seule " sur laquelle les clients ne pourront pas écrire. Définissez cette directive sur no
pour autoriser les clients à y écrire :
. . .
replica-read-only no
. . .
Ce sont là toutes les modifications que vous devez apporter au fichier de configuration de la cible, vous pouvez donc l’enregistrer et le fermer.
Ensuite, redémarrez le service Redis pour mettre ces modifications en œuvre :
- sudo systemctl restart redis
Après avoir redémarré le service Redis, votre serveur cible sera prêt à devenir une réplique de la source. Tout ce que vous devrez faire pour cela, c’est exécuter une seule commande, ce que nous allons faire sous peu.
Remarque : si certains clients écrivent des données sur votre instance Redis source, c’est le moment de les configurer pour qu’ils écrivent également des données sur votre cible.
À ce stade, vous avez configuré votre instance Redis source pour qu’elle accepte les connexions de votre serveur cible et vous avez configuré votre instance Redis cible pour qu’elle puisse s’authentifier à la source en tant que réplique. Une fois ces pièces en place, vous êtes prêt à transformer votre instance cible en une réplique de la source.
Commencez par ouvrir l’interface de ligne de commande Redis sur votre serveur Redis cible :
- redis-cli
Exécutez la commande auth
pour authentifier la connexion :
- auth password
Ensuite, transformez l’instance cible en une réplique de la source avec la commande replicaof
Veillez à remplacer source_server_ip
par l’adresse IP publique de votre instance source et source_port
par le port utilisé par Redis sur votre instance source :
- replicaof source_server_ip source_port
À partir de l’invite, exécutez la commande scan
suivante. Cela va retourner toutes les clés actuellement détenues par la réplique :
- scan 0
Si la réplication fonctionne comme prévu, vous verrez toutes les clés de votre instance source détenues dans la réplique. Si vous avez chargé votre source avec les données de l’échantillon à l’Étape 1, la sortie de la commande scan
ressemblera à ceci :
Output1) "0"
2) 1) "string3"
2) "string1"
3) "set1"
4) "string2"
5) "hash1"
6) "list1"
Remarque : il faut savoir que cette commande peut retourner les clés dans un ordre différent de celui qui est indiqué dans cet exemple.
Cependant, si cette commande ne renvoie pas les mêmes clés que celles de votre instance Redis source, il se peut qu’une erreur dans les fichiers de configuration d’un de vos serveurs empêche la base de données cible de se connecter à la source. Dans ce cas, fermez la connexion à votre instance Redis cible, et vérifiez que vous avez correctement édité les fichiers de configuration sur vos serveurs Redis source et cible.
Tant que la connexion est ouverte, vous pouvez également confirmer que les clés que vous avez définies pour expire sont toujours volatiles. Pour ce faire, exécutez la commande ttl
avec une de ces clés comme argument :
- ttl hash1
Cela va retourner le nombre de secondes avant que cette clé ne soit supprimée :
Output5430
Une fois que vous avez confirmé que les données de votre instance source ont été correctement synchronisées avec votre cible, vous pouvez faire en sorte que la cible redevienne une instance primaire en exécutant une nouvelle fois la commande replicof
. Cette fois, cependant, au lieu de suivre replicaof
avec une adresse IP et un port, suivez-la avec no one
. L’instance cible cessera alors immédiatement de se synchroniser avec la source :
- replicaof no one
Pour confirmer que les données reproduites à partir de la source persistent sur la cible, exécutez à nouveau la commande scan
que vous avez saisie précédemment :
scan 0
Vous devriez voir les mêmes clés dans la sortie de cette commande que lorsque vous avez exécuté la commande scan
pendant que la cible répliquait encore la source :
Output1) "0"
2) 1) "string3"
2) "string1"
3) "set1"
4) "string2"
5) "hash1"
6) "list1"
Vous avez ainsi réussi à migrer toutes les données de votre instance Redis source vers votre cible. Si vous avez des clients qui écrivent encore des données sur l’instance source, c’est le moment de les configurer pour qu’ils n’écrivent que sur la cible.
Outre la réplication, il existe plusieurs méthodes que vous pouvez utiliser pour migrer des données d’une instance Redis à une autre, mais la réplication présente l’avantage de nécessiter relativement peu de changements de configuration pour fonctionner et une seule commande pour la lancer ou l’arrêter.
Si vous souhaitez en savoir plus sur le travail avec Redis, nous vous encourageons à consulter notre série tutoriel sur Comment gérer une base de données Redis. Par ailleurs, si vous souhaitez transférer vos données Redis vers une instance Redis gérée par DigitalOcean, suivez notre guide sur la façon de procéder.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!