MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Comment migrer des données dans MongoDB

Le but de cet article est de découvrir les différentes méthodes de migration de données dans MongoDB qui peuvent nous aider à écrire des scripts qui modifient votre base de données en ajoutant de nouveaux documents, en modifiant ceux qui existent déjà.

Si vous venez ici pour la première fois, veuillez jeter un coup d'œil à la préquelle MongoDB auto-hébergée.

Très bien, reprenons là où nous nous étions arrêtés et commençons la migration des données dans MongoDB.

Maintenant, les étapes de base pour migrer des données d'un MongoDB vers un autre seraient :

  1. Créer une sauvegarde compressée des données existantes
  2. Vider les données dans une nouvelle base de données

C'est très simple lorsque la base de données source n'est pas en ligne, car nous savons qu'aucun nouveau document ne sera créé/mis à jour pendant le processus de migration. Examinons d'abord la migration simple avant de plonger dans le scénario en direct.

Migration depuis une base de données hors ligne dans MongoDB

Création d'une sauvegarde

Nous allons utiliser un programme utilitaire existant, mongodump, pour créer la sauvegarde de la base de données.

Exécutez cette commande dans le serveur de base de données source

mongodump --host="hostname:port" \
  --username="username" --password="password" \
  --authenticationDatabase "admin" \
  --db="db name" --collection="collection name" --query='json' \
  --forceTableScan -v --gzip --out ./dump

--host :Le nom d'hôte MongoDB source avec le port. Il est par défaut localhost:27017 . S'il s'agit d'une chaîne de connexion, vous pouvez utiliser cette option —-uri="mongodb://username:password@host1[:port1]..."

--username :spécifie un nom d'utilisateur pour s'authentifier auprès d'une base de données MongoDB qui utilise l'authentification.

--password :spécifie un mot de passe pour s'authentifier auprès d'une base de données MongoDB qui utilise l'authentification.

--authenticationDatabase :Spécifie la base de données d'authentification où le --username spécifié a été créé.

Si vous ne spécifiez pas de base de données d'authentification ou de base de données à exporter, mongodump suppose que la base de données d'administration contient les informations d'identification de l'utilisateur.

--db :spécifie la base de données à partir de laquelle effectuer une sauvegarde. Si vous ne spécifiez pas de base de données, mongodump collecte toutes les bases de données de cette instance.

Alternativement, vous pouvez également spécifier la base de données directement dans la chaîne de connexion URI, c'est-à-dire mongodb://username:password@uri/dbname .
Fournir une chaîne de connexion tout en utilisant également --db et la spécification d'informations contradictoires entraînera une erreur .

--collection :spécifie une collection à sauvegarder. Si vous ne spécifiez pas de collection, cette option copie toutes les collections de la base de données ou de l'instance spécifiée dans les fichiers de vidage.

--query :fournit un document JSON en tant que requête qui limite éventuellement les documents inclus dans la sortie de mongodump.
Vous devez placer le document de requête entre apostrophes ('{ ... }') pour s'assurer qu'il n'interagit pas avec votre environnement.
La requête doit être au format Extended JSON v2 (soit en mode détendu, soit en mode canonique/strict), y compris en mettant les noms de champ et les opérateurs entre guillemets, par ex. '{ "created_at": { "\$gte": ISODate(...) } }' .

Pour utiliser la --query option, vous devez également spécifier l'option --collection option.

--forceTableScan :Force mongodump à analyser directement le magasin de données. En règle générale, mongodump enregistre les entrées telles qu'elles apparaissent dans l'index du _id domaine.

Si vous spécifiez une requête --query , mongodump utilisera l'index le plus approprié pour prendre en charge cette requête.
Par conséquent, vous ne pouvez pas utiliser --forceTableScan avec le --query possibilité .

--gzip :Compresse la sortie. Si mongodump sort dans le répertoire de vidage, la nouvelle fonctionnalité compresse les fichiers individuels. Les fichiers ont le suffixe .gz .

--out :Spécifie le répertoire où mongodump écrira BSON fichiers pour les bases de données vidées. Par défaut, mongodump enregistre les fichiers de sortie dans un répertoire nommé dump dans le répertoire de travail actuel.

Restauration de la sauvegarde

Nous utiliserons un programme utilitaire appelé mongorestore pour restaurer la sauvegarde de la base de données.

Copiez le vidage du répertoire de sauvegarde dans la nouvelle instance de base de données et exécutez la commande suivante :

mongorestore --uri="mongodb://user:password@host:port/?authSource=admin" \
  --drop --noIndexRestore --gzip -v ./dump

Remplacez les informations d'identification par les nouvelles informations d'identification de la base de données. Délignez à l'étape précédente, le --authenticationDatabase l'option est spécifiée dans la chaîne URI.

Utilisez également --gzip si utilisé lors de la création de la sauvegarde.

--drop :Avant de restaurer les collections à partir de la sauvegarde de vidage, supprime les collections de la base de données cible. Il ne supprime pas les collections qui ne sont pas dans la sauvegarde.--noIndexRestore :Empêche mongorestore de restaurer et de créer des index comme spécifié dans la sortie mongodump correspondante.

Si vous souhaitez modifier le nom de la base de données lors de la restauration, vous pouvez le faire en utilisant
--nsFrom="old_name.*" --nsTo="new_name.*" options.

Cependant, cela ne fonctionnera pas si vous deviez migrer avec oplogs qui est une exigence dans la migration à partir d'une instance en ligne.

Migration depuis une base de données en ligne dans MongoDB

Le seul défi de la migration à partir d'une base de données en ligne est de ne pas pouvoir suspendre les mises à jour pendant la migration. Voici donc l'aperçu des étapes,

  1. Exécuter une migration groupée initiale avec oplogs capturer
  2. Exécuter une tâche de synchronisation pour atténuer la latence du changement de connexion à la base de données

Maintenant, pour capturer les oplogs , un jeu de répliques doit être initialisé dans les bases de données source et de destination. C'est parce que les oplogs sont capturés à partir de local.oplog.rs espace de noms, qui est créé après l'initialisation d'un jeu de répliques.

Vous pouvez suivre ce guide pour configurer un jeu de répliques.

Migration initiale avec Oplog Capture

Les oplogs, en termes simples, sont les journaux d'opérations créés par opération dans la base de données. Ils représentent un état partiel du document ou, en d'autres termes, l'état de la base de données. Nous allons donc capturer toutes les mises à jour de notre ancienne base de données pendant le processus de migration à l'aide de ces oplogs .

Exécutez le programme mongodump avec les options suivantes,

mongodump --uri=".../?authSource=admin" \
  --forceTableScan --oplog \
  --gzip -v --out ./dump

--oplog :Crée un fichier nommé oplog.bson dans le cadre du mongodump production. Le oplog.bson fichier, situé au niveau supérieur du répertoire de sortie, contient oplog entrées qui se produisent pendant l'opération mongodump. Ce fichier fournit un instantané efficace de l'état de notre instance de base de données.

Restaurer les données avec oplog replay

Afin de rejouer les oplogs, un rôle spécial est requis. Créons et attribuons le rôle à l'utilisateur de la base de données utilisé pour la migration.

Créer le rôle

db.createRole({
  role: "interalUseOnlyOplogRestore",
  privileges: [
    {
      resource: { anyResource: true },
      actions: [ "anyAction" ] 
    }
  ],
  roles: []
})

Attribuer le rôle

db.grantRolesToUser(
  "admin",
  [{ role:"interalUseOnlyOplogRestore", db:"admin" }]
);

Vous pouvez maintenant restaurer à l'aide du programme mongorestore avec les options suivantes,

mongorestore --uri="mongodb://admin:.../?authSource=admin" \
  --oplogReplay 
  --gzip -v ./dump

Dans la commande ci-dessus, en utilisant le même utilisateur admin à qui le rôle était associé.

--oplogReplay  :Après avoir restauré le vidage de la base de données, rejoue les entrées oplog à partir d'un fichier bson et restaure la base de données à la sauvegarde ponctuelle capturée avec le mongodump --oplog commande.

