Migrer MongoDB vers Oracle Database sans temps d'arrêt

Découvrez comment utiliser OCI GoldenGate pour MongoDB vers Oracle Database sans temps d'arrêt.

OCI GoldenGate Big Data prend en charge les migrations d'MongoDB et d'MongoDB Atlas vers Oracle Autonomous JSON Database, Oracle Autonomous Database et Oracle Database sans temps d'arrêt. Autonomous JSON Database et Oracle Autonomous Database sont fournis avec des chaînes de connexion Oracle API for MongoDB préconfigurées que OCI GoldenGate utilise pour se connecter aux systèmes Oracle Database cible. Pour plus d'informations, reportez-vous à Utilisation d'Oracle Database API for MongoDB. Si votre cible est une base de données Oracle Database sur site, vous pouvez utiliser Oracle Rest Data Services pour activer Oracle Database API for MongoDB avec votre base de données Oracle Database sur site.

Avant de commencer

Pour terminer ce démarrage rapide, assurez-vous de disposer des éléments suivants :

  • Une source MongoDB, version 5 ou supérieure
  • Création d'un déploiement Big Data OCI GoldenGate, version 23.7 ou supérieure
  • MongoDB Outils de base de données, y compris mongodump et mongostore, installés et chemins de répertoire respectifs ajoutés à la variable d'environnement PATH

Configurer et exécuter la migration

  1. Dans votre source MongoDB, exécutez l'utilitaire de vidage MongoDB.
    1. Exécutez mongodump avec l'option --oplog pour créer un cliché de la base de données source MongoDB :
      $ ./bin/mongodump --uri="mongodb://localhost:27021" --oplog -v

      La commande renvoie les éléments suivants :

      <date+timestamp>    getting most recent oplog timestamp
<date+timestamp>    writing admin.system.version to dump/admin/system.version.bson
<date+timestamp>    done dumping admin.system.version (1 document)
<date+timestamp>    dumping up to 4 collections in parallel
<date+timestamp>    writing testDB.coll1 to dump/testDB/coll1.bson
<date+timestamp>    writing testDB.coll2 to dump/testDB/coll2.bson
<date+timestamp>    writing testDB.coll3 to dump/testDB/coll3.bson
<date+timestamp>    done dumping testDB.coll3 (10000 documents)
<date+timestamp>    done dumping testDB.coll1 (10000 documents)
<date+timestamp>    done dumping testDB.coll2 (10000 documents)
<date+timestamp>    writing captured oplog to
<date+timestamp>    dumped 7 oplog entries
      Cela génère un dossier de vidage contenant le fichier de données d'archive binaire pour toutes les bases de données et collections à l'emplacement suivant : 
      dump/database-name/collection-name/collection-name.bson
      Elle crée également un fichier oplog.bson directement sous le dossier de vidage.
    2. Pour inspecter le contenu du fichier oplog.bson (au format binaire), vous pouvez le convertir en JSON à l'aide de l'utilitaire bsondump :
      $ ./bin/bsondump --pretty --outFile /path/to/oplog.json dump/oplog.bson

      La commande renvoie les éléments suivants :

      <date+timestamp>    7 objects found
  2. Extraire les horodatages de la première et de la dernière opération à partir de oplong.bson :
    1. Télécharger le script OplogLSN.sh
    2. Exécutez le script OplongLSN.sh dans votre source MongoDB dans le même répertoire que celui où se trouve mongodump, en transmettant l'emplacement à oplog.bson en tant qu'argument comme suit :
      $./oplogLSN.sh /path/to/dump/oplog.bson

      La commande renvoie les éléments suivants :

      <date+timestamp> 1 objects found
