One place for hosting & domains

      migrer

      Comment sauvegarder, restaurer et migrer une base de données MongoDB sur Ubuntu 20.04


      L’auteur a choisi le COVID-19 Relief Fund pour recevoir un don dans le cadre du programme Write for DOnations.

      Introduction

      MongoDB est l’un des moteurs de base de données NoSQL les plus populaires. Il doit sa célébrité à son évolutivité, sa robustesse, sa fiabilité et sa facilité d’utilisation. À l’aide de cet article, vous allez sauvegarder, restaurer et migrer un échantillon de base de données MongoDB.

      Lorsque l’on parle d’importation et d’exportation d’une base de données, nous faisons référence à la gestion de données sous un format lisible par l’homme et qui sont compatibles avec d’autres produits logiciels. En revanche, les opérations de sauvegarde et de restauration de MongoDB créent ou utilisent des données binaires spécifiques à MongoDB. Elles préservent non seulement la cohérence et l’intégrité de vos données mais également leurs attributs MongoDB spécifiques. Par conséquent, lors de la migration, il est généralement recommandé d’utiliser la sauvegarde et la restauration dans la mesure où les systèmes source et cible sont compatibles.

      Conditions préalables

      Avant de suivre ce tutoriel, vérifiez si vous répondez bien aux conditions préalables suivantes :

      Sauf indication contraire, toutes les commandes qui nécessitent des privilèges root dans ce tutoriel doivent être exécutées en tant que non-root user avec des privilèges sudo.

      Étape 1 — Utiliser JSON et BSON dans MongoDB

      Avant de poursuivre avec cet article, vous devez avoir quelques connaissances de base sur le sujet. Si vous avez de l’expérience avec d’autres systèmes de base de données NoSQL comme Redis, il se peut que vous trouviez quelques similitudes avec MongoDB.

      MongoDB utilise les formats JSON et BSON (JSON binaire) pour stocker ses informations. JSON est le format lisible par l’homme, idéal pour exporter et éventuellement importer vos données. Vous pouvez également gérer vos données exportées avec tout outil qui prend en charge JSON et notamment un éditeur de texte simple.

      Voici à quoi ressemble un exemple de document JSON :

      Example of JSON Format

      {"address":[
          {"building":"1007", "street":"Park Ave"},
          {"building":"1008", "street":"New Ave"},
      ]}
      

      Bien que le format JSON soit pratique pour travailler, il ne prend cependant pas en charge tous les types de données disponibles dans BSON. Cela signifie que, si vous utilisez JSON, vous ferez l’expérience de ce que l’on nomme une « perte de fidélité » des informations. Que ce soit pour la sauvegarde ou la restauration, il est donc préférable d’utiliser le format binaire BSON.

      Deuxièmement, vous n’aurez plus à vous soucier de créer explicitement une base de données MongoDB. Si la base de données spécifiée que vous souhaitez importer n’existe pas encore, elle sera automatiquement créée. Cette fonctionnalité est encore plus pratique avec la structure des collections (tables de la base de données). Contrairement à d’autres moteurs de base de données, dans MongoDB, la structure est également créée automatiquement à l’insertion du premier document (ligne de la base de données).

      Troisièmement, dans MongoDB, il se peut que la lecture et l’insertion de grandes quantités de données, (comme les tâches de cet article par exemple) exigent un volume intensif de ressources et consomment une grande partie de votre CPU, de votre mémoire et de votre espace disque. Ce point est crucial, car on utilise fréquemment MongoDB avec de grandes bases de données et les Big Data. Pour palier ce problème, la solution la plus simple consiste à exécuter les exportations et les sauvegardes pendant la nuit ou en-dehors des heures de pointe.

      Quatrièmement, il se peut que la cohérence des informations pose des problèmes si le serveur MongoDB est occupé et si les informations qui s’y trouvent changent pendant le processus d’exportation ou de sauvegarde de la base de données. Il existe une solution possible à ce problème qui est la réplication. Vous pourrez envisager de l’utiliser une fois que vous en saurez davantage sur MongoDB.

      Bien que vous puissiez utiliser les fonctions import et export pour sauvegarder et restaurer vos données, il existe de meilleures façons d’assurer la complète intégrité de vos bases de données MongoDB. Pour sauvegarder vos données, nous vous recommandons d’utiliser la commande mongodump. Pour la restauration, utilisez mongorestore. Voyons comment ces deux commandes fonctionnent.

      Étape 2 — Utiliser mongodump pour sauvegarder une base de données MongoDB

      Examinons tout d’abord de quelle manière sauvegarder votre base de données MongoDB.

      Un des arguments essentiels de mongodump est --db. Il spécifie le nom de la base de données que vous souhaitez sauvegarder. Si vous omettez de spécifier le nom de la base de données, mongodump procédera à la sauvegarde de toutes vos bases de données. Le second argument important est --out. Il permet de définir le répertoire dans lequel les données seront déchargées. Par exemple, sauvegardons la base de données newdb et sauvegardons-la dans le répertoire /var/backups/mongobackups. Idéalement, chacune de nos sauvegardes devraient se trouver dans un répertoire affichant la date du jour comme suit : /var/backups/mongobacackup/10-29-20.

      Créez tout d’abord ce répertoire /var/backups/mongobackups :

      • sudo mkdir /var/backups/mongobackups

      Ensuite, exécutez mongodump :

      • sudo mongodump --db newdb --out /var/backups/mongobackups/`date +"%m-%d-%y"`

      Vous verrez un résultat similaire à ce qui suit :

      Output

      2020-10-29T19:22:36.886+0000 writing newdb.restaurants to 2020-10-29T19:22:36.969+0000 done dumping newdb.restaurants (25359 documents)

      Notez que, dans le chemin du répertoire ci-dessus, nous avons utilisé date +"%m-%d-%y qui permet d’obtenir la date du jour automatiquement. Nos sauvegardes se trouveront ainsi dans le répertoire nommé de la manière suivante : /var/backups/10-29-20/. Ceci est particulièrement pratique pour automatiser les sauvegardes.

      À ce stade, vous disposez d’une sauvegarde complète de la base de données newdb dans le répertoire /var/backups/mongobackups/10-29-20/newdb/. Cette sauvegarde intègre tout ce dont vous avez besoin pour restaurer la newdb correctement et préserver sa dénommée « fidélité ».

      En règle générale, vous devriez régulièrement procéder à des sauvegardes, de préférence au moment où le serveur est le moins chargé. Par conséquent, vous pouvez configurer la commande mongodump comme un travail cron afin qu’elle s’exécute régulièrement, par exemple, chaque jour à 03:03 du matin.

      Pour cela, ouvrez crontab, l’éditeur de cron :

      Notez que, lorsque vous exécutez sudo crontab, vous allez modifier les tâches cron pour le root user. Cette commande est recommandée. En effet, si vous configurez les crons pour votre utilisateur, ils ne s'exécuteront pas correctement, surtout si votre profil sudo nécessite une vérification du mot de passe.

      Dans l'invite crontab, insérez la commande mongodump suivante :

      crontab

      3 3 * * * mongodump --out /var/backups/mongobackups/`date +"%m-%d-%y"`
      

      Dans la commande ci-dessus, nous avons omis l'argument --db sur l'objet délibérément, car vous souhaiterez généralement sauvegarder toutes vos bases de données.

      En fonction de la taille de votre base de données MongoDB, vous devriez rapidement manquer d'espace disque à cause du nombre élevé de sauvegardes. C'est pourquoi il est également recommandé de nettoyer ou de compresser régulièrement les anciennes sauvegardes.

      Par exemple, si vous souhaitez supprimer toutes les sauvegardes de plus de sept jours, vous pouvez utiliser la commande bash suivante :

      • find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} ;

      De la même manière que la commande mongodump précédente, vous pouvez également ajouter cette commande en tant que cron. Elle devra être exécutée juste avant de commencer la prochaine sauvegarde, par exemple, à 03:01 du matin. Pour cela, ouvrez à nouveau crontab :

      Ensuite, insérez la ligne suivante :

      crontab

      1 3 * * * find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} ;
      

      Enregistrez et fermez le fichier.

      En exécutant toutes les tâches de cette étape, vous disposerez d'une solution de sauvegarde adaptée à vos bases de données MongoDB.

      Étape 3 — Utiliser mongorestore pour restaurer et migrer une base de données MongoDB

      Lorsque vous restaurez votre base de données MongoDB à l'aide d'une sauvegarde précédente, vous obtenez la copie exacte de vos informations MongoDB à un moment particulier qui inclut tous les index et les types de données. Ceci est particulièrement utile pour migrer vos bases de données MongoDB. Pour restaurer MongoDB, nous allons utiliser la commande mongorestore qui fonctionne avec les sauvegardes binaires générées par mongodump.

      Continuons à travailler sur nos exemples avec la base de données newdb pour voir de quelle manière nous pouvons la restaurer à partir de la sauvegarde précédemment réalisée. Nous allons tout d'abord spécifier le nom de la base de données en utilisant l'argument --nsInclude. Nous allons ensuite utiliser newdb.* pour restaurer toutes les collections. Pour restaurer une collection unique, comme restaurants, utilisez plutôt newdb.restaurants.

      Puis, en utilisant --drop, nous allons veiller à ce que la base de données cible soit tout d'abord supprimée afin que la sauvegarde puisse être restaurée dans une base de données propre. Pour finir, nous allons spécifier le répertoire de la dernière sauvegarde, dont l'appellation devrait ressembler à ce qui suit : /var/backups/mongobackups/10-29-20/newdb/.

      Une fois que vous disposez d'une sauvegarde horodatée, vous pouvez la restaurer en utilisant la commande suivante :

      • sudo mongorestore --db newdb --drop /var/backups/mongobackups/10-29-20/newdb/

      Vous verrez un résultat similaire à ce qui suit :

      Output

      2020-10-29T19:25:45.825+0000 the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead 2020-10-29T19:25:45.826+0000 building a list of collections to restore from /var/backups/mongobackups/10-29-20/newdb dir 2020-10-29T19:25:45.829+0000 reading metadata for newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.metadata.json 2020-10-29T19:25:45.834+0000 restoring newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.bson 2020-10-29T19:25:46.130+0000 no indexes to restore 2020-10-29T19:25:46.130+0000 finished restoring newdb.restaurants (25359 documents) 2020-10-29T19:25:46.130+0000 done

      Dans le cas ci-dessus, nous avons restauré les données sur le serveur dans lequel nous avons créé la sauvegarde. Si vous souhaitez migrer les données sur un autre serveur et utiliser la même technique, vous devrez alors copier le répertoire de sauvegarde, c'est-à-dire /var/backups/mongobackups/10-29-20/newdb/ dans notre cas, sur l'autre serveur.

      Conclusion

      Vous avez désormais exécuté quelques-unes des tâches essentielles liées à la sauvegarde, la restauration et la migration de vos bases de données MongoDB. Aucun serveur MongoDB de production ne devrait jamais être exécuté sans une stratégie de sauvegarde fiable, comme celle décrite ici.



      Source link

      Comment migrer les données Redis avec réplication sur Ubuntu 18.04


      Introduction

      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.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de :

      Étape 1 – (Facultatif) Chargement de votre instance Redis source avec des échantillons de données

      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 :

      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.

      Étape 2 — Sauvegarde de votre instance Redis source

      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 :

      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 :

      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 :

      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.

      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 :

      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: :

      Output

      dump.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.

      Étape 3 — Configuration de votre instance Redis source

      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 :

      /etc/redis/redis.conf

      . . .
      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 :

      /etc/redis/redis.conf

      . . .
      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 :

      /etc/redis/redis.conf

      . . .
      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 :

      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.

      Étape 4 — Configuration de votre instance Redis cible

      À 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 :

      /etc/redis/redis.conf

      . . .
      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 :

      /etc/redis/redis.conf

      . . .
      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 :

      /etc/redis/redis.conf

      . . .
      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.

      Étape 5 — Démarrage et vérification de la réplication

      À 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 :

      Exécutez la commande auth pour authentifier la connexion :

      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 :

      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 :

      Output

      1) "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 :

      Cela va retourner le nombre de secondes avant que cette clé ne soit supprimée :

      Output

      5430

      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 :

      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 :

      Output

      1) "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.

      Conclusion

      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.



      Source link