Atténuation de la latence du changement de connexion à la base de données

Très bien, jusqu'à présent, nous en avons fini avec la plupart des gros travaux. Il ne reste plus qu'à maintenir la cohérence entre les bases de données lors du basculement de connexion dans nos serveurs applicatifs.

Si vous utilisez MongoDB version 3.6+, il est préférable d'opter pour l'approche Change Stream, qui est un mécanisme basé sur les événements introduit pour capturer les modifications dans votre base de données de manière optimisée. Voici un article qui en parle https://www.mongodb.com/blog/post/an-introduction-to-change-streams

Découvrez le script de synchronisation générique, que vous pouvez exécuter en tant que tâche CRON toutes les minutes.

Mettre à jour les variables dans ce script et exécuter en tant que

$ ./delta-sync.sh from_epoch_in_milliseconds

# from_epoch_in_milliseconds is automatically picked with every iteration if not supplied

Ou vous pouvez configurer une tâche cron pour l'exécuter toutes les minutes.

* * * * * ~/delta-sync.sh

La sortie peut être surveillée avec la commande suivante (j'utilise RHEL 8, reportez-vous au guide de votre système d'exploitation pour la sortie cron)

$ tail -f /var/log/cron | grep CRON

Ceci est un exemple de journal de synchronisation.

CMD (~/cron/dsync.sh)
CMDOUT (INFO: Updated log registry to use new timestamp on next run.)
CMDOUT (INFO: Created sync directory: /home/ec2-user/cron/dump/2020-11-03T19:01:01Z)
CMDOUT (Fetching oplog in range [2020-11-03T19:00:01Z - 2020-11-03T19:01:01Z])
CMDOUT (2020-11-03T19:01:02.319+0000#011dumping up to 1 collections in parallel)
CMDOUT (2020-11-03T19:01:02.334+0000#011writing local.oplog.rs to /home/ec2-user/cron/dump/2020-11-03T19:01:01Z/local/oplog.rs.bson.gz)
CMDOUT (2020-11-03T19:01:04.943+0000#011local.oplog.rs  0)
CMDOUT (2020-11-03T19:01:04.964+0000#011local.oplog.rs  0)
CMDOUT (2020-11-03T19:01:04.964+0000#011done dumping local.oplog.rs (0 documents))
CMDOUT (INFO: Dump success!)
CMDOUT (INFO: Replaying oplogs...)
CMDOUT (2020-11-03T19:01:05.030+0000#011using write concern: &{majority false 0})
CMDOUT (2020-11-03T19:01:05.054+0000#011will listen for SIGTERM, SIGINT, and SIGKILL)
CMDOUT (2020-11-03T19:01:05.055+0000#011connected to node type: standalone)
CMDOUT (2020-11-03T19:01:05.055+0000#011mongorestore target is a directory, not a file)
CMDOUT (2020-11-03T19:01:05.055+0000#011preparing collections to restore from)
CMDOUT (2020-11-03T19:01:05.055+0000#011found collection local.oplog.rs bson to restore to local.oplog.rs)
CMDOUT (2020-11-03T19:01:05.055+0000#011found collection metadata from local.oplog.rs to restore to local.oplog.rs)
CMDOUT (2020-11-03T19:01:05.055+0000#011restoring up to 4 collections in parallel)
CMDOUT (2020-11-03T19:01:05.055+0000#011replaying oplog)
CMDOUT (2020-11-03T19:01:05.055+0000#011applied 0 oplog entries)
CMDOUT (2020-11-03T19:01:05.055+0000#0110 document(s) restored successfully. 0 document(s) failed to restore.)
CMDOUT (INFO: Restore success!)

Vous pouvez arrêter ce script après avoir vérifié qu'il n'y a plus d'oplogs sont en cours de création, c'est-à-dire lorsque la base de données source est passée hors ligne.

Ceci conclut le guide complet de migration de données MongoDB auto-hébergé. Si vous souhaitez en savoir plus sur MongoDB, voici une ressource utile sur l'utilisation de MongoDB comme source de données dans goLang.