TOC

Comment migrer des données Redis avec la réplication maître-esclave sur Ubuntu 14.04

introduction

Redis est un cache en mémoire, NoSQL, une mémoire clé-valeur et un magasin qui peuvent également être conservés sur le disque. Sa popularité ne cesse de croître et il est utilisé comme magasin de données dans les grands et les petits projets. Pour diverses raisons, telles que la transition vers un serveur plus puissant, il devient parfois nécessaire de migrer ces données d’un serveur à un autre.

Bien qu’il soit possible de copier simplement les fichiers de la base de données du serveur actuel sur le nouveau, la méthode recommandée pour migrer une base de données Redis consiste à utiliser une configuration de réplication de manière maître-esclave. Une telle configuration est beaucoup plus rapide que la copie de fichiers et implique très peu de temps d’arrêt, voire aucun.

Cet article montrera comment migrer les données Redis d’un serveur Ubuntu 14.04 vers un serveur similaire à l’aide de la réplication maître-esclave. Cela implique la configuration d’un nouveau serveur Redis, en le configurant pour être l’esclave du serveur actuel (c.-à-d. maître), puis promotion de l’esclave en maître une fois la migration terminée.

Conditions préalables

Pour suivre cet article, vous aurez besoin d’un serveur maître Redis avec les données à exporter ou à migrer et d’un deuxième nouveau serveur Redis qui sera l’esclave.

Plus précisément, ce sont les conditions préalables pour le maître Redis.

Et ce sont les conditions préalables pour l’esclave Redis.

Assurez-vous de suivre la section de configuration du serveur de noms du didacticiel IPTables sur les deux serveurs; sans cela, + apt + ne fonctionnera pas.

Étape 1 - Mise à jour du pare-feu principal de Redis

Après avoir installé et configuré l’esclave Redis, vous disposez de deux serveurs indépendants qui ne communiquent pas à cause des règles de pare-feu. Dans cette étape, nous allons résoudre ce problème

Le correctif implique l’ajout d’une exception aux règles TCP sur le maître pour autoriser le trafic Redis sur le port 6379. Ainsi, sur le maître, ouvrez le fichier de configuration IPTables pour les règles IPv4.

sudo nano /etc/iptables/rules.v4

Juste en dessous de la règle qui autorise le trafic SSH, ajoutez une règle pour Redis qui autorise le trafic sur le port Redis only à partir de l’adresse IP de l’esclave. Assurez-vous de mettre à jour ++ à l’adresse IP du serveur esclave.

/etc/iptables/rules.v4

. . .
# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT

. . .

C’est très restrictif et plus sécurisé. Sinon, le serveur accepterait le trafic provenant de n’importe quel hôte sur le port Redis.

Redémarrez IPTables pour appliquer la nouvelle règle.

sudo service iptables-persistent restart

Maintenant que le système de réplication est opérationnel et que le pare-feu du maître est configuré pour autoriser le trafic Redis, nous pouvons vérifier que les deux serveurs peuvent communiquer. Cela peut être fait avec les instructions données à l’étape 4 de la Ce tutoriel sur le cluster Redis .

Étape 2 - Vérification de l’importation des données

Si les deux serveurs ont établi un contact, l’importation des données du serveur vers l’esclave devrait démarrer automatiquement. Il ne vous reste plus qu’à vérifier qu’il a bien été exécuté. Il y a plusieurs façons de vérifier cela.

Le répertoire de données Redis

Un moyen de vérifier si une importation de données est réussie consiste à consulter le répertoire de données Redis. Les mêmes fichiers qui sont sur le maître devraient maintenant être sur l’esclave. Si vous faites une longue liste des fichiers dans le répertoire de données Redis du serveur esclave en utilisant cette commande:

ls -lh /var/lib/redis

Vous devriez obtenir une sortie de cette sorte:

Sortie

total 32M
-rw-r----- 1 redis redis 19M Oct  6 22:53 appendonly.aof
-rw-rw---- 1 redis redis 13M Oct  6 22:53 dump.rdb