First LSN: 1740663867.1
Last LSN: 1740663946.211
    3. Inspecter les entrées Oplog. S'il y avait des opérations entrantes pendant le vidage, le fichier oplog.bson contient des entrées pour ces opérations, chacune avec un horodatage. Vous pouvez utiliser OplogLSN.sh pour capturer les horodatages de la première et de la dernière opération ou le convertir en fichier JSON pour inspection manuelle, comme indiqué à l'étape précédente.
  3. Exécutez l'utilitaire de restauration MongoDB. Utilisez l'utilitaire mongorestore pour restaurer les collections sélectionnées à partir du fichier dump vers l'instance MongoDB cible :
    $ ./mongorestore --uri="mongodb://localhost:27021" --nsInclude=testDB.coll1 --nsInclude=testDB.coll2 /path/to/dump -v

    La commande renvoie les éléments suivants :

    <date+timestamp>    using write concern: &{majority <nil> 0s}
<date+timestamp>    using default 'dump' directory
<date+timestamp>    preparing collections to restore from
<date+timestamp>    found collection admin.system.version bson to restore to admin.system.version
<date+timestamp>    found collection metadata from admin.system.version to restore to admin.system.version
<date+timestamp>    don't know what to do with file "dump/oplog.json", skipping...
<date+timestamp>    found collection testDB.coll1 bson to restore to testDB.coll1
<date+timestamp>    found collection metadata from testDB.coll1 to restore to testDB.coll1
<date+timestamp>    found collection testDB.coll2 bson to restore to testDB.coll2
<date+timestamp>    found collection metadata from testDB.coll2 to restore to testDB.coll2
<date+timestamp>    reading metadata for testDB.coll1 from dump/testDB/coll1.metadata.json
<date+timestamp>    reading metadata for testDB.coll2 from dump/testDB/coll2.metadata.json
<date+timestamp>    creating collection testDB.coll1 with no metadata
<date+timestamp>    creating collection testDB.coll2 with no metadata
<date+timestamp>    restoring testDB.coll1 from dump/testDB/coll1.bson
<date+timestamp>    restoring testDB.coll2 from dump/testDB/coll2.bson
<date+timestamp>    finished restoring testDB.coll1 (10000 documents, 0 failures)
<date+timestamp>    finished restoring testDB.coll2 (10000 documents, 0 failures)
<date+timestamp>    no indexes to restore for collection testDB.coll1
<date+timestamp>    no indexes to restore for collection testDB.coll2
<date+timestamp>    20000 document(s) restored successfully. 0 document(s) failed to restore.

    La commande restaure les données, les métadonnées et les définitions d'index de la collection indiquée vers l'instance MongoDB/ORDS cible. Par exemple, coll1 et coll2 dans la base de données testDB, comme indiqué dans la sortie ci-dessus.

  4. Créez et exécutez une extraction CDC (Change Data Capture) sur le déploiement Big Data source pour MongoDB. Démarrez l'extraction CDC MongoDB à partir du premier horodatage d'opération (premier LSN) obtenu à l'étape 2b. Cela garantit que l'extraction CDC capture les opérations qui se produisent après le démarrage du processus de vidage.
  5. Créez et exécutez une réplication MongoDB.
    1. Utilisez le fichier de trace CDC généré à l'étape 4.
    2. Définissez oplongReplayLastLsn sur l'horodatage de la dernière opération (dernier LSN) obtenu à l'étape 2b, ou le chemin d'accès à oplog.bson et le dernier LSN est obtenu automatiquement. Ainsi, le processus Replicat s'exécute en mode oplong-replay, ce qui évite les collisions et garantit un lancement précis sans perte de données ni duplication. Une fois le dernier horodatage traité, le processus Replicat continue en mode normal.

Astuces

Voici quelques conseils pour garantir le bon déroulement de votre migration :

  • Il est recommandé d'utiliser mongodb-database-tools version 100.10.0 ou inférieure.
  • Avant d'exécuter mongodump, nettoyez le dossier de vidage existant pour supprimer les données incohérentes.
  • Restauration MongoDB : plusieurs ensembles d'une base de données peuvent être répliqués à l'aide de plusieurs options --nsInclude dans la commande mongorestore. Toutefois, les bases de données ORDS multiples ne peuvent pas être restaurées à l'aide de plusieurs commandes --nsInclude. Vous devez utiliser plusieurs commandes de restauration, une pour chaque base de données à restaurer.