La ligne de commande Redis

Une autre méthode de vérification de l’importation des données consiste à utiliser la ligne de commande Redis. Entrez la ligne de commande sur le serveur esclave.

redis-cli

Puis authentifiez-vous et lancez la commande + info +

auth

info

Dans la sortie, le nombre de clés dans * # Keyspace * doit être identique sur les deux serveurs. La sortie ci-dessous provient du serveur esclave, qui est identique à la sortie sur le serveur maître.

Sortie

# Keyspace
db0:keys=26378,expires=0,avg_ttl=0

Scannez les clés

Une autre méthode permettant de vérifier que l’esclave dispose maintenant des mêmes données que le maître consiste à utiliser la commande + scan + à partir de la ligne de commande Redis. Bien que la sortie de cette commande ne soit pas toujours la même sur les deux serveurs, elle vous permettra au moins de confirmer que l’esclave contient les données que vous vous attendez à trouver.

Un exemple de sortie du serveur de test utilisé pour cet article est présenté ci-dessous. Notez que l’argument de la commande + scan + est n’importe quel nombre et agit comme un curseur:

scan 0

Le résultat devrait ressembler à ceci:

Sortie

1) "17408"
2)  1) "uid:5358:ip"
   2) "nodebbpostsearch:object:422"
   3) "uid:4163:ip"
   4) "user:15682"
   5) "user:1635"
   6) "nodebbpostsearch:word:HRT"
   7) "uid:6970:ip"
   8) "user:15641"
   9) "tid:10:posts"
  10) "nodebbpostsearch:word:AKL"
  11) "user:4648"
127.0.0.1:6379>

Étape 3 - Promouvoir l’esclave en maître

Une fois que vous avez confirmé que l’esclave dispose de toutes les données, vous pouvez le promouvoir en tant que maître. Ceci est également couvert dans https://www.digitalocean.com/community/tutorials/how-to-configure-a-redis-cluster-on-ubuntu-14-04#step-5-%E2%80%94- switch-to-the-slave [Étape 5 du tutoriel du cluster Redis], mais pour simplifier, les instructions sont également ici.

Tout d’abord, entrez la ligne de commande Redis sur l’esclave.

redis-cli

Après authentification, émettez la commande + slaveof no one + pour la promouvoir en tant que maître.

auth
slaveof no one

Vous devriez obtenir cette sortie:

Sortie

OK

Puis utilisez la commande + info + pour vérifier.

info

La sortie pertinente dans la section * Réplication * devrait ressembler à ceci. En particulier, la ligne * role: master * indique que l’esclave est maintenant le maître.

Sortie

# Replication

connected_slaves:0
master_repl_offset:11705
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Ensuite, une seule entrée dans le fichier journal de l’ancien maître doit également le confirmer.

/var/log/redis/redis-server.log

14613:M 07 Oct 14:03:44.159 # Connection with slave 192.168.1.8:6379 lost.

Et sur le nouveau maître (anciennement l’esclave), vous devriez voir:

/var/log/redis/redis-server.log

14573:M 07 Oct 14:03:44.150 # Connection with master lost.
14573:M 07 Oct 14:03:44.150 * Caching the disconnected master state.
14573:M 07 Oct 14:03:44.151 * Discarding previously cached master state.
14573:M 07 Oct 14:03:44.151 * MASTER MODE enabled (user request from 'id=4 addr=127.0.0.1:52055 fd=6 name= age=2225 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof')

À ce stade, vous pouvez maintenant connecter les applications à la base de données et supprimer ou détruire le maître d’origine.

Conclusion

Lorsque cela est fait correctement, la migration des données Redis de cette manière est une tâche simple. La principale source d’erreur consiste généralement à ne pas modifier le pare-feu du serveur maître afin d’autoriser le trafic Redis.

Vous pouvez apprendre à en faire plus avec Redis en parcourant la page more Redis.

